中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者依據工作中項目實踐的所思所想，并結合案例等分享了關于中臺建設的相關知識概念，梳理了中臺建設的基本流程，供大家一同參考和學習。

一、回顧

1. 故事的開端

2018年3月份，我正式成為一名中臺產品經理，在這之前的一兩個月，我已經和Sunner就中臺的發展有了多次溝通。我們要做一個在線教育領域的中臺產品-愛多思(EduOS)，顧名思義，就是一個在線教育的操作系統。

線下教育的教學工具有桌椅板凳，黑板、粉筆、投影儀這些教學設備，組合成物理世界的課堂，愛多思的目標是構建出線上教育里的桌椅板凳，讓其能夠自由組合成一整個在線教學管理系統(LMS)，并形成標準。

這是一個有挑戰的活：首先，當時中臺在互聯網公司是個新概念，如何在互聯網公司里做一個中臺，業界并沒有太多的成熟經驗可以參考；

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

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

中臺項目正式立項，我成為立項后第一個產品經理，Sunner是負責人和產品架構師。我們計劃用兩年時間把中臺搭建好，讓愛多思能夠支撐各條業務線的發展，并且能快速孵化出新的業務。

然而，一年過后，2019年2月底，因為公司戰略和組織架構調整，中臺項目被停止了。

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

2. 這一年的收獲

回顧這一年，我們做到了幾點：

1. 完成了多個教學服務的中臺化改造。其中包括一些底層的基礎服務，如賬號、權限、點播、直播等，也包括一些具備教學邏輯的模塊，如直播課、題庫、問卷等等，每個服務都可以單獨拿出來做成可直接給終端用戶使用的產品，類似于CCtalk、問卷星這樣的。并且這些服務和模塊都已經支持各業務產品了；
2. 總結出來中臺化產品設計、產品研發、項目管理的一些標準規范和套路。依照這些標準和套路，沒有中臺經驗的產品和技術人員也可以快速的開發出中臺服務，并被業務產品接入使用。

我們也還有一些沒完成的，包括：

1. 中臺教學系統的閉環。我們做了一些獨立的教學模塊，但還沒能夠用中臺化的標準把這些教學模塊完全組合起來，形成一個可以系統化學習的課程；
2. 中臺價值的量化體系。只有做好了價值量化這一點，我們才算完成了中臺在商業世界里的實踐，并且經驗可以被推廣到公司內外；
3. 中臺商業化的探索。我個人一直希望能夠把中臺做成一個可商業化的企業服務，不僅僅只是一個內部支持型的產品。

中臺項目停止后，我也依然在教育to B行業，時常在想，如果有了成熟的中臺能夠對現在的問題有什么幫助。

現在看起來，在國內目前的商業環境下，一個好的中臺在對內服務產生的價值還是會遠遠高于對外直接輸出的價值的，慶幸當年Sunner壓制住了我想快速商業化的訴求。

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

此外對于我個人而言，這是我能夠再沉下來打基礎，這一年收獲良多：

1. 進入互聯網行業后，小步快跑成了常態。而在中臺的這段時間我難得能夠暫時放開業務的壓力，按照近乎理想化的標準去進行產品架構設計、做抽象、畫UML、花時間仔細思考。我本不是這樣的人，這也算是在刻意練習了；
2. 作為一個在線教育行業的新人，通過中臺我能有機會能夠參與整個事業部涉及的所有教育業務，K12、成人、to C、to B，讓我對在線教育行業有了一個更全面的認識，從中尋找興趣所在；
3. 結識了一幫優秀而有趣的小伙伴，大家一起做有挑戰的事情，也才有了這篇文章里的回憶。

二、什么是中臺

1. IT行業的中臺

中臺是近年來IT行業非常火的概念，有很多的文章從產品、技術、組織等多個角度來解釋什么是中臺，對于一個快速變化的新概念而言，很難有標準定義，阿里中臺某高管都提到過現在阿里所做到的距離他理想的中臺還有一段距離。

