對筆者來說，由于公司的業(yè)務與產(chǎn)品特性，做中臺很有必要。于是在中臺實踐之下，筆者為我們總結分享了如何建設業(yè)務中臺。

這個冬天，風格外的冷，讓人不寒而栗；產(chǎn)品經(jīng)理，一種求生欲特別強的生物，不僅要考慮如何讓自己度過寒冬臘月，也要幫著老板降本增效，度過這個互聯(lián)網(wǎng)寒冬。而中臺或許就成了一個不錯的選擇。

一、為什么要選擇中臺？

我負責的產(chǎn)品是一個訂單調度管理平臺，這個平臺涵蓋了計劃、商品、訂單、審批、執(zhí)行和單據(jù)生命周期管理等模塊，是一個產(chǎn)品線交織、模塊冗合在一起的運營管理產(chǎn)品，還有各種各樣的配置、規(guī)則等。

面對新業(yè)務的產(chǎn)生和變化調整，超出了現(xiàn)有產(chǎn)品的承載服務能力。

產(chǎn)品線多，產(chǎn)品邏輯各異，對于一個產(chǎn)品來講，很難全局掌握——如果一個產(chǎn)品需要調整優(yōu)化， 容易產(chǎn)生產(chǎn)品遺漏或者產(chǎn)品設計漏洞，導致生產(chǎn)問題。

另外，對開發(fā)測試來講，通用的產(chǎn)品方案因為新業(yè)務的產(chǎn)生而重復性開發(fā)測試，不僅開發(fā)資源浪費嚴重，也會造成后期產(chǎn)品的運營維護壓力大增。

因此，業(yè)務場景隨著發(fā)展越來越多，堆砌式開發(fā)建設，產(chǎn)品管理越來越臃腫。

因此，優(yōu)化訂單管理平臺結構，創(chuàng)新產(chǎn)品管理方式，迫在眉睫！

這時候，我們就會慢慢思考，我們要將訂單調度管理平臺做成什么樣子呢？我們設定了幾個大的方向：

• 能力沉淀：將過去幾年來積累下的訂單調度能力沉淀下來，能夠支持多場景、高并發(fā)訂單服務；
• 快速響應：針對越來越快的業(yè)務發(fā)展速度，能夠提供現(xiàn)有邏輯的服用能力，快速響應新業(yè)務的需求，同時減少單據(jù)間的沖突；
• 穩(wěn)定輸出：提升訂單服務穩(wěn)定性，支持多種創(chuàng)單形式、提供統(tǒng)一創(chuàng)單服務接入規(guī)范，降低團隊協(xié)作和系統(tǒng)交互成本；
• 模塊化管理：針對訂單管理周邊服務，進行模塊化管理，并支持快速迭代調整，局部調整盡可能少的影響整體產(chǎn)品功能。

中臺解決方案就慢慢進入了我們產(chǎn)品的視野，中臺是啥呢？簡單來講就是企業(yè)級能力復用平臺，專業(yè)一點，就是一套結合互聯(lián)網(wǎng)技術和行業(yè)特性，將企業(yè)核心能力以共享服務中心進行沉淀，形成“大中臺、小前臺“的組織和業(yè)務機制，供企業(yè)快速低成本的進行業(yè)務創(chuàng)新的企業(yè)架構。

那我們?yōu)槭裁匆x擇中臺呢？

資本角度：

自從2018年以來，雖然互聯(lián)網(wǎng)投資資本趨勢不減，但投資熱度有所收斂，不再盲目“追風”,資金流向更加理性和集中。

資本主要是向頭部聚攏，部分尾部創(chuàng)業(yè)企業(yè)甚至沒有獲得任何新投資。

資本是逐利的，整體經(jīng)濟形勢不是很好的情況下，可以用的錢少了，錢也不那么好賺了，也更容易花掉了；就要省吃儉用，從各個成本中心降低成本，想辦法節(jié)約開發(fā)、人力和產(chǎn)品成本，甚至從員工福利下手，出國游變成了“新馬泰（新街口、馬群、泰馮路）一日游”。

不過，產(chǎn)品層面的中臺架構，因為能夠對人均效能的顯著改進而受科技企業(yè)追捧。

規(guī)劃調整：

