中臺產品,要做什么不做什么?

21 評論 11394 瀏覽 54 收藏 11 分鐘

#本文為人人都是產品經理《原創激勵計劃》出品。

不同產品具有各自的“能力邊界”,作為產品人,你知道一款中臺產品應當做好哪些工作、具備哪些能力嗎?當面對需求時,你能否判斷該需求應不應當開發?本文作者就結合實際工作經驗,總結了中臺產品的“三做”與“三不做”,也許可以解答你的困惑。

在入職公司前,筆者只知道產品分為B端C端、PC端或移動端等;入職公司后,才知道原來還有一種產品叫做中臺產品,與前臺產品、后臺產品同屬于一個分類。在查閱資料的過程中,筆者發現中臺并不是今年才出現的概念,而筆者在此前作為一個產品求職者,卻從未關注過,深感慚愧。

于是,筆者在邊摸索邊踩坑的狀態中,開啟了職業生涯之路,也在接下來的實際工作中總結出了關于中臺產品的三個“要做”和“不做”。

一、要做通用能力,不做定制能力

故事發生在今年7月。彼時,筆者還是一名剛入門做中臺的產品新人,進入職場僅一個月。

筆者所在的中臺團隊下,積分模塊剛完成了服務升級,需要在公司范圍內尋找相關團隊接入中臺,避免相同服務在多處維護,浪費人力資源。筆者的任務,就是引導業務團隊A將原來的服務遷移至中臺,由我們中臺對積分模塊進行統一管控。

在初步需求溝通過程中,問題很快就浮出了水面。在業務團隊A原來使用的系統中,獲取積分的途徑是固定不變的,但是每次可獲取的積分數量是可變的,且操作人員可以在前端展示頁面中輸入任意一個大于零的自然數,允許靈活修改。而在我們中臺的積分模塊中,獲取積分的途徑是代碼里預置好的,每次可獲取的積分數量及積分獲取規則也是在代碼里預置好的,這些數據均不能在前端展示頁面中人為修改。

于是,業務團隊A提出希望中臺在頁面中增加一個可配置的文本框,用于操作人員靈活配置發放的積分數量。由于缺乏實戰經驗,對于這個需求我遲遲拿不定主意,于是我找到身經百戰的研發負責人,詢問他的建議。

研發同學立刻聽出了團隊A的弦外之音,原來是想讓我們中臺給他們做定制化需求呢。于是當機立斷,給出建議:我們中臺不做定制需求,如果他們非要積分可配置化,那就先醬,再醬,最后再醬,OK。筆者表示感謝:原來如此,我本來還覺得他這個需求蠻合理,差點就同意了~

最后由筆者的leader牽頭組了一個會議,業務團隊A同意將原有的積分獲取規則進行管理和整合,對于每次可獲取的積分數量,也整理出一些可選值在代碼中提前預置好,操作人員可以在這些可選值中靈活配置。

二、要做預處理,不做過度處理

在筆者剛入門做中臺產品的時候,曾經做過這樣一個需求。在電商訂單盛行的當下,可能會由于運營配置錯誤、用戶巧妙“薅羊毛”、被黑客攻擊系統等原因導致積分不正常虧損,因此要對積分支付過程中可能出現的風險進行控制。

經過一番思想的碰撞,筆者最終產出了一份自認為比較完整的解決方案:

前臺各業務端在系統中埋點,將用戶的操作日志數據傳給我們中臺,中臺自行落庫得到日志數據庫。

中臺對原始數據進行計算,得出多個數據指標,這些數據指標大多是對用戶的歷史消費習慣進行概括,比如積分消耗區間、每次支付行為平均消耗積分數量等;已經計算好的數據指標用于支撐風險判斷接口,以每次交易的基礎數據作為請求參數,比如本次交易需支付的積分數量等。

接口邏輯大概可以歸納為:將歷史消費習慣與本次交易做比較,如果本次交易的數據與歷史消費習慣不符,則將本次交易風險等級置為y,需通過對應的校驗才可繼續完成交易。

但是當筆者與leader溝通想法的時候,卻得到了leader“你還是不懂中臺”的評價。

leader指出中臺最多做到日志統計報表這一步就夠了,而風險判斷接口的各種判斷應該由各業務端根據不同的應用場景,做差異化的處理和判斷。

