網易有道中台試錯這一年

圖源：圖蟲創意

市面上有關中台的“應景兒”文章越來越多，但是講概念的多、有乾貨的少，畢竟中台雖然熱，但是還缺少真刀真槍的實踐。而恰恰本文作者，就是一位中台的實踐者。他所在的團隊用一年時間搭建中台，雖然因為公司戰略和組織架構調整，中台項目被停止了，但是其間有太多的收獲、感悟和反思，借本篇文章分享給對中台感興趣的朋友們。

令人唏噓的一年

故事的開端

2018 年 3 月份，我正式成為一名中台產品經理，在這之前的一兩個月，我已經和 Sunner 就中台的發展有了多次溝通。我們要做一個在線教育領域的中台產品——愛多思（EduOS），顧名思義，就是一個在線教育的作業系統。線下教育的教學工具有桌椅板凳，黑板、粉筆、投影儀等教學設備，組合成物理世界的課堂，愛多思的目標是構建出線上教育裡的桌椅板凳，讓其能夠自由組合成一整個在線教學管理系統（LMS），並形成標準。

這是一個有挑戰的活兒：

首先，當時中台在互聯網公司是個新概念，如何在互聯網公司裡做一個中台，業界並沒有太多的成熟經驗可以參考；

其次，各條業務線裡煙囪式的教學系統已經分開跑了很久了，在這個基礎上搭建中台，就好像在給飛行中的飛機換引擎（當然，並不是每條業務跑得同樣快，這也是中台能夠在各個業務產品間周旋的基礎）。

17 年阿里出版的那本書「阿里中台戰略」是我們當時唯一找到的理論基礎，阿里大中台幾年的實踐，以及 17 年我們通過一支幾個人的別動隊在內部對可行性的探索，最終讓我們在申請立項時說明這事可以做成。

中台項目正式立項，我成為立項後第一個產品經理，Sunner 是負責人和產品架構師。我們計劃用兩年時間把中台搭建好，讓愛多思能夠支撐各條業務線的發展，並且能快速孵化出新的業務。然而一年過後，2019 年 2 月底，因為公司戰略和組織架構調整，中台項目被停止了。

我依然清晰的記得那天，大家在會議室裡討論已經在線上跑的中台服務未來何去何從，想想在雲端本地無數的代碼庫中有一套打著那天的 tag，然後就沒有再更新過，讓人唏噓不已。

這一年的收獲

回顧這一年，我們做成了這幾件事兒：

完成了多個教學服務的中台化改造。其中包括一些底層的基礎服務，如账號、權限、點播、直播等；也包括一些具備教學邏輯的模塊，如直播課、題庫、問卷等等。每個服務都可以單獨拿出來做成可直接給終端用戶使用的產品，類似於 CCtalk、問卷星，並且這些服務和模塊都已經支持各業務產品了。

總結出來中台化產品設計、產品研發、項目管理的一些標準規範和套路。依照這些標準和套路，沒有中台經驗的產品和技術人員也可以快速的開發出中台服務，並被業務產品接入使用。

當然我們也還有一些沒做完的事兒，包括：

中台教學系統的閉環。我們做了一些獨立的教學模塊，但還沒能夠用中台化的標準把這些教學模塊完全組合起來，形成一個可以系統化學習的課程。

中台價值的量化體系。只有做好了價值量化這一點，我們才算完成了中台在商業世界裡的實踐，並且經驗可以被推廣到公司內外。

中台商業化的探索。我個人一直希望能夠把中台做成一個可商業化的企業服務，不僅僅只是一個內部支持型的產品。中台項目停止後，我也依然在教育 ToB 行業。時常在想：如果有了成熟的中台能夠對現在的問題有什麽幫助？現在看起來，在國內目前的商業環境下，一個好的中台，其對內服務產生的價值還是遠遠高於對外直接輸出的價值，慶幸當年 Sunner 壓製住了我想快速商業化的訴求。