公司的規(guī)模發(fā)展到一定程度，現(xiàn)有傳統(tǒng)的系統(tǒng)架構肯定無法支撐業(yè)務的體量和復雜程度，為了新業(yè)務，而不斷的調整企業(yè)級系統(tǒng)，不穩(wěn)定的系統(tǒng)會造成系統(tǒng)的巨大使用風險，如何保證系統(tǒng)的穩(wěn)定可用，是一個產(chǎn)品要思考的問題。

另外，業(yè)務發(fā)展很寬廣的時候，也要考慮產(chǎn)品的另一個問題，就是如何讓產(chǎn)品進行能力的積淀和輸出，通過有效的產(chǎn)品管理和設計，讓平臺的各種能力（功能/產(chǎn)品）能夠快速復用、快速組合，支持業(yè)務更快捷的探索和發(fā)展；

研發(fā)模式：

互聯(lián)網(wǎng)前十年，企業(yè)快速發(fā)展，不計成本的堆積互聯(lián)網(wǎng)產(chǎn)品和系統(tǒng)開發(fā)資源，煙囪建設了不少，而近兩年，這種研發(fā)方式針對的業(yè)務價值和收益卻寥寥無幾——有些產(chǎn)品線花了很大的成本建設起來，業(yè)務卻塌了，導致開發(fā)資源的極度浪費。

比如產(chǎn)品部門幾十個開發(fā)，每年（只能）做幾百多個需求，研發(fā)差不多每天都要加班到晚上9點左右，作為產(chǎn)品經(jīng)理一年要開幾百個會，每天18:00之后才能正經(jīng)寫寫文檔做做產(chǎn)品設計，和研發(fā)的下班時間差不多。

但是即便大家這么努力，產(chǎn)品部門的需求周期依然是特別長，整天被業(yè)務線投訴，一年下來，還沒做出太多創(chuàng)新的成果，對新業(yè)務的響應速度還是很慢。

因此，中臺架構擺脫了”煙囪式“系統(tǒng)建設方式所帶來的種種發(fā)展桎梏，通過統(tǒng)一的公共技術模塊抽離形成服務。再次需要該服務時通過接口調用完成，避免重復造輪子，避免研發(fā)周期拉長。

技術沖突：

還有煙囪式建立起來的產(chǎn)品，如果一個企業(yè)的業(yè)態(tài)較多，場景較為復雜，企業(yè)中后臺產(chǎn)品往往并不能很好的支撐前臺快速創(chuàng)新響應用戶的需求，后臺更多的是在解決企業(yè)管理效率問題，而中臺才能很好的解決前臺的創(chuàng)新問題。

大多數(shù)企業(yè)雖然已有的后臺，但是要么前臺根本就用不，要么不好用，要么變更速度跟不上前臺的節(jié)奏，前臺求變和新，中臺求穩(wěn)和定，依賴現(xiàn)有的產(chǎn)品架構，好像并不能很好的解決這個問題。

因此，企業(yè)有必要盡力搭建穩(wěn)定可靠的中臺系統(tǒng)，?要有前臺系統(tǒng)，能夠?而美，快速迭代。

業(yè)務發(fā)展：

這兩年業(yè)務快速創(chuàng)新發(fā)展，業(yè)務場景越來越復雜，短平快的業(yè)務創(chuàng)新，不斷的犯錯就是節(jié)約成本。

這里不得不提supercell公司——以 2 到 5 個員工、最多不超過 7 個員工組成獨立的開發(fā)團隊就可以進入新游戲的開發(fā)，投入市場看看游戲是否受用戶歡迎——如果用戶不歡迎，迅速放棄這個產(chǎn)品，再進行新的嘗試，以最小資源進行不斷的創(chuàng)新試錯，卻是對公司資源最大的節(jié)約，有了中臺，就可以支撐他們這樣去做；

時代變了：

另外就是，隨著用戶增長紅利逐步消失，互聯(lián)網(wǎng)市場趨于飽和，市場開始進入挖掘存量用戶的階段。用戶對應用的選擇變得更理性，互聯(lián)網(wǎng)產(chǎn)品也從野蠻生長變成了精細化運營——

