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

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

一、為什么要選擇中臺？

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

面對新業務的產生和變化調整，超出了現有產品的承載服務能力。

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

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

因此，業務場景隨著發展越來越多，堆砌式開發建設，產品管理越來越臃腫。

因此，優化訂單管理平臺結構，創新產品管理方式，迫在眉睫！

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

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

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

那我們為什么要選擇中臺呢？

資本角度：

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

資本主要是向頭部聚攏，部分尾部創業企業甚至沒有獲得任何新投資。

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

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

規劃調整：

公司的規模發展到一定程度，現有傳統的系統架構肯定無法支撐業務的體量和復雜程度，為了新業務，而不斷的調整企業級系統，不穩定的系統會造成系統的巨大使用風險，如何保證系統的穩定可用，是一個產品要思考的問題。

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

研發模式：

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

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

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

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

技術沖突：

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

大多數企業雖然已有的后臺，但是要么前臺根本就用不，要么不好用，要么變更速度跟不上前臺的節奏，前臺求變和新，中臺求穩和定，依賴現有的產品架構，好像并不能很好的解決這個問題。

因此，企業有必要盡力搭建穩定可靠的中臺系統，?要有前臺系統，能夠?而美，快速迭代。

業務發展：

這兩年業務快速創新發展，業務場景越來越復雜，短平快的業務創新，不斷的犯錯就是節約成本。

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

時代變了：

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

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

二、怎么做中臺？

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

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

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

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

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

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

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

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

切分前中后臺

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

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

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

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

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

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

因此，這樣做肯定不行！

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

訂單調度系統有兩個技術系統，A系統大概負責預測計劃，B系統負責單據執行。

這樣下來，前臺產品負責A系統，中臺產品負責B系統，這樣做起產品需求是好一些。

不過怪怪的，前臺產品有些需求要調整B系統的邏輯，中臺產品有時候也會聯動A系統，因此，產品矛盾解決了，技術矛盾越發凸顯，也不是很好。

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

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

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

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

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

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

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

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

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

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

三、我們做了哪些事？

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

業務抽象

梳理現有業務現狀，將各類場景入口、單據管理和單據信息流進行對比分析，設計業務藍圖和抽象業務元素，隱藏業務細節，將業務對象進行抽象化。

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

因此，業務抽象化一定要站在一定產品架構高度，把控和規劃好產品管理。落在產品功能設計，夠設計易用的功能和優秀的交互體驗。

中臺核心產品模塊規劃

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

抽象與整合實施，組建最小產品模塊

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

確定了中臺的整體思路后，產品經理就可以放開手腳，自主推動業務中臺建設了。

產品管理切分交割

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

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

中臺產品與業務漸行漸遠

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

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

中臺需求優先級不穩定

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

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

前期建設資源占用較大，短期無明顯業務價值產出

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

四、中臺經驗總結

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

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

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

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

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

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

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

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

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

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

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

業務價值和訴求導向系統抽象迭代

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

通過這段時間的中臺架構切分和搭建，希望能給企業發一張“免裁劵”，在互聯網寒冬中，安穩的度過這段艱難的日子……

本文由 @產品包工頭 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議