假如我們能有兩年時間，不知道能否達成最初的目標，也不知道未來是否還有機會繼續？但我幾乎肯定的是：中台會在接下來互聯網和傳統產業深度結合時，變得越來越重要。名字除了叫中台外，還可能會被稱為平台、中間件、共享服務等等。

此外對於我個人而言，應該說我這一年的收獲良多：

進入互聯網行業後，小步快跑成了常態。而在中台的這段時間，我難得能夠暫時放開業務的壓力，按照近乎理想化的標準去進行產品架構設計、做抽象、畫 UML、花時間仔細思考。我本不是這樣的人，這也算是在刻意練習了。

作為一個在線教育行業的新人，通過中台我能有機會參與整個事業部涉及的所有教育業務，包括 K12、成人、ToC、ToB，讓我對在線教育行業有了一個更全面的認識，從中尋找興趣所在。

結識了一幫優秀而有趣的小夥伴，大家一起做有挑戰的事情，也才有了這篇文章裡的回憶。

都在談中台，究竟什麽是中台？

中台的概念

中台是近年來 IT 行業非常火的概念（這裡最好加上一個”IT 行業“的限定，因為曾經有商務同事以為我是研究兩岸關係的，哈哈），有很多的文章從產品、技術、組織等多個角度來解釋什麽是中台。對於一個快速變化的新概念而言，很難有標準定義，阿里中台某高管都提到過現在阿里所做到的離他所定義的中台還有一段距離。

給定義是非常謹慎的事情，但很多時候不給定義又沒辦法繼續聊，所以我也曾經在一個內部分享上給中台做了定義「服務於某個垂直領域的工具平台」。在做這個定義時，我是參考了雲計算的概念的。雲計算是一種通用服務，那麽中台和雲計算有什麽差別呢？按照 IaaS/PaaS/SaaS 來劃分，服務的領域越來越垂直。參考這種方式，我會定義中台在 PaaS 和 SaaS 之間，主要原因如下：

PaaS 提供了一種服務，客戶的程序員通過二次開發使用 PaaS 服務，最終完成某個功能給最終用戶。PaaS 的通用性需要非常強，這樣才能獲得足夠大的市場，比如 IM、視頻雲服務等，也因此 PaaS 往往是沒有界面的。

SaaS 提供的服務不需要客戶進行開發，只需要開通服務，在管理後台上配置一下就可以直接使用。但 SaaS 服務往往針對的是一個細分領域，其定製化能力也相對弱很多。即使是像釘釘，釘釘選擇 IM 這種企業中最通用化的服務，同時做成企業服務的開放生態，目標客戶也主要是覆蓋中小企業。定製化需求強的大客戶，也往往會需要希望借助 IM PaaS 服務來自主研發內部 IM 工具。

PaaS 和 SaaS 定位在服務外部客戶，必須具備很低的使用成本。即使是需要通過技術來接入的 PaaS 服務，接入成本也一定要足夠低，接口清晰，文檔完善。

中台首先是定位在服務公司內部客戶，由於這個範圍的限定，導致中台的通用性可以在很多約束條件下來實現，可服務的領域比 SaaS 廣。比如即使同樣是電商，淘寶、天貓、聚劃算、閑魚、飛豬的站點都是不一樣的，而阿里共享事業部就在中台層服務多個業務。此外，由於中台的用戶是公司內部的程序員，大家有相似的背景，也可以頻繁溝通，所以服務接入的成本可以做得比面向外部客戶的 PaaS 要高。

中台 vs 第一性原理

很多資料在介紹中台概念時都會引用這樣兩個例子：

美軍的特種部隊加航空母艦的策略：10 人以內的一支特種部隊在戰鬥的最前沿偵查，獨立決策，一旦發現目標，迅速呼叫強大的中台航母群對其進行毀滅性打擊。