筆者幡然醒悟,中臺產品對原始數據做預處理的目的是更好地服務各前端業務線,但忌過度處理,或是做了本該各業務線做的工作。

后來筆者查閱了很多文章和書籍,惡補中臺的概念及設計思想,終于找到了比較合理的解釋。

《中臺產品經理寶典》一書中,作者將互聯網公司的研發中心比作一個廚房,將研發新產品的過程比作做菜,從而將做菜這個過程拆解為:買菜、配菜、炒菜三個步驟。買菜小哥作為后臺,為中臺提供最基礎的原料;配菜小哥作為中臺,統一對菜做預處理,完成洗菜、切菜動作;炒菜小哥作為前臺,則根據不同烹飪方式最終完成口味不同的菜品。

在這個例子中,如果配菜小哥不僅完成了洗菜、切菜的動作,還順手完成了炒菜小哥的任務,則會導致炒菜小哥無任務可做,那么人員組織架構將會變得很混亂。

三、要判斷需求是否符合產品定位,不要盲目接需求

中臺向各業務團提供通用能力,目的是為了減輕各業務團的重復工作量,而不是為了減輕各業務團的工作量。要注意區分工作量和重復工作量,僅兩字之差,其含義卻相去甚遠。

舉個例子:

  • 團隊A需要開發功能模塊a和功能模塊b,最終得到一個完整的產品x;
  • 團隊B需要開發功能模塊a和功能模塊c,最終得到一個完整的產品y;
  • 團隊C需要開發功能模塊a、功能模塊c和功能模塊d,最終得到一個完整的產品z。

那么功能模塊a、功能模塊c就是重復工作量,而剩下的功能模塊b、功能模塊d皆屬于工作量,分別歸屬不同的團隊。

筆者所在的中臺團隊下設不同領域的產品研發團隊,分管不同的業務領域。

其中,在訂單領域內,常常出現這樣的情況:團隊B需要與中臺對接得到功能模塊a和附加小功能e。功能模塊a屬于訂單領域,由中臺團隊下的訂單產研團隊負責開發;而附加小功能e不屬于訂單領域,由中臺團隊下的其他產研團隊負責開發。

由于附加小功能e的開發量比較小,團隊B不愿意多對接一個團隊,因此常常會有需求,希望訂單產研團隊直接開發功能模塊a和附加小功能e,完成后對接給團隊B。

顯而易見,這種做法是不合理的。如果中臺產品人將這樣的方案推上需求評審會,不僅不會得到研發負責人的認可,還可能會被各位研發同事懟。畢竟,誰也不愿意做工作之外的工作,而我們產品人更不能因為自己身上不背負開發的重任,就隨意接需求,把一堆額外的任務丟給開發。

更重要的是,作為一名中臺產品人,把握需求的邊界應該是我們的基本功~

四、寫在最后

本文主要描述了筆者在真實的工作場景中遇到的問題,并從問題中歸納總結出做中臺產品的三大原則。以上僅作為筆者的經驗,供各位讀者參考。而各位讀者對于中臺的思考,需要從實際出發、在實際工作中總結專屬自己的經驗,方可在中臺領域內快速成長。

俗話說,讀萬卷書不如行萬里路。對于剛入門的產品新人來說,不論看過再多道理、再標準的指導原則,也許都跟紙上談兵無甚區別。實踐是檢驗真理的唯一標準,關于中臺產品到底應該如何做,相信一千個人有一千個哈姆萊特。

 

本文由 @一顆半柚 原創發布于人人都是產品經理,未經許可,禁止轉載。