過去躺在樹下摘果子的日子將一去不復返；產(chǎn)品也不是隨便開發(fā)幾個系統(tǒng)就能躺贏，必須精雕細琢產(chǎn)品方案，讓產(chǎn)品的成本一步步壓縮，卻還得承擔更多的職責，也就是馬兒吃的少，還得干的好，干得多。

二、怎么做中臺？

面對一個訂單調度管理平臺，現(xiàn)在他是一個整體，基本上沒有前后臺之分，一條產(chǎn)品線從單據(jù)開始到單據(jù)結束，由一個產(chǎn)品經(jīng)理負責，看似產(chǎn)品線十分清晰，這也是在保持現(xiàn)有規(guī)模下比較完美，可擴展性很差，如果我們切分了前中后臺，哪些產(chǎn)品是前臺，哪些產(chǎn)品是中臺呢？而我們的中臺又是什么性質的中臺呢？

從產(chǎn)品線來看，大概分為幾條產(chǎn)品線：采購線、退貨線、調撥線幾條。

就拿采購為例，采購的需求計劃、采購單據(jù)創(chuàng)建、采購執(zhí)行作業(yè)到采購單據(jù)完結，從頁面設計、訂單管理邏輯到作業(yè)執(zhí)行邏輯，從用戶體驗、人機交互到單據(jù)跟蹤預警，只要是采購相關的東西都是一個產(chǎn)品經(jīng)理負責，這算是產(chǎn)品線責任制，在業(yè)務邏輯簡單，場景較為單一的情況下，此方案非常好用。

不過，隨著業(yè)務的發(fā)展，各種各樣的小產(chǎn)品（預售采購、生鮮采購、門店采購）出現(xiàn)，因為小產(chǎn)品的差異，而去改動一條產(chǎn)品線的各個入口，導致牽一發(fā)而動全身，從頭改到尾，產(chǎn)品經(jīng)理每接到一個新業(yè)務需求，可謂是苦不堪言，若是換成了一個新產(chǎn)品經(jīng)理，丟三落四的產(chǎn)品方案，漏洞百出。

另外，每個產(chǎn)品線都會涉及用戶操作頁面，不同的產(chǎn)品經(jīng)理因為風格不一樣，設計出來的產(chǎn)品功能也會不一樣，同一平臺下不同的模塊帶給使用者的用戶體驗也是不同的，經(jīng)常會出現(xiàn)業(yè)務提需求：A產(chǎn)品經(jīng)理，你做的跟B產(chǎn)品經(jīng)理設計的頁面一樣就好了。多么尷尬的需求呀！

從現(xiàn)有架構來看，訂單調度管理平臺的產(chǎn)品線管理是縱向剖析的，按照產(chǎn)品線模塊去劃分的，那切分了前中后臺，我們要換成什么結構模塊切割呢？

對于中臺，現(xiàn)在市面上有好幾種類型的中臺：數(shù)據(jù)中臺、業(yè)務中臺、組織中臺、技術中臺，從產(chǎn)品設計及使用來看，訂單調度管理平臺本身是業(yè)務系統(tǒng)，對現(xiàn)有的業(yè)務需求實現(xiàn)信息化管理，因此，我們搭建的應該屬于業(yè)務中臺，即：

基于抽象復用、架構合理性和業(yè)務統(tǒng)一管理的視角，通過適度的業(yè)務邏輯抽象、彈性的復用功能設計，將產(chǎn)品管理方案進行抽象、復用和下沉，打造企業(yè)級功能服用平臺。

切分前中后臺

下一個問題就我們該怎么切分了，粗略統(tǒng)計了一下，我們大概有以下好幾種設想：

• 按照技術系統(tǒng)結構切分前中后臺；
• 按照頁面與邏輯切分前中后臺：
• 按照需求申請與訂單調度切分前中后臺：
• 按照業(yè)務場景和通用執(zhí)行切分前中后臺：

剛開始接觸前中后臺，前臺的印象停留在前端的概念，那不就是頁面和后臺邏輯的區(qū)分嘛。

因此，我們團隊進行了拆分，一個團隊負責頁面，與頁面相關的都歸屬于前臺產(chǎn)品負責，那么后臺復雜的業(yè)務邏輯就是由中臺負責，這樣劃分下來，立馬矛盾就凸顯出來了——

