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

在入職公司前，筆者只知道產(chǎn)品分為B端C端、PC端或移動端等；入職公司后，才知道原來還有一種產(chǎn)品叫做中臺產(chǎn)品，與前臺產(chǎn)品、后臺產(chǎn)品同屬于一個分類。

在查閱資料的過程中，筆者發(fā)現(xiàn)中臺并不是今年才出現(xiàn)的概念，而筆者在此前作為一個產(chǎn)品求職者，卻從未關(guān)注過，深感慚愧。

于是，筆者在邊摸索邊踩坑的狀態(tài)中，開啟了職業(yè)生涯之路，也在接下來的實際工作中總結(jié)出了關(guān)于中臺產(chǎn)品的三個“要做”和“不做”。

要做通用能力，不做定制能力

故事發(fā)生在今年7月。

彼時，筆者還是一名剛?cè)腴T做中臺的產(chǎn)品新人，進入職場僅一個月。

筆者所在的中臺團隊下，積分模塊剛完成了服務(wù)升級，需要在公司范圍內(nèi)尋找相關(guān)團隊接入中臺，避免相同服務(wù)在多處維護，浪費人力資源。

筆者的任務(wù)，就是引導(dǎo)業(yè)務(wù)團隊A將原來的服務(wù)遷移至中臺，由我們中臺對積分模塊進行統(tǒng)一管控。

在初步需求溝通過程中，問題很快就浮出了水面。

在業(yè)務(wù)團隊A原來使用的系統(tǒng)中，獲取積分的途徑是固定不變的，但是每次可獲取的積分數(shù)量是可變的，且操作人員可以在前端展示頁面中輸入任意一個大于零的自然數(shù)，允許靈活修改。

而在我們中臺的積分模塊中，獲取積分的途徑是代碼里預(yù)置好的，每次可獲取的積分數(shù)量及積分獲取規(guī)則也是在代碼里預(yù)置好的，這些數(shù)據(jù)均不能在前端展示頁面中人為修改。

于是，業(yè)務(wù)團隊A提出希望中臺在頁面中增加一個可配置的文本框，用于操作人員靈活配置發(fā)放的積分數(shù)量。

由于缺乏實戰(zhàn)經(jīng)驗，對于這個需求我遲遲拿不定主意，于是我找到身經(jīng)百戰(zhàn)的研發(fā)負責(zé)人，詢問他的建議。

研發(fā)同學(xué)立刻聽出了團隊A的弦外之音，原來是想讓我們中臺給他們做定制化需求呢。

于是當機立斷，給出建議：我們中臺不做定制需求，如果他們非要積分可配置化，那就先醬，再醬，最后再醬，OK。

筆者表示感謝：原來如此，我本來還覺得他這個需求蠻合理，差點就同意了~

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

要做預(yù)處理，不做過度處理

在筆者剛?cè)腴T做中臺產(chǎn)品的時候，曾經(jīng)做過這樣一個需求：

在電商訂單盛行的當下，可能會由于運營配置錯誤、用戶巧妙“薅羊毛”、被黑客攻擊系統(tǒng)等原因?qū)е路e分不正常虧損，因此要對積分支付過程中可能出現(xiàn)的風(fēng)險進行控制。

經(jīng)過一番思想的碰撞，筆者最終產(chǎn)出了一份自認為比較完整的解決方案：

前臺各業(yè)務(wù)端在系統(tǒng)中埋點，將用戶的操作日志數(shù)據(jù)傳給我們中臺，中臺自行落庫得到日志數(shù)據(jù)庫。

中臺對原始數(shù)據(jù)進行計算，得出多個數(shù)據(jù)指標，這些數(shù)據(jù)指標大多是對用戶的歷史消費習(xí)慣進行概括，比如積分消耗區(qū)間、每次支付行為平均消耗積分數(shù)量等；已經(jīng)計算好的數(shù)據(jù)指標用于支撐風(fēng)險判斷接口，以每次交易的基礎(chǔ)數(shù)據(jù)作為請求參數(shù)，比如本次交易需支付的積分數(shù)量等。

接口邏輯大概可以歸納為：將歷史消費習(xí)慣與本次交易做比較，如果本次交易的數(shù)據(jù)與歷史消費習(xí)慣不符，則將本次交易風(fēng)險等級置為y，需通過對應(yīng)的校驗才可繼續(xù)完成交易。

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