本文為人人都是產品經理《原創激勵計劃》出品。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 中臺的具現就是接口沒錯吧

    來自湖南 回復
    1. 通常情況下是通過接口的方式將中臺能力提供給各個業務線,但是根據不同的業務需求也會有不同的方式(比如只傳輸數據,可以用消息隊列等)

      來自上海 回復
    2. 請教一下大佬,先目前一些普通的項目應該都是小中臺的形式,是通過接口或者隊列來交互,那有些人說的大中臺用通俗的說法該如何解釋了?

      來自湖南 回復
    3. 大佬不敢當,個人愚見:中臺都是通過接口或隊列等其他形式向各業務線提供支持,所謂的小中臺和大中臺的說法只是中臺在整個企業中所占的比例大小。在企業中,中臺所占的比例越大,就可以叫大中臺,中臺所占比例越小,就叫小中臺。

      來自上海 回復
    4. 了解了,言簡意賅

      來自湖南 回復
    5. 感謝支持~

      來自上海 回復
  2. 好文章,做中臺產品要把握的標準,列舉得通俗易懂

    來自北京 回復
    1. 感謝支持,元旦快樂~

      回復
  3. 好文章,受益良多

    來自福建 回復
    1. 感謝支持~

      來自上海 回復
  4. 樓主,如果業務方強勢,又該怎么辦呢?

    回復
    1. 那當然就需要產品比業務更強勢~~確定不做的需求,拒絕時一定要有充分的理由,不給業務反駁的機會

      來自上海 回復
  5. 受益了

    回復
    1. 感謝支持~

      來自上海 回復
  6. 如果有的需求業務線自己做,導致用戶體驗問題咋辦?之前遇過一個案例,需要中臺的掃碼工具支持掃A業務線的售后碼,售后碼這個類型是有些定制,但如果業務線自己做就是在前臺再增加一個掃碼入口,加上中臺的掃碼,兩個掃一掃入口,用戶很難辨別用哪個

    來自江蘇 回復
    1. 如果確實是業務線的定制需求,就業務線自己做,中臺不做。這樣一來就只有業務線做掃碼工具,也就不存在兩個掃一掃入口了。

      來自上海 回復
    2. 沒看懂,中臺不是有掃碼工具支持么?只是不支持售后碼。他意思好像是別的業務條線可能,不會用到這個碼的識別,不具備上中臺的背景。業務線再做掃碼工具就會有兩個入口。為啥回不存在?沒看懂

      回復
    3. 根據0風的問題,有這兩種可能:
      1、中臺已有掃碼工具,A業務線已有售后碼,0風的疑問是:售后碼屬于定制,按我的文章思路應該由業務線自己做,最終結果是中臺有掃碼工具,A業務線有售后碼、掃碼工具,這兩個掃碼工具用戶不知道該用哪個?
      2、A業務線已有售后碼,目前掃碼工具還未做,0風的疑問是:掃碼工具是A業務線來做還是中臺來做?
      按我原來的理解,是第二種可能,因此我認為中臺目前應該還沒有掃碼工具,所以我說不存在兩個掃碼入口?,F在看來可能是我理解錯了,應該是第一種可能~

      回復
    4. 再說解決方案,1、既然中臺已有掃碼工具,且屬于定制功能,就由A業務線自己做售后碼、掃碼工具,中臺下線掃碼工具的服務。2、A業務線來做。
      在0風的問題中,售后碼和掃碼工具應該是被合并為一個需求了,因此在以上的回答中,我也將二者進行了合并。此外,個人還有一個問題:售后碼是定制需求,由A業務線來做沒問題,但是0風并未說到掃碼工具是否是定制需求。如果掃碼工具是通用能力,那由中臺來做是沒問題的,不知道0風為何會提到A業務線再自己做一個掃碼工具?如果掃碼工具是定制需求,當時又為什么是中臺做了這個需求呢?

      回復
    5. 1. 掃碼是中臺通用能力,目前各個業務線前臺都接入了掃碼入口,包括A業務線~
      2. A業務線現在需要支持掃售后碼這個類型,但中臺掃碼不支持這個類型,屬于定制需求~
      3. 下線中臺的掃碼工具不妥,因為中臺掃碼解決了通用需求~
      4. A自己做的話,就得前臺再增加一個掃碼入口專門用于掃售后碼,加上通用的掃碼入口,前臺就出現兩個掃碼入口,對用戶來講就會有不知用哪個的問題~
      5. 所以我感覺這種業務線自己做會產生體驗問題的定制需求,中臺是否也要考慮做呢?

      來自江蘇 回復
    6. 原來如此,這種情況下,我建議:
      1、就售后碼這個定制需求,向除A業務線之外的前臺做需求調研,各團隊是否會用到售后碼?如果有其余團隊表示希望接入售后碼,那么問題迎刃而解,多條業務線需要的需求,中臺來做,即掃碼工具支持掃售后碼。
      2、如果除A業務線外沒有其他團隊要使用售后碼,那么我個人傾向于A業務線不接入中臺,自己做掃碼工具+售后碼。

      來自上海 回復