做一個業(yè)務需求，頁面的前臺產(chǎn)品畫，邏輯中臺產(chǎn)品寫，前臺產(chǎn)品不就是UI體驗部了嘛。

對接同一個需求，業(yè)務被搞蒙了，產(chǎn)品也被搞蒙了，本來一個產(chǎn)品可以搞定的產(chǎn)品方案，結果投入了兩三個人力資源，不僅不省力，還浪費資源。

因此，這樣做肯定不行！

后來和技術交流后，在深入探索一下，能否按照技術系統(tǒng)切分去做呢？

訂單調度系統(tǒng)有兩個技術系統(tǒng)，A系統(tǒng)大概負責預測計劃，B系統(tǒng)負責單據(jù)執(zhí)行。

這樣下來，前臺產(chǎn)品負責A系統(tǒng)，中臺產(chǎn)品負責B系統(tǒng)，這樣做起產(chǎn)品需求是好一些。

不過怪怪的，前臺產(chǎn)品有些需求要調整B系統(tǒng)的邏輯，中臺產(chǎn)品有時候也會聯(lián)動A系統(tǒng)，因此，產(chǎn)品矛盾解決了，技術矛盾越發(fā)凸顯，也不是很好。

在后面又有了新的變化，因為A系統(tǒng)大概負責預測計劃，B系統(tǒng)負責單據(jù)執(zhí)行，那我們就按照產(chǎn)品類型來切分，需求端不管頁面還是邏輯都是由前端產(chǎn)品負責，那單據(jù)執(zhí)行，不管是頁面還是邏輯都是由中臺產(chǎn)品負責，這樣下來，也解決了技術矛盾。

不過由我看來，這樣也不是很好——并不能解決業(yè)務快速發(fā)展與系統(tǒng)響應較慢的矛盾問題和資源重復浪費的問題。

隨著對中臺的深入體會和架構師的溝通學習，逐漸對中臺有了更深層次的意識和了解——

前臺是一個個業(yè)務的小場景，那中臺通過調度各個資源服務于前臺部門，為前臺業(yè)務服務；中臺要做的是抽象、沉淀和整合后臺資源，包裝成便于前臺使用的可復用、可共享的核心能力，實現(xiàn)后臺資源到前臺易用能力的簡化。

其實在這個過程中，分析了現(xiàn)有的業(yè)務場景，針對現(xiàn)有的零售場景，有商超、便利店、高端店以及門店和中心倉下的各種商業(yè)場景（預售、無人貨架、新鮮到家），規(guī)模不是很大。

而且公司處于探索時期，針對一種商業(yè)模式，比如說便當模式，可能要短短一個月內要上線試點，然后過了半個月，效益不好，模式試驗失敗，又會迅速止損下線。

要是按照傳統(tǒng)的模式，那我們可能就是改了整套產(chǎn)品系統(tǒng)來適配這樣商業(yè)模式的運作，這樣的風險很大而且成本很高，因此前中后臺不分家的產(chǎn)品管理并不能很好的支撐前臺快速創(chuàng)新響應業(yè)務場景的需求；

慢慢的，經(jīng)過切分的陣痛期和前臺中臺的磨合，我理解的中臺慢慢清晰了起來，企業(yè)級產(chǎn)品管理既要求穩(wěn)定，又要求快速應變，穩(wěn)定和應變本來就是相悖的兩件事，那中臺就是這種矛盾的變速箱，將前臺（車輪）與后臺（發(fā)動機）的速率矛盾匹配起來，達到最佳的傳動比，提升發(fā)動機的效率，降低油耗、

因此，我們的切分不是簡單的系統(tǒng)、頁面還有單據(jù)類型的區(qū)分，變成了業(yè)務小場景和抽象能力沉淀的劃分，小場景中也有通用的邏輯，那我們就把它在產(chǎn)品管理中沉淀到中臺去進行資源整合包裝提供穩(wěn)定的輸出，轉化為前臺友好可重用的核心能力，我們的前臺就是各類小產(chǎn)品場景下的前端系統(tǒng)，他們就像一個個用戶觸點，是企業(yè)與用戶最直接的接觸。

小場景產(chǎn)品快速迭代上線，中臺則不斷的抽象、沉淀，解決了前臺與后臺失速的問題，以此幫助企業(yè)不斷提升用戶響應。