給定義是需要非常謹慎的事情，但很多時候不給定義又沒辦法繼續聊，所以我也曾經在一個內部分享上給中臺做了定義「服務于某個垂直領域的工具平臺」。

在做這個定義時，我是參考了云計算的概念的。云計算是一種通用服務，那么中臺和云計算有什么差別呢？按照Iaas/Paas/Saas來劃分，服務的領域越來越垂直。參考這種方式，我會將中臺定位在Paas和Saas之間，主要是這樣考慮的：

1. Paas提供了一種服務，客戶的程序員通過二次開發使用Paas服務，最終完成某個功能給最終用戶。Paas的通用程度需要非常強以獲得足夠大的市場，比如IM、視頻云服務等。也因此Paas往往是沒有界面的；
2. Saas提供的服務不需要客戶進行開發，只需要開通服務，在管理后臺上配置一下就可以直接使用。但Saas服務往往針對的是一個細分領域，其定制化能力也相對弱很多。即使是像釘釘，選擇IM這種企業中最通用化的服務，同時做成企業服務的開放生態，也主要是覆蓋中小企業。定制化需求強的大客戶，也往往會需要希望借助IM Paas服務來自主研發內部IM工具；
3. Paas和Saas定位在服務外部客戶的，必須具備很低的使用成本。即使是需要通過技術來接入的Paas服務，接入成本也一定要足夠低，接口清晰，文檔完善；
4. 中臺首先是定位在服務內部公司客戶的，由于這個范圍的限定，導致中臺的通用可以在很多約束條件下來實現，可服務的領域比Saas廣。比如即使同樣是電商，淘寶、天貓、聚劃算、閑魚、飛豬的站點都是不一樣的，而阿里共享事業部就在中臺層服務多個業務。此外，由于中臺的用戶是內部業務的程序員，大家有相似的背景，也可以頻繁溝通，服務接入的成本可以做得比面向外部客戶的Paas要高。

2. 中臺 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年的區塊鏈。同時我也聽說有創業公司連核心業務的商業模式還沒摸清楚，上來就要搭建中臺的。這其實是沒搞清楚為什么要建中臺，要解決什么問題。

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

其次，中臺的目標是提高業務產品的研發效率，但為了達到這個目的，在一段時間內是需要以降低「效率」為代價的，時間長短取決于系統復雜度和團隊能力的差距。當公司隨著業務發展，需要研發第二個、第三個產品等等，在這種情況下可能會有兩種方式來構建中臺：

1. 新產品和技術架構都是繼承自當前產品，不斷的通過優化當前產品架構來適應新的產品，讓中臺服務自然沉淀出來。這種情況下的前提條件是在做第一個產品時就做好了服務架構設計，即便如此，在第二個產品時很有可能要走彎路，不能滿足新產品那快速迭代和試錯的渴望。但到了第三個、第四個產品，就變得越來越快了。
2. 新的產品和技術架構都是從新設計，這樣做每個產品的速度都差不多，靈活度也能做到最高。但每個產品都很難在技術上從前面的產品借力，當團隊人員發生變動，產品越來越多，多分支的維護和開發就凸顯了人力不足的問題，需要搭建一個中臺。這也是我們面臨的問題。

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

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

當然我們也可有另外的選擇，即砍掉大部分產品，只專注做到一兩個。但大家都知道，其實真正困難的不是決定做什么，而是決定不做什么，這種決策其實比做中臺更加困難。

此外，從作為一家成熟的公司，一定是需要有能夠形成合力的產品矩陣來支撐整個公司的戰略推進，所以多產品并行是公司發展到一定階段的必然產品，而做中臺也絕不是站在其中某一個產品的角度來解決問題，而是站在多產品協同的角度來看公司的戰略。

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

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

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

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

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

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

一方面是設計質量。中臺的團隊通常會以功能模塊為劃分，專職負責某功能模塊的團隊往往會更有意愿去突破一些難點，成為最懂此功能模塊的團隊。

比如現在教育領域最熱門的授課方式就是直播課，而直播功能就是一個有較高門檻的功能模塊。