芬蘭著名的遊戲公司 SuperCell，開發了部落衝突、皇室戰爭等現象級的手遊。整個公司才 200 多號人，就被騰訊以 86 億美金收購。在 SuperCell 裡，一個遊戲開發團隊平均是 3-7 個人，但有一個強大的遊戲中台在做支撐，可以並行開發 50 款遊戲，然後通過“內部賽馬”產生出一到兩款經典。據說馬雲在帶領阿里眾多高官參觀了 SuperCell 後，回來就在阿里整個集團層面啟動了大中台戰略。

同時我想要對比的是另一個概念「第一性原理」。第一性原理也是近幾年很火的一個詞，基本已經成為完成顛覆式創新的大殺器。最典型的例子之一就是 Elon Musk 了。這個同時掌管 Solar、SpaceX 和 Tesla 的矽谷鋼鐵俠，從最基礎的物理學原理出發，重新設計和製造的獵鷹火箭，正帶領著人類飛向火星。

在上述例子中，第一性原理和中台都帶來了創新和成功，但其實這兩者在某種程度上是矛盾的。第一性原理往往是打破原有的經驗，跳出舒適圈，從最底層邏輯去進行思考。而中台是將通用的能力進行抽象和共享，將成功的經驗固化下來，將有限的人力投入到創新中去。

第一性原理是物理世界運轉的本質，在沒有時間條件的約束下，可以推導出整個世界。假如地球要滅亡了，只有一張紙上的信息能夠保留下來，寫在這張紙上的就是地球文明的第一性原理。基於這些可以重塑地球文明，但可能需要幾千萬年。

但人類社會的運轉往往是有明確時間約束的，如果我只知道 1+1=2 時就要完成微積分，可能要窮盡一生。因此，依靠前人和自己的經驗做事才是人類社會能夠高效運轉的基本要素，放在 IT 行業，這些經驗就叫中台。經驗往往能帶來效率提升、成本提升、質量提高，同時也能帶來偏見、慣性思維模式，中台也一樣。

我們為什麽要做中台？

隨著「阿里中台服務」那本書在 17 年的出版，中台開始走進更多人的視野，並且在 18 年逐漸熱門起來。但那時網上介紹中台的文章和分享還不多，記得我在準備公司內中台分享時，沒有花多大功夫就看完了幾乎所有相關內容。

而到了 2019 年，中台的熱度迅速攀升，火爆程度有點類似 16 年的 VR、18 年的區塊鏈。同時我也聽說有創業公司連核心業務的商業模式還沒摸清楚，上來就要搞中台。這其實是沒搞清楚為什麽要建中台、中台要解決什麽問題：

首先，中台是支撐公司多個業務產品的共享服務，如果你的公司只有一個業務產品，能做的最多只能是良好的架構設計，沒有多個業務產品的實際場景輸入，是難以直接做出中台的。

其次，中台的目標是提高業務產品的研發效率，但為了達到這個目的，在一段時間內是需要以降低「效率」為代價的，時間長短取決於系統複雜度和團隊能力的差距。

當公司隨著業務發展，需要研發第二個、第三個產品時，在這種情況下可能會有兩種方式來構建中台：

新產品和技術架構都是繼承自當前產品，不斷的通過優化當前產品架構來適應新的產品，讓中台服務自然沉澱出來。這種情況下的前提條件是在做第一個產品時就做好了服務架構設計，即便如此，在第二個產品時很有可能還是要走彎路，不能滿足新產品快速迭代和試錯的渴望。但到了第三個、第四個產品時，就會變得越來越快了。

新的產品和技術架構都是重新設計，這樣做每個產品的速度都差不多，靈活度也能做到最高。但每個產品都很難在技術上從前面的產品去借力。當團隊人員發生變動、產品越來越多，多分支的維護和開發就凸顯了人力不足的問題，這時候就需要搭建一個中台。這也是我們當時所面臨的問題。

我所在的事業部發展了多年，有五條業務產品線。這五條產品線就是從一條產品線開始，隨著時間的推移逐步發展起來的。和大部分研發團隊的情況一樣，在應對快速變化的市場環境時，我們沒有能夠做好系統的底層積累，而是選擇了一條在當時看來是更簡單的路徑：從一套代碼 copy 出了另一套代碼來支撐新的產品。

