大型企業面對快速變化的市場形勢，需要有像創業公司一樣快速的反應能力。然而由于復雜的人員和層級關系，大企業做到“擁抱變化”是很困難的。

傳統以職能部門分治的樹狀組織架構，若一個底層員工有個好點子，就不得不自下而上說服管理層，管理層還需發動行政力量推動層層下屬，任何一環出了問題就難以進行，其難度可想而知。而各業務線各自有KPI，互相協作非常困難。

傳統公司的組織架構

即使說服老大，克服重重困難，從各部門抽調和招兵買馬，成立了新的業務部門。然而市場變化非常快，一旦業務受阻，方向轉換，花費巨大精力組成的業務線何去何從？此時部門的發展極大地依賴于老大的決策，底層活力不足。

大型組織想出各種方式解決這樣的問題，例如阿里在2016年提出了“大中臺小前臺”的戰略，將業務共同的工具和技術予以沉淀，成立專門的中臺部門。這樣新的項目可以重用中臺服務而不用重新設計，避免重復功能建設和維護帶來的浪費和山頭林立。這樣做的不只是企業，美軍更是設計了新的戰斗方式，每3人一個小組，戰斗需要時可隨時調集后方火力，信息和后勤支援，靈活而成本低廉。

中臺+小隊模式

程序員對這些概念更是熟悉，中臺類比到編程領域，就是形成可復用的函數庫，抽象共性，減少重復開發，提升迭代效率。中臺將人力，技術和服務重新組織，例如，數據中臺維護底層數據能力，內容中臺將各類資訊匯總整理，供給各業務線豐富的資訊資源；推薦營銷中臺抽象推薦系統的共性，為各種業務提供營銷的快速接入能力。這樣也方便統一協調，如數據中臺可根據業務優先級管理流量和負載分配，這在各部門獨立運營時是不可想象的。當然，中臺還有一大好處：分擔風險，方便分黑鍋，你懂的。

當然，不是所有公司都能實現中臺戰略，中臺要求扁平化的管理模式，沒有太多的條條框框。靈活的考勤，沒有隔板的工位，統一的基礎設施（如數據庫和代碼庫），否則中臺就是空中樓閣，實施起來甚為困難。

中臺模式的困擾

如果中臺模式全部都是好處，這篇文章就應該結束了。中臺相比于傳統模式雖有優勢，但實踐和理論的隔閡必然存在。中臺該做不該做什么，如何與業務方良好協同，如何評估KPI都成了難題。

我們可以根據中臺對業務方的參與度，繪制成下面的一張圖。

中臺對業務的參與度

軸的最左邊：僅提供工具庫和少量答疑維護，不對業務效果負責。絕大多數開源項目，各種數據庫，都可以歸于這種極端。

軸的最右邊：all-in參與業務方的大部分流程，從運營業務，到數據模型，事無巨細。我們戲稱其為“高級外包”。

我們形象地稱其為左傾和右傾問題。

越往左走，工具抽象和通用能力強，賦能業務多，雨露均沾，研發人員能專注于技術本身。但越往左越好么？不一定。越左就無法深入業務場景，無法接受業務滋養，很可能故步自封，甚至為了技術而技術，變得學究派，而過于獨立的中臺變成了純后臺，更重要的是，如何評估業務產出？

在最右面則是另一種極端，其優點非常明顯：此時中臺完全融入業務，有完整的業務sense，非常理解并能快速應對需求，與業務方打成一片，戲稱為“高級外包”。但是，該模式的人力一般只能覆蓋單一業務，很難對外輻射。由于精力所限，技術人員過分關注業務，中臺的技術深度就會相對較差。

我們要同時警惕這兩種極端，但從整體來看，最容易被忽視的反而是右傾。右傾構建了看似美好的中臺合作模式，親密無間的服務，但是人們很容易忽略其問題：由于過分具象和強耦合，中臺能力難以沉淀在通用的工具和理論上，當出現其他相關業務時，原有產品并不能支持，應對變化的能力小，一旦業務方向變化就可能前功盡棄。