三、我們做了哪些事？

從業(yè)務抽象到領域建模，再到架構設計，一步步搭建起訂單調度管理系統(tǒng)的中臺產(chǎn)品管理模式；作為中臺產(chǎn)品，從0到1的中臺建設，從骨子里都要保持中臺思維，我們做了以下幾件事：

業(yè)務抽象

梳理現(xiàn)有業(yè)務現(xiàn)狀，將各類場景入口、單據(jù)管理和單據(jù)信息流進行對比分析，設計業(yè)務藍圖和抽象業(yè)務元素，隱藏業(yè)務細節(jié)，將業(yè)務對象進行抽象化。

中臺產(chǎn)品在抽象化的過程中，就是做建模工程圖一樣，一會我要縮小公工程圖看看整個房子好不好看，俯瞰全貌看看整體效果是不是在控制之中，一會我還得放大，深入局部看細節(jié)有沒有畫到位，看看每個細節(jié)的房屋結構是否合理。

因此，業(yè)務抽象化一定要站在一定產(chǎn)品架構高度，把控和規(guī)劃好產(chǎn)品管理。落在產(chǎn)品功能設計，夠設計易用的功能和優(yōu)秀的交互體驗。

中臺核心產(chǎn)品模塊規(guī)劃

經(jīng)過業(yè)務的調研和分析，基于上階段輸出的主題域，技術架構師按照中心的多個劃分標準，進行產(chǎn)品模塊的規(guī)劃，從業(yè)務管理和產(chǎn)品管理的角度，總結出整體的架構設計，在覆蓋現(xiàn)有所有業(yè)務場景基礎上，整體產(chǎn)品架構具備易于擴展、組合，可支持動態(tài)伸縮、精準監(jiān)控等目標。

抽象與整合實施，組建最小產(chǎn)品模塊

產(chǎn)品功能設計是在產(chǎn)品模塊規(guī)劃設指導下，由上而下、由粗到細的抽象過程，主要是將業(yè)務抽象成果轉化為產(chǎn)品管理方案(主要由業(yè)務場景、業(yè)務流程構成)，通過搭建最小產(chǎn)品模塊，實現(xiàn)產(chǎn)品的模塊化設計，業(yè)務能力輸出就會像搭積木一樣，將各個最小產(chǎn)品功能模塊快速組合在一起，實現(xiàn)能力的輸出。

確定了中臺的整體思路后，產(chǎn)品經(jīng)理就可以放開手腳，自主推動業(yè)務中臺建設了。

產(chǎn)品管理切分交割

面對集合在一起的產(chǎn)品做前中后臺拆分，在完成整體思路和細節(jié)設計后，就是產(chǎn)品管理的灰度切換和交割，這只是產(chǎn)出業(yè)務價值的開始。業(yè)務中臺經(jīng)過運營管理，不斷沉淀和發(fā)展，循環(huán)往復，能力會逐步增強和擴展，模型會逐步調整和完善。

其實，中臺方案解決了現(xiàn)有企業(yè)遇到的矛盾和問題，但是在實施過程中，中臺也并不是完美的方案，這個過程中，也感受到了中臺產(chǎn)品管理的弊端。

中臺產(chǎn)品與業(yè)務漸行漸遠

我做了四個月的中臺搭建，最大的感觸是離我們的業(yè)務人員交流的時間和頻次明顯降低了很多——基本上需求都是從前端產(chǎn)品而來，不斷的梳理抽象邏輯和業(yè)務場景，根據(jù)對現(xiàn)有業(yè)務的理解不斷的構建中臺的框架。

但是這些產(chǎn)品管理的需求，沒有業(yè)務能夠深入理解，他們能做的就是我們現(xiàn)在的業(yè)務時什么，接下來要做什么，至于中臺要怎么做，很大程度上看一個產(chǎn)品經(jīng)理的理解和輸出。

中臺需求優(yōu)先級不穩(wěn)定

中臺雖然隱藏在了前臺業(yè)務場景后面，但是也會接受到業(yè)務的需求提報，但是對于業(yè)務優(yōu)先級排期，我們有兩大類需求：中臺建設自提自解決需求和業(yè)務需求，但是每次資源排期，不確定因素會很大，可能因為業(yè)務需求緊急，而無法排期中臺建設需求，導致錯過了中臺整合的最佳時期，后再進行變更調整，可能會用到更多的資源。

