大型企業面對快速變化的市場形勢，需要有像創業公司一樣快速的反應能力。然而由於復雜的人員和層級關系，大企業做到“擁抱變化”是很困難的。
傳統以職能部門分治的樹狀組織架構，若一個底層員工有個好點子，就不得不自下而上說服管理層，管理層還需發動行政力量推動層層下屬，任何一環出了問題就難以進行，其難度可想而知。而各業務線各自有KPI，互相協作非常困難。
(傳統的組織架構)
即使說服老大，克服重重困難，從各部門抽調和招兵買馬，成立了新的業務部門。然而市場變化非常快，一旦業務受阻，方向轉換，花費巨大精力組成的業務線何去何從？此時部門的發展極大地依賴於老大的決策，底層活力不足。
大型組織想出各種方式解決這樣的問題，例如阿里在2016年提出了“大中台小前台”的戰略，將業務共同的工具和技術予以沉淀，成立專門的中台部門。這樣新的項目可以重用中台服務而不用重新設計，避免重復功能建設和維護帶來的浪費和山頭林立。這樣做的不只是企業，美軍更是設計了新的戰斗方式，每3人一個小組，戰斗需要時可隨時調集后方火力，信息和后勤支援，靈活而成本低廉。
程序員對這些概念更是熟悉，中台類比到編程領域，就是形成可復用的函數庫，抽象共性，減少重復開發，提升迭代效率。中台將人力，技術和服務重新組織，例如，數據中台維護底層數據能力，內容中台將各類資訊匯總整理，供給各業務線豐富的資訊資源；推薦營銷中台抽象推薦系統的共性，為各種業務提供營銷的快速接入能力。這樣也方便統一協調，如數據中台可根據業務優先級管理流量和負載分配，這在各部門獨立運營時是不可想象的。當然，中台還有一大好處：分擔風險，方便分黑鍋，你懂的。
當然，不是所有公司都能實現中台戰略，中台要求扁平化的管理模式，沒有太多的條條框框。靈活的考勤，沒有隔板的工位，統一的基礎設施（如數據庫和代碼庫），否則中台就是空中樓閣，實施起來甚為困難。
中台模式的困擾
如果中台模式全部都是好處，這篇文章就應該結束了。中台相比於傳統模式雖有優勢，但實踐和理論的隔閡必然存在。中台該做不該做什么，如何與業務方良好協同，如何評估KPI都成了難題。
我們可以根據中台對業務方的參與度，繪制成下面的一張圖。
軸的最左邊：僅提供工具庫和少量答疑維護，不對業務效果負責。絕大多數開源項目，各種數據庫，都可以歸於這種極端。
軸的最右邊：all-in參與業務方的大部分流程，從運營業務，到數據模型，事無巨細。我們戲稱其為“高級外包”。
我們形象地稱其為左傾和右傾問題。
越往左走，工具抽象和通用能力強，賦能業務多，雨露均沾，研發人員能專注於技術本身。但越往左越好么？不一定。越左就無法深入業務場景，無法接受業務滋養，很可能故步自封，甚至為了技術而技術，變得學究派，而過於獨立的中台變成了純后台，更重要的是，如何評估業務產出？
在最右面則是另一種極端，其優點非常明顯：此時中台完全融入業務，有完整的業務sense，非常理解並能快速應對需求，與業務方打成一片，戲稱為“高級外包”。但是，該模式的人力一般只能覆蓋單一業務，很難對外輻射。由於精力所限，技術人員過分關注業務，中台的技術深度就會相對較差。
我們要同時警惕這兩種極端，但從整體來看，最容易被忽視的反而是右傾。右傾構建了看似美好的中台合作模式，親密無間的服務，但是人們很容易忽略其問題：由於過分具象和強耦合，中台能力難以沉淀在通用的工具和理論上，當出現其他相關業務時，原有產品並不能支持，應對變化的能力小，一旦業務方向變化就可能前功盡棄。
此時由於中台容量有限，過重的服務模式導致只能覆蓋有限的業務。中台不得不評估前台項目的重要程度，甚至拒絕為低優先級的前台提供支持，挑肥揀瘦。那么前台可能會為自己的業績考慮去自行組團隊完成項目，進而導致中台與前台隔閡。相反的，若事無巨細地參與到業務方，侵入性就會很強，人的問題會成為最大的問題：它可能會架空業務方人員，引起猜疑，甚至可能被並入業務方，導致中台骨干流失。
那什么才是合理的中台模式呢？
合理的中台
最好的服務應該像空氣一樣，不留意就感受不到存在，但不可或缺。
首先，中台必須有對應領域過硬的能力積累，例如算法中台需要有扎實的理論基礎，搜索中台在搜索能力的積累更是要達到業務方遠達不到的程度。打鐵還需自身硬，否則被革命掉只是時間問題。
中台一方面提供服務，另一方面則促進人和人的交流，推動換位思考。原本不同方向的人為了共同的任務在一起工作，能夠迅速地學習對方的能力。當任務告一段落后，我們需要關注：業務方是否能維護，改進甚至優化中台的工作和技術；中台是否能產生對業務的通盤理解和技術沉淀。因此，在合作剛開始時，可適當右傾，中台快速熟悉業務，建立共識； 隨着業務深入，業務方吸收消化，中台逐漸后撤，直到業務方可自行處理大部分問題。
一般來說，在提供相同服務質量的前提下，對業務問題的抽象能力越好，參與度就能越往左。 例如SQL確實是非常偉大的發明，它將數據處理的需求抽象地如此淋漓盡致，技術人員能夠專精於性能優化，業務方能靈活操作數據庫，完成業務任務。
因此，中台有個重要命題應當考慮：**自己的服務和技術應該如何合理抽象，將業務和底層盡可能隔離開來？這套領域特定語言(DSL)應該如何設計，才能讓業務方也能看得懂，用得好？ **Tensorflow和Keras這類深度學習框架成功的一大部分原因，就是設計了非常良好的深度學習原語。越好的抽象和領域原語，就越能發揮前台人員的業務優勢和主觀能動性，極大地提升了溝通效率。
同樣，業務方也必須能把自己面臨的問題予以清晰地描述，參數，環境和目標至少能明白地寫在一張紙上。提出模糊的，太過抽象的(比如不管用什么方式，只要能提升KPI)，甚至不切實際的目標，就是業務方的懶政和甩鍋，中台不是高級外包。在任務層面上，兩邊應有清晰的分界和明確的問題，大家都精力有限，應做好分內之事。
在溝通上，不僅需要主管之間的密切配合，建立緊密溝通機制，如定期參與前端的業務周會；同時還應有清晰的接口人機制。筆者見過不少例子：多個接口人導致信息冗雜，傳播不暢，有時不得不十幾個人開大會，導致反復溝通，效率很低。接口人需要明確業務問題，熟悉數據鏈路，溝通能力強，方能事半功倍。
結語
一切事業都需要由人來推動，大部分問題都是人的問題。組織形式的不同，會導致信息傳遞效率的極大不同，進而影響事業的成敗。“組織架構排名第二的公司，最后在市場上也只能居於老二的位置。”
本文只是筆者作為某大型公司的基層中台工程師，面對業務合作中遇到問題的一些思考，由於視角限制，肯定有以偏概全甚至偏激之處，還請各位讀者老爺海涵。為什么要寫這篇文章？因為研究如何利用零和博弈，組織一幫聰明人，高效地為了同一個目標奮斗是非常有意思的，組織架構的設計很值得思考。當然由於篇幅所限，還有很多問題沒有討論，比如如何考核中台績效？
拿着 5000 塊的工資，操着 5000 億富豪的心吶。