leader指出中臺最多做到日志統(tǒng)計報表這一步就夠了，而風(fēng)險判斷接口的各種判斷應(yīng)該由各業(yè)務(wù)端根據(jù)不同的應(yīng)用場景，做差異化的處理和判斷。

筆者幡然醒悟，中臺產(chǎn)品對原始數(shù)據(jù)做預(yù)處理的目的是更好地服務(wù)各前端業(yè)務(wù)線，但忌過度處理，或是做了本該各業(yè)務(wù)線做的工作。

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

《中臺產(chǎn)品經(jīng)理寶典》一書中，作者將互聯(lián)網(wǎng)公司的研發(fā)中心比作一個廚房，將研發(fā)新產(chǎn)品的過程比作做菜，從而將做菜這個過程拆解為：買菜、配菜、炒菜三個步驟：

買菜小哥作為后臺，為中臺提供最基礎(chǔ)的原料；

配菜小哥作為中臺，統(tǒng)一對菜做預(yù)處理，完成洗菜、切菜動作；

炒菜小哥作為前臺，則根據(jù)不同烹飪方式最終完成口味不同的菜品。

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

要判斷需求是否符合產(chǎn)品定位，不要盲目接需求

中臺向各業(yè)務(wù)團提供通用能力，目的是為了減輕各業(yè)務(wù)團的重復(fù)工作量，而不是為了減輕各業(yè)務(wù)團的工作量。

要注意區(qū)分“工作量”和“重復(fù)工作量“”，僅兩字之差，其含義卻相去甚遠。

舉個例子：

團隊A需要開發(fā)功能模塊a和功能模塊b，最終得到一個完整的產(chǎn)品x；

團隊B需要開發(fā)功能模塊a和功能模塊c，最終得到一個完整的產(chǎn)品y；

團隊C需要開發(fā)功能模塊a、功能模塊c和功能模塊d，最終得到一個完整的產(chǎn)品z。

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

筆者所在的中臺團隊下設(shè)不同領(lǐng)域的產(chǎn)品研發(fā)團隊，分管不同的業(yè)務(wù)領(lǐng)域。

其中，在訂單領(lǐng)域內(nèi)，常常出現(xiàn)這樣的情況：團隊B需要與中臺對接得到功能模塊a和附加小功能e。

功能模塊a屬于訂單領(lǐng)域，由中臺團隊下的訂單產(chǎn)研團隊負責(zé)開發(fā)；而附加小功能e不屬于訂單領(lǐng)域，由中臺團隊下的其他產(chǎn)研團隊負責(zé)開發(fā)。

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

顯而易見，這種做法是不合理的。如果中臺產(chǎn)品人將這樣的方案推上需求評審會，不僅不會得到研發(fā)負責(zé)人的認可，還可能會被各位研發(fā)同事懟。

畢竟，誰也不愿意做工作之外的工作，而我們產(chǎn)品人更不能因為自己身上不背負開發(fā)的重任，就隨意接需求，把一堆額外的任務(wù)丟給開發(fā)。

更重要的是：作為一名中臺產(chǎn)品人，把握需求的邊界應(yīng)該是我們的基本功~

寫在最后

本文主要描述了筆者在真實的工作場景中遇到的問題，并從問題中歸納總結(jié)出做中臺產(chǎn)品的三大原則。

以上僅作為筆者的經(jīng)驗，供各位讀者參考。

而各位讀者對于中臺的思考，需要從實際出發(fā)、在實際工作中總結(jié)專屬自己的經(jīng)驗，方可在中臺領(lǐng)域內(nèi)快速成長。

俗話說，讀萬卷書不如行萬里路。

對于剛?cè)腴T的產(chǎn)品新人來說，不論看過再多道理、再標準的指導(dǎo)原則，也許都跟紙上談兵無甚區(qū)別。

實踐是檢驗真理的唯一標準，關(guān)于中臺產(chǎn)品到底應(yīng)該如何做，相信一千個人有一千個哈姆萊特。

本文來自微信公眾號“人人都是產(chǎn)品經(jīng)理”（ID：woshipm），作者：一顆半柚，36氪經(jīng)授權(quán)發(fā)布。

關(guān)鍵詞： 不做 要做什么 產(chǎn)品