多年後我們就有了五個獨立的系統來支撐五個業務產品。我無法判斷如果當時做好了底層系統架構，整個部門實際會發展成什麽樣。只知道當五個產品要在五套系統上快速往前跑時，研發的複雜程度和成本都太高了。為了解決這個問題，我們決定做中台。

當然我們也可以有另外的選擇——砍掉大部分產品，隻專注做到一、兩個。但大家都知道，其實真正困難的不是決定做什麽，而是決定不做什麽，這種決策其實比做中台更加困難。此外，作為一家成熟的公司，一定是需要有能夠形成合力的產品矩陣來支撐整個公司戰略推進的，所以多產品並行是公司發展到一定階段的必然選擇，而做中台也絕不是站在其中某一個產品的角度來解決問題，而是站在多產品協同的角度來看公司的戰略發展。

從公司戰略來看，阿里巴巴的曾鳴在「智能商業」一書中提出了看十年、做一年的觀點。在日益複雜而又快速變化的市場環境中，公司已經無法做到一個五年的準確的規劃，並執行下去。而需要通過看十年的終局思維來看到行業最終會成為什麽樣子，從而制定公司願景和方向。

通過做一年的方法來制定計劃，快速落地一些事情，然後根據效果來迅速調整方向、更新計劃，朝著終局推進。要想做到這點，基礎能力的積累就非常重要，而中台也是其中非常重要的部分。

站在產品團隊的角度來看，一個搭建完成的中台基礎框架，能夠帶來的直接價值就是：

成本節省。需要開發新功能時，很可能這個功能中台已經提供了，產品經理提供配置參數，研發直接接入服務就可以用起來了。

效率提高。在中台上開發新功能，只需要參考標準和文檔，一個新人也可以快速上手，並且這個新功能還可以被其他產品直接使用，產生複利效應。

質量提升。從兩方面來看：

設計質量。中台團隊通常會以功能模塊為劃分，專職負責某功能模塊的團隊往往會更有意願去突破一些難點，成為最懂此功能模塊的團隊。比如現在教育領域最熱門的授課方式就是直播課，而直播功能就是一個有較高門檻的功能模塊。要想做出適合業務發展的直播功能，需要對雲計算、計算機網絡、直播授課方法、直播運營等多個方面都有較為深入的了解。這需要團隊能夠有一定程度的積累，不是從某一個業務產品研發團隊裡找幾個人就能很快突擊出來的。

研發質量。中台的服務往往提供給多個業務產品使用，出現故障就會造成大面積的問題。所以質量保障往往是中台服務的生命線。每一個下沉到中台的服務不但會經過常規的測試，還會在 Code review、單元測試覆蓋率等指標上有更為嚴格的要求，力保高質量的交付。

我們是怎麽做中台的？

產品設計層面

隨著中台的日益火爆，如何做一個中台產品經理也成了一個新的職業發展熱點，最近也看到有了線上的中台產品經理課程。中台產品經理是 B 端產品經理的一種類型，有 B 端通用的能力要求，比如擅長做抽象建模、具備一定的研發技術功底、懂 UML 等，我在這裡就不一一展開了。但就中台服務多個內部業務產品為主的特點來說，會對中台產品經理有些不一樣的要求。在我個人的經歷裡，我認為有三點非常重要：

中台產品經理如何設計出用戶體驗好的功能？由於教育中台對其服務的要求是從前端到後端的完整服務（具體原因在技術部分介紹），因此教育中台的產品經理所設計的功能需要直接面對最終用戶，也需要保有良好的用戶體驗。

在上圖中，業務產品經理的能力要求偏向市場側，中台產品經理的能力要求偏向研發側，綠色部分是兩類產品經理都需要掌握的。教育中台對產品經理一直有要求，必須走到需求的源頭不能隻接二手需求。拋開個人能力而言，這對其提出的難度在於：必須花大量的精力去熟知不同的場景。