因此，中臺需求很不穩(wěn)定，但是我們畢竟是業(yè)務導向型產(chǎn)品平臺，無法將兩類需求提升到同一維度排定優(yōu)先級，但是，中臺產(chǎn)品一定要留點資源給一些中臺基礎建設。

前期建設資源占用較大，短期無明顯業(yè)務價值產(chǎn)出

針對訂單調度管理平臺，初期進行中臺建設，每一個需求都要占用到兩個月的人天資源，整個改造下來，基本上可以做幾十個大項目了，因為無業(yè)務價值產(chǎn)出，業(yè)務同事也無法理解，資源占用較大，受到了很大的抵觸，產(chǎn)品經(jīng)理一定要扛得住壓力，量化價值指標，中臺的價值效益會隨著公司的發(fā)展慢慢展現(xiàn)出來；

四、中臺經(jīng)驗總結

我覺得中臺產(chǎn)品應該這么干，“任憑弱水三千，我只取一瓢飲”，雖然有弱水三千，中臺產(chǎn)品經(jīng)理眼里有一瓢水即可，對于中臺產(chǎn)品的舊詞新解，我覺得還蠻合適的，總結一下自己的經(jīng)驗與大家分享探討：

中臺產(chǎn)品一定要保留力量始終去做一些基礎的、重要不緊急的事情

由于互聯(lián)網(wǎng)公司多年來信奉的就是「唯快不破」，團隊在做優(yōu)先級排序時，往往會傾向于去做業(yè)務價值最明顯的事情，有很多重要不緊急的工作就被壓在后面，永遠沒有再被提起過。

但對中臺產(chǎn)品團隊需要有不同的要求——中臺產(chǎn)品一定要保留力量始終去做一些基礎的、重要不緊急的事情。

很多企業(yè)的信息建設部門停留在業(yè)務支持的程度，看起來好像甲方乙方一樣，作為業(yè)務導向型產(chǎn)品部門，業(yè)務提出當前的業(yè)務需求，以項目制管理產(chǎn)品工作，業(yè)務對系統(tǒng)的整體架構不會過多考慮，完成了一個煙囪式項目，即項目結束，又投入了另一個項目中。

作為中臺產(chǎn)品經(jīng)理，不僅要考慮業(yè)務提出的需求，還要在項目過程中，不斷的整合基礎產(chǎn)品管理，借項目之力，一點點完善中臺建設；

明顯共性的功能模塊盡早抽象落地

訂單管理調度平臺屬于B端產(chǎn)品，很多形態(tài)的產(chǎn)品是具備明顯共性的，可以盡早的進行抽象設計。

這樣在系統(tǒng)架構建設的初期，就能做出正確的設計方案，不會增加太多多少研發(fā)工作量，未來還會讓系統(tǒng)擴展更加輕松。如果建設到一定程度的平臺，在進行拆分前中后臺，對橫踢架構調整，的確要花費很大的力氣。

適度的業(yè)務邏輯抽象，不要過于多的考慮未來

中臺產(chǎn)品設計初期，沒有必要為未來不確定的事情提前做過多的布局，適度的業(yè)務邏輯抽象、彈性的復用功能設計即可，因為很有可能未來根本用不到，卻會產(chǎn)生過度設計，造成開發(fā)資源的浪費，甚至也會讓系統(tǒng)架構看起來非常奇怪。

業(yè)務價值和訴求導向系統(tǒng)抽象迭代

沒有明確的收益和價值，強行采用中臺理念設計，會造成業(yè)務的困惑和恐慌，可能會造成業(yè)務正常工作的不良影響，在初期階段，可以容忍一定程度的不合理，但是中臺的產(chǎn)品管理一定是體現(xiàn)了業(yè)務訴求，能夠量化業(yè)務價值，才能得到業(yè)務方的支持，順利的進行系統(tǒng)的抽象迭代功能。

通過這段時間的中臺架構切分和搭建，希望能給企業(yè)發(fā)一張“免裁劵”，在互聯(lián)網(wǎng)寒冬中，安穩(wěn)的度過這段艱難的日子……

本文由 @產(chǎn)品包工頭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議