要想做出適合業務發展的直播功能，需要對云計算、計算機網絡、直播授課方法、直播運營等多個方面都有較為深入的了解。這需要團隊能夠有一定程度的積累，不是某一個業務產品的研發團隊里找幾個人就能很快突擊出來的；

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

四、我們是怎么做中臺的

1. 產品設計層面

隨著中臺日益火爆，如何做中臺產品經理也成了一個新的職業發展熱點，最近也看到有了線上的中臺產品經理課程。中臺產品經理是B端產品經理的一種類型，有B端通用的能力要求，比如擅長做抽象建模、具備一定的研發技術功底、懂UML等，不一一展開。

但就中臺服務多個內部業務產品為主的特點，會對中臺產品經理有些不一樣的要求。我個人的經歷里有三點非常重要：

（1）中臺產品經理如何設計出用戶體驗好的功能？

由于教育中臺對其服務的要求是從前端到后端的完整服務(具體原因在技術部分介紹)，因此教育中臺的產品經理設計的功能需要直接面對最終用戶，也需要保有良好的用戶體驗。

在上圖中，業務產品經理的能力要求偏市場側，中臺產品經理的能力要求靠偏研發側，綠色部分是兩類產品經理都需要掌握的。教育中臺對產品經理一直有要求，必須走到需求的源頭不能只接二手需求。

拋開個人能力而言，這對其提出的難度在于，必須花大量的精力去熟知不同的場景。中臺產品經理是按照功能模塊來劃分職責的(如題庫、直播)，但實際的使用場景是用戶使用整體產品的全流程，并不會只能看某個功能模塊，因此每個模塊的產品經理需要了解所支持的所有業務的全部場景才能做好相關模塊的設計。

同時教育行業是碎片化的，不同業務之前的場景差異性比較大，某模塊的中臺產品經理如何才能快速的熟知所有業務的全部場景，這是一個難題。

（2）中臺產品經理和技術的分界線在哪里？

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

舉個極端的例子，為了降低各個業務產品在各個端(前端、后端、移動端)接入中臺服務時的配置管理難度，我曾考慮改進中臺服務里零散在各端代碼中的配置管理，做到集中管理并且可靈活配置，還拓展出支持未來可能的中臺服務付費需求；

為了描述清楚需求，我寫的PRD里除了描述各種場景和功能外，還用偽代碼描述了如何使用，雖然偽代碼的水平可能會被研發同事鄙視，但達到了清晰表述問題的目的。

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

（3）中臺產品經理如何設計一個新功能模塊能夠滿足各方需求，且推動其在各個業務產品上使用起來？

除了要求產品經理有極強的專業能力外，還需要具備極強的主動性、溝通能力、甚至是商務能力，在各個業務之間想盡辦法把中臺的種子種進去。相關的經驗在在本文的「組織架構層面」部分做了介紹。

2. 技術層面

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

因此我們希望教育中臺提供的是前后端一體的服務，最終展現給用戶的是前端模塊/組件。

理想的情況下，業務產品的前臺頁面只要嵌入中臺某功能服務的前端模塊，就可以使用該模塊的完整功能。這種方式最大限度的拓展了中臺服務的價值，但也給中臺服務在設計中帶來巨大的難度。經過一年反復的煎熬，我們也整理出了幾條設計原則：

（1）數據結構的統一是底線

理想情況下，教育中臺搭建完一個模塊，各個業務產品一接入就能完美的用起來。但實際情況下沒有產品經理和研發具備這樣的能力，反復是一定要的，甚至于有時候教育中臺需要去做一個需求還不明確的功能(我通常反對中臺新做功能來完成業務產品的需求驗證，ROI太低了)。

當面對這樣的情況時，一定要堅守的底線是數據結構的統一。研發同學都知道數據遷移是一個大坑，所以只要數據結構是統一的，任何邏輯和交互的變化都是可以接受的。

（2）前臺界面通用的邊界