中台產品經理是按照功能模塊來劃分職責的（如題庫、直播），但實際的使用場景是用戶使用整體產品的全流程，並不會只看某個功能模塊，因此每個模塊的產品經理需要了解所支持的所有業務的全部場景，才能做好相關模塊的設計。同時教育行業是碎片化的，不同業務之前的場景差異性比較大，某模塊的中台產品經理如何才能快速的熟知所有業務的全部場景？這是一個難題。

中台產品經理和技術的分界線在哪裡？也許這不僅僅是做中台產品經理才需要考慮的問題，但在教育中台的很長一段時間內，我的疑問比以前任何時候都強烈。中台裡有太多的產品設計，可以由具備產品思維的研發人員來考慮，但更多時候，還是需要向技術深入一步的產品經理來組織研發人員一起設計。

舉個極端的例子：為了降低各個業務產品在各個端（前端、後端、移動端）接入中台服務時的配置管理難度，我曾考慮改進中台服務裡零散在各端代碼中的配置管理，做到集中管理並且可靈活配置。此外還拓展出支持未來可能的中台服務付費需求。為了描述清楚需求，我寫的 PRD 裡除了描述各種場景和功能外，還用偽代碼描述了如何使用。雖然偽代碼的水準可能會被研發同事鄙視，但達到了清晰表述問題的目的。

本文我無意提倡 PRD 裡要寫偽代碼，主要想要說明的是中台產品經理不要指望能夠和技術有清晰的界限，應該堅定的跨過去一步，同時也把產品思維帶到技術中去，搭起一座橋。

中台產品經理如何設計一個新功能模塊，讓它能夠滿足各方需求，且推動其在各個業務產品上使用起來？除了要求產品經理有極強的專業能力外，還需要具備極強的主動性、溝通能力、甚至是商務能力，在各個業務之間想盡辦法把中台的種子種下去。相關的經驗在在本文的「中台策略對組織架構的挑戰」部分做了介紹。

技術層面

在中台架構的設計之初，我們就定位了教育中台需要提供的不僅僅只是後端服務，一方面純後端服務和 PaaS 服務就沒太多區別；另一方面由於教育中台所希望提供的服務的業務屬性非常強，提供的服務複雜程度遠高於常見的 IM、視頻雲等常見 PaaS 服務，如果完全通過後端開放接口來使用，接口的數量會非常多，調用的邏輯關係也會很複雜，使用成本會遠高於常見的 PaaS 服務。

因此我們希望教育中台提供的是前後端一體的服務，最終展現給用戶的是前端模塊 / 組件。理想的情況下，業務產品的前台頁面只要嵌入中台某功能服務的前端模塊，就可以使用該模塊的完整功能。這種方式最大限度地拓展了中台服務的價值，但也給中台服務在設計中帶來巨大的難度。經過一年反覆的煎熬，我們也整理出了幾條設計原則：

1. 數據結構的統一是底線

理想情況下，教育中台搭建完一個模塊，各個業務產品一接入就能完美的用起來。但實際情況下沒有產品經理和研發具備這樣的能力，反覆是一定要的，甚至於有時候教育中台需要去做一個需求還不明確的功能（我通常反對中台新做功能來完成業務產品的需求驗證，ROI 太低了）。當面對這樣的情況時，一定要堅守的底線是數據結構的統一。研發同學都知道數據遷移是一個大坑，所以只要數據結構是統一的，任何邏輯和互動的變化都是可以接受的。

2. 前台界面通用的邊界

數據結構的統一、後端服務的共享，是容易在思想上達成一致的，難的部分只是在執行。但前端界面統一的觀點自始至終都在激烈的辯論中。對於一個 ToC 產品的產品經理和設計師來說，往往對互動、視覺都非常敏感，這也是 ToC 產品能夠在第一眼就留住用戶的最重要原因。