此時由于中臺容量有限，過重的服務模式導致只能覆蓋有限的業務。中臺不得不評估前臺項目的重要程度，甚至拒絕為低優先級的前臺提供支持，挑肥揀瘦。那么前臺可能會為自己的業績考慮去自行組團隊完成項目，進而導致中臺與前臺隔閡。相反的，若事無巨細地參與到業務方，侵入性就會很強，人的問題會成為最大的問題：它可能會架空業務方人員，引起猜疑，甚至可能被并入業務方，導致中臺骨干流失。

那什么才是合理的中臺模式呢？

合理中臺模式的探索

最好的服務應該像空氣一樣，不留意就感受不到存在，但不可或缺。

首先，中臺必須有對應領域過硬的能力積累，例如算法中臺需要有扎實的理論基礎，搜索中臺在搜索能力的積累更是要達到業務方遠達不到的程度。打鐵還需自身硬，否則被革命掉只是時間問題。

中臺一方面提供服務，另一方面則促進人和人的交流，推動換位思考。原本不同方向的人為了共同的任務在一起工作，能夠迅速地學習對方的能力。當任務告一段落后，我們需要關注：業務方是否能維護，改進甚至優化中臺的工作和技術；中臺是否能產生對業務的通盤理解和技術沉淀。因此，在合作剛開始時，可適當右傾，中臺快速熟悉業務，建立共識；隨著業務深入，業務方吸收消化，中臺逐漸后撤，直到業務方可自行處理大部分問題。

一般來說，在提供相同服務質量的前提下，對業務問題的抽象能力越好，參與度就能越往左。 例如SQL確實是非常偉大的發明，它將數據處理的需求抽象地如此淋漓盡致，技術人員能夠專精于性能優化，業務方能靈活操作數據庫，完成業務任務。

因此，中臺有個重要命題應當考慮：自己的服務和技術應該如何合理抽象，將業務和底層盡可能隔離開來？這套領域特定語言(DSL)應該如何設計，才能讓業務方也能看得懂，用得好？? Tensorflow和Keras這類深度學習框架成功的一大部分原因，就是設計了非常良好的深度學習原語。越好的抽象和領域原語，就越能發揮前臺人員的業務優勢和主觀能動性，極大地提升了溝通效率。

同樣，業務方也必須能把自己面臨的問題予以清晰地描述，參數，環境和目標至少能明白地寫在一張紙上。提出模糊的，太過抽象的(比如不管用什么方式，只要能提升KPI)，甚至不切實際的目標，就是業務方的懶政和甩鍋，中臺不是高級外包。在任務層面上，兩邊應有清晰的分界和明確的問題，大家都精力有限，應做好分內之事。

在溝通上，不僅需要主管之間的密切配合，建立緊密溝通機制，如定期參與前端的業務周會；同時還應有清晰的接口人機制。筆者見過不少例子：多個接口人導致信息冗雜，傳播不暢，有時不得不十幾個人開大會，導致反復溝通，效率很低。接口人需要明確業務問題，熟悉數據鏈路，溝通能力強，方能事半功倍。

接口和分界清晰的中臺分工

結語

一切事業都需要由人來推動，大部分問題都是人的問題。組織形式的不同，會導致信息傳遞效率的極大不同，進而影響事業的成敗。“組織架構排名第二的公司，最后在市場上也只能居于老二的位置。”

本文只是筆者作為某大型公司的基層中臺工程師，面對業務合作中遇到問題的一些思考，由于視角限制，肯定有以偏概全甚至偏激之處，還請各位讀者老爺海涵。為什么要寫這篇文章？因為研究如何利用零和博弈，組織一幫聰明人，高效地為了同一個目標奮斗是非常有意思的，組織架構的設計很值得思考。當然由于篇幅所限，還有很多問題沒有討論，比如如何考核中臺績效？

拿著 5000 塊的工資，操著 5000 億富豪的心吶。

總結

以上是生活随笔為你收集整理的大型科技公司架构：中台模式的爱与恨的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。