數據結構的統一，后端服務的共享是容易在思想上達成一致的，難的部分只是在執行。但前端界面的統一的觀點自始至終都在激烈的辯論中。

對于一個2C產品的產品經理和設計師，往往對交互、視覺都非常敏感，這也是2C產品能夠在第一眼就留住用戶的最重要的點。但中臺服務為了做到重用，往往很難在一些細節的交互、視覺層百分之百的滿足每個業務的需求，并且在這種用戶體驗的層面，往往沒有誰能夠說服誰。

對于設計型的產品經理而言，不能把控自己產品界面里的設計，簡直就是被褻瀆，因此在前端界面統一的這件事情的爭論有多激烈可想而知，我自己也在這件事情的立場也有搖擺。在多個case的糾葛后，我們推動了幾件事情，不敢說解決了這個沖突，至少是改善了問題：

1）推動更新整個事業部產品的交互視覺規范。

對于建立規范大家都是沒有疑問的。在交互規范不完善且沒有被嚴格執行的情況下，很多時候產品經理都需要為了一些交互細節大傷腦筋，比編輯框里字數超出了限制應該怎樣提示，諸如此類。

當交互規范完善，且做成了Axure組件后，普通產品經理都有了升級成產品設計師的可能，基于規范和組件就可以做出一個完成度很高的交互稿。而視覺規范是整個事業部各產品統一品牌形象的條件，也是統一前端組件的基礎，設計在前端組件級達成一致是可以的。

2）根據用戶前臺和管理后臺加以區別對待。

用戶前臺是給終端用戶使用的，也是大量C端用戶直接接觸產品的入口，不同業務的用戶往往在交互和視覺上有不同的需求。

而管理后臺往往是給一些特殊用戶，比如管理員使用的。這類用戶首先數量相對少，后臺操作也不那么頻繁，且這類用戶在操作管理后臺時具備B端用戶的屬性，很多時候是部門內的運營，對功能是否強大的敏感度高于視覺體驗。

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

3）根據業務的目標用戶年齡層次進行區分。

事業部有面向成人、K12、年齡更小的兒童等各個不同年齡階段用戶的產品。年齡越小的用戶對交互和視覺的要求越高，愛奇藝還專門推出了面向兒童的奇巴布，整個交互和視覺都做了重新設計。

因此教育中臺盡可能在面向成人的產品里去做到前端界面通用，不考慮和面向低齡人群的產品有任何前端界面的復用。

（3）前后端直連

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

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

業務產品的后端從教育中臺的后端獲取數據后，通過業務產品的前端拼裝好再傳給教育中臺的前端模塊進行顯示。這種方案其實等同于把一個模塊的開發按照人頭分工到兩個團隊來開發，理論上來說可以滿足任何業務的需求。

早期在需求還不那么確定業務也比較少的時候，這樣去進行探索是可行的。但當接入的業務產品多起來，這種架構會帶來幾個很麻煩的問題：

1. 業務產品的前端和后端都分別需要和教育中臺的前端和后端直接對接，需要對教育中臺的接口有很深入的了解，服務的接入成本非常高；
2. 由于教育中臺后端暴露的接口太多，很容易在后續更新時發生變動，從而導致所有已經接入的業務產品都需要發生代碼改動，并進行回歸測試。

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

在這種方式下：

1. 教育中臺的前后端是直接交互，可獨立運行的；
2. 只需在前端層進行接入，接入成本大大降低；
3. 只要有限的接口保證穩定，教育中臺的升級對于業務產品是無感知的。

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

3. 組織架構層面

（1）高層的支持

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

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

大部分員工是很難站在一定的高度去做看十年做一年的規劃，特別是當一件事和眼前的KPI難以達成平衡時，中臺的工作會受到各個方面的挑戰。因此高層的堅定支持是中臺戰略的第一必要條件。

中臺的價值是有條件的，搭建完成后還得有機會來享受成果，這個判斷也需要高層來完成。 此外高層還需要推動一些規范的建設，如交互規范、視覺規范、視覺配套的前端組件規范等，在這些規范的約束下，中臺服務搭建的難度會大大降低。