但中台服務為了做到重用，往往很難在一些細節的互動上和視覺層上，百分之百的滿足每個業務的需求。並且在這種用戶體驗的層面，往往沒有誰能夠說服誰。對於設計型的產品經理而言，不能把控自己產品界面裡的設計，簡直就是被褻瀆，因此在前端界面統一這件事情上的爭論有多激烈，可想而知，我自己在這件事情的立場上也有搖擺。在多個 case 的糾葛後，我們推動了幾件事情，不敢說解決了這個衝突，至少是改善了問題：

推動更新整個事業部產品的互動視覺規範。對於建立規範大家都是沒有疑問的，在互動規範不完善且沒有被嚴格執行的情況下，很多時候產品經理都需要為了一些互動細節大傷腦筋：比如編輯框裡字數超出了限制應該怎樣提示？諸如此類。當互動規範完善，且做成了 Axure 組件後，普通產品經理都有了升級成產品設計師的可能，基於規範和組件就可以做出一個完成度很高的互動稿。而視覺規範是整個事業部各產品統一品牌形象的條件，也是統一前端組件的基礎，設計在前端組件級達成一致是可以的。

根據用戶前台和管理後台加以區別對待。用戶前台是給終端用戶使用的，也是大量 C 端用戶直接接觸產品的入口，不同業務的用戶往往在互動和視覺上有不同的需求。而管理後台往往是給一些特殊用戶、比如管理員使用的，這類用戶首先數量相對少，後台操作也不那麽頻繁。且這類用戶在操作管理後台時具備 B 端用戶的屬性，很多時候是部門內的運營，對功能是否強大的敏感度高於視覺體驗。

因此教育中台盡量能在管理後台的前端界面上保持統一，而用戶前台頁面會考慮放開讓各個業務產品自己做。當然這一點很容易就可以找出反例，因此也只是在設計過程中的一個指導方向，並不是定理。

根據業務的目標用戶年齡層次進行區分。事業部有面向成人、K12、年齡更小的兒童等各個不同年齡階段用戶的產品。年齡越小的用戶對互動和視覺的要求越高，愛奇藝還專門推出了面向兒童的奇巴布。整個互動和視覺都做了重新設計。因此教育中台盡可能在面向成人的產品裡去做到前端界面通用，不考慮和面向低齡人群的產品有任何前端界面的複用。

3. 前後端直連

教育中台的用戶是部門其他業務產品線的程序員，雖然都是內部用戶，但降低用戶的使用成本是非常重要的，我在組織架構部分會詳細介紹。要想推動教育中台在內部業務的使用，必須要最大程度的降低用戶的使用成本。

第一年我們教育中台的別動隊在搭建服務驗證可行性時，服務的架構設計是這樣的：

業務產品的後端從教育中台的後端獲取數據後，通過業務產品的前端拚裝好再傳給教育中台的前端模塊進行顯示。這種方案其實等同於把一個模塊的開發按照人頭分工到兩個團隊來開發，理論上來說可以滿足任何業務的需求。早期在需求還不那麽確定、業務也比較少的時候，這樣去進行探索是可行的。但當接入的業務產品多起來，這種架構會帶來幾個很麻煩的問題：

業務產品的前端和後端都分別需要和教育中台的前端和後端直接對接，需要對教育中台的接口有很深入的了解，服務的接入成本非常高。

由於教育中台後端暴露的接口太多，很容易在後續更新時發生變動，從而導致所有已經接入的業務產品都需要發生代碼改動，並進行回歸測試。

為了解決上述問題，我們改成了前後端直連的架構設計：

在這種方式下：

教育中台的前後端是直接互動，可獨立運行的。

只需在前端層進行接入，接入成本大大降低。

只要有限的接口保證穩定，教育中台的升級對於業務產品是無感知的。

直連的架構在某些特定情況下會增加功能實現的難度，比如要在教育中台前端模塊裡去顯示其後端服務沒有的數據時，會面臨拿數據困難的問題。但總體來講帶來的好處遠遠大於增加的難度，我們也基本確定了前後端直連的架構是教育中台服務首選的方式。

中台策略對組織架構的挑戰

高層的支持重要嗎？