（2）各業務產品的支持

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

那么如何推動業務產品接入中臺服務呢？

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

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

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

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

形成生態系統。當iOS和android已經成為世界上最大的兩個移動端操作系統后，無論開發者多么希望按照Windows Phone的標準做開發，他也只能選擇iOS或android，這就是生態系統的力量。

同理，當中臺統一了各個業務的一些基礎服務后，在上層的業務功能無論有多么個性化的需求，都不能跳出基礎服務的限制。而對于一個業務而言，放棄中臺的底層服務自己重新搭建一套也幾乎是不可執行的，太不劃算了，無論該產品經理的主觀意見多么強烈，在ROI的壓力下也很難獲得支持。

當然，每個產品最初都需要一批種子用戶來實現冷啟動，中臺服務最初也需要能有種子客戶來打磨產品，那么應該找誰來合作呢？

大家習慣性會想去找戰略型的重點業務產品，做成標桿客戶。但實際上重點業務產品往往人力充足，并且跑得飛快。一個還不太完善的中臺服務想要直接跟此類產品合作是非常難的。他不在意成本，對質量不那么在意，更在意的是速度，這就是和中臺本身的定位是有矛盾的。

因此，中臺服務反而應該去找潛力型的業務產品進行合作。此類業務有著表現自己贏得關注的欲望，但又苦于資源不足很多事情都做不了，是非常有意愿去借助中臺的力量做事情的。

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

（3）重要不緊急的事情始終在推進

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

但對中臺產品團隊需要有不同的要求，中臺產品一定要保留力量始終去做一些基礎的，重要不緊急的事情，就好像公司如果想要做得長久除了在商業上的持續投入外，一定要保留足夠的人力來做基礎性的研究，近期華為的海思芯片和鴻蒙操作系統就是最好的例子。

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

（4）中臺價值的量化

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

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

提供以下的計算方法：

假設：

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

中臺服務被某一個業務接入后給業務節省的成本(人天) = 業務自研此服務的成本 + 業務自己運維 – 業務產品接入中臺服務的成本

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

總體成本節省 = (a1 * 業務1節省 + a2 * 業務2節省 + …) – 中臺開發成本 – 數據遷移(適配層開發) – 中臺運維

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

1. 部門戰略，也就是業務的優先級的系數。顯然來自戰略級業務的需求優先級是高于其他普通業務的。
2. 需求靠譜程度。這里面有包括兩個層次：是否是核心的需求，是否是偽需求、提出需求的業務是否靠譜，是否可能很快就被干掉了
3. 與中臺目標自身目標的契合程度。這也是很好理解。中臺不是業務的外包團隊，中臺需要有自己的思想和規劃。

需要說明的是，雖然有了這樣的計算公式，但我們在實際的工作中并沒有直接去量化每一個功能。主要原因在于教育中臺正式立項一年的過程中，團隊一直在探索中臺設計的套路，比如對如何才能較好的滿足需求，快速的被接入，并且在運維層面對業務做到無感知。

只有在搞清楚這些討論之后，中臺服務才有可能會對節省成本有明顯的幫助。因此量化只是少數幾個團隊核心成員做規劃時參考，而沒有直接做為產生的價值而公布出來。

青山綠水，江湖再見

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

感謝兩位主管Sunner和Genify，Sunner作為中臺業務負責人和產品架構師，親手搭建了整個教育中臺的底層基礎和業務抽象，包括「愛多思」在內的很多特有的名字都是他取的。他是我直接的老師，他對愛多思能夠成功的堅定信念是我在多次迷惑中也能堅持到最后的最主要原因。

Genify是研發負責人和技術架構師，從抽象的業務模型到實際可執行的技術方案，再到技術規范的形成，中間依然需要有一條靠經驗和想象力來架設的橋梁，而他就是這座橋梁。

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

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

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

本文由 @何少甫 原創發布于人人都是產品經理。未經許可，禁止轉載。

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