看過一篇文章「重新理解中台—中台的戰略和困境」，對中台在組織架構層面的需求做了比較好的介紹，其中最關鍵的就是：中台是自頂向下的，中台一定需要得到高層的支持。

和絕大多數商業化的事業部一樣，我所在事業部的 KPI 一直是可量化的營收數據。而中台項目在啟動運轉的相當長一段時間內，我們所做的很難對 KPI 有直接幫助，甚至於在局部較短時間內是阻礙當年 KPI 達成的。

大部分員工是很難站在一定的高度去做一個”看十年、做一年“的規劃，特別是當一件事和眼前的 KPI 難以達成平衡時，中台的工作會受到各個方面的挑戰。因此高層的堅定支持是中台戰略的第一必要條件。中台的價值是有條件的，搭建完成後還得有機會來享受成果，這個判斷也需要高層來完成。

此外高層還需要推動一些規範的建設，如互動規範、視覺規範、視覺配套的前端組件規範等，在這些規範的約束下，中台服務搭建的難度會大大降低。

各業務產品的支持重要嗎？

高層的支持是基礎，但在中台和業務產品實際工作中，無數次的碰撞都需要靠中台自己的影響力來推進。因此中台如何在各業務中獲得影響力，並推動各業務接入服務也是至關重要的。那麽如何推動業務產品接入中台服務呢？

直接利益就是人力成本節省。針對單個業務而言，他們最關心的就是接入中台服務能夠為其節省的成本，這個計算方式在後面的「中台價值量化」部分會介紹。

理念的灌輸。除了高層的直接支持外，中台的各負責人會時不時的在各種場合給業務的負責人和小夥伴「洗腦」，鼓吹共享服務的思想。

首先拉動的一定是研發人員，好的研發人員是有代碼潔癖的，即使他不得不在某些情況下寫出惡心的代碼。如果跟他們去聊抽象、架構和重用，天然就會產生親切感。

面對業務產品經理就往往需要做交換了——我可以在中台功能設計裡支持你的一個偏定製需求，但你得答應要接入我的另一個服務，我甚至於可以出人力幫你接入。

形成生態系統。當 iOS 和 Android 已經成為世界上最大的兩個移動端作業系統後，無論開發者多麽希望按照 Windows Phone 的標準做開發，也只能選擇 iOS 或 Android，這就是生態系統的力量。同理，當中台統一了各個業務的基礎服務後，上層的業務功能無論有多麽個性化的需求，都不能跳出基礎服務的限制。

而對於一個業務而言，放棄中台的底層服務、自己重新搭建一套系統也幾乎是不可執行的，這太不劃算了。無論該產品經理的主觀意願多麽強烈，在 ROI 的壓力下也很難獲得支持。當然，每個產品最初都需要一批種子用戶來實現冷啟動，中台服務最初也需要能有種子客戶來打磨產品，那麽應該找誰來合作呢？大家習慣性會想去找戰略型的重點業務產品，做成標杆客戶。但實際上重點業務產品往往人力充足，並且跑得飛快，一個還不太完善的中台服務想要直接跟此類產品合作是非常難的。

重點業務不在意成本，也不那麽在意質量，他們更在意的是速度，這和中台本身的定位是有矛盾的。因此，中台服務反而應該去找潛力型的業務產品進行合作。此類業務有著表現自己、贏得關注的欲望，但又苦於資源不足了，是非常有意願去借助中台的力量做事情的。

當然，中台支持此類業務產品需要承擔的風險就是：這個業務產品可能活不了多久就被老闆砍掉了。因此如何選擇具備潛力的產品，這就是需要中台負責人在戰略上能有敏銳判斷的地方了。

保留力量，去做重要不緊急的事情

由於互聯網公司多年來信奉的就是「唯快不破」，團隊在做優先級排序時，往往會傾向於去做業務價值最明顯的事情。有很多重要不緊急的工作就被壓在後面，永遠沒有再被提起過。但對中台產品團隊需要有不同的要求，中台產品一定要保留力量始終去做一些基礎的、重要不緊急的事情。

就好像公司如果想要做得長久，除了在商業上的持續投入外，一定要保留足夠的人力來做基礎性的研究，近期華為的海思芯片和鴻蒙作業系統就是最好的例子。

我們在做中台時，無論外部各個業務需求的壓力有多大，都應該始終保持有一個小隊在做基礎組件和規範建設。比如在各套業務產品裡的權限體系都還能跑、但某些功能始終無法完美支撐時，我們按照 RBAC 的方式進行一個新的角色權限系統的設計，並提供了數據遷移方法，也最後為新的業務模塊功能開發打下了基礎。

中台價值的量化

即使我們都認為一件事情是正確的，價值量化依然是最重要的事情之一。中台是一個 ToB 服務本質上是成本的節省和效率的提升，但由於中台的客戶是內部業務產品的程序員，這個價值的量化就變得比一個給銷售用的 CRM 系統要複雜了。

中台是提供給多個業務服務的共享服務，任意一個中台服務都可以為業務節省成本，因此被越多的接入，整體節省的成本越大。同時由於每個業務在整個事業部裡都有不同的優先級，被高優先級業務接入的中台服務，能夠產生的價值就更越大。這是符合直覺的，但如何去量化這樣的價值呢？提供以下的計算方法：

假設：

各個業務在事業部的優先級系數 = a1、a2、a3....；

中台服務被某一個業務接入後給業務節省的成本（人天） = 業務自研此服務的成本 + 業務自己運維 - 業務產品接入中台服務的成本。

可以推導出每個服務開發出來後對整個部門節省的成本是：

總體成本節省 = （a1*業務 1 節省 + a2*業務 2 節省 + ...）- 中台開發成本 - 數據遷移（適配層開發)）- 中台運維。

由於中台團隊要同時面對多個業務的需求，根據以上公式，我們也可以得出一些判斷需求優先級的基本規則：

部門戰略，也就是業務的優先級的系數。顯然來自戰略級業務的需求優先級是高於其他普通業務的；

需求靠譜程度。這裡麵包括兩個層次：

是否是核心的需求？是否是偽需求？

提出需求的業務是否靠譜？是否可能很快就被乾掉了？

與中台自身目標的契合程度。這也很好理解：中台不是業務的外包團隊，中台需要有自己的思想和規劃。

需要說明的是，雖然有了這樣的計算公式，但我們在實際工作中並沒有直接去量化每一個功能。主要原因在於教育中台正式立項一年的過程中，團隊一直在探索中台設計的套路，比如如何才能較好的滿足需求，快速的被接入，並且在運維層面對業務做到無感知。只有在搞清楚這些討論之後，中台服務才有可能會對節省成本有明顯的幫助。因此量化只是少數幾個團隊核心成員做規劃時的參考，而沒有直接做為產生的價值而公布出來。

青山綠水，江湖再見

從教育中台組的解散到今天，已經過去差不多五個月了。在寫此文時回憶起中台這一年，感慨萬千。

感謝兩位主管 Sunner 和 Genify，Sunner 作為中台業務負責人和產品架構師，親手搭建了整個教育中台的底層基礎和業務抽象，包括「愛多思」在內的很多特有的名字都是他取的。他是我直接的老師，他對愛多思能夠成功的信念、是我在多次迷惑中能堅持到最後的最主要原因。Genify 是研發負責人和技術架構師，從抽象的業務模型到實際可執行的技術方案，再到技術規範的形成，中間依然需要有一條靠經驗和想象力來架設的橋梁，而他就是這座橋梁。

感謝一起戰鬥過的和沒來得及深入合作的同事，這些思考和追憶屬於我們每一個人。

感謝部門老大，沒有他的支持，中台根本不可能立項。

青山不改，綠水長流，他日江湖再見，自當把酒言歡，就此別過。

作者介紹

何少甫，網易有道中國大學 MOOC 資深產品經理，所關注領域主要為在線教育和企業服務。

（標題有修改）