中臺這一概念，在近幾年在國內大熱，不少企業接連開始組織架構的調整，意圖建設中臺。但建設中臺，并非這么容易，可能投了不少錢，最后也沒有什么水花，那么中臺為什么難做？作者在這篇文章中給出了解答，一起來看看吧。

01 中臺到底是什么？

狹義上來講：我們知道前臺是一個個面向用戶的可視化操作界面。

后臺是包含代碼、中間件、數據庫等一系列框架代碼集。

后臺搭建完，前臺就會展現出來，一個閉環就形成了。

那什么是中臺？顧名思義中臺其實就是在夾在前臺和后臺之間的一個東西。

那為啥前后臺已經能形成閉環了還需要中臺？

大家一定聽過一個被講了很多次的故事：阿里在發展業務的過程中發現，隨著業務線的快速增加，一開始只有一個1688，后來出現了淘寶、阿里媽媽、支付寶、咸魚、口碑等等大量的內部項目。

每個項目都需要開發一個所謂的前后臺閉環，阿里內部100個業務，就得搞至少100個閉環，1個閉環算他50個人的開發測試團隊，大業務線還不止，就得5000個員工，這在以人員成本為最大成本的互聯網公司，簡直是要命。

當然成本還不是最關鍵的，最關鍵的是效率，在互聯網快速發展的階段，效率是生命線，你比別人上線晚、迭代晚，可能就玩不過人家了。

所以只能拼命堆人做，與時間賽跑。

雖然這個思路是對的，但是抵不過幾個問題?。?/p>

1. 那會很多項目都是通過市場測出來能不能成的，失敗率很高，很可能跑不出來，這樣這個團隊怎么辦，調到其他部門？流動性太高，團隊成本也打水漂了
2. 很多項目的重復性很高，其中的很多模塊都可以通用，每次都重新做一遍成本太高了
3. 如果每次都要從0開發，哪怕堆人搞，其實響應效率也很低，一般一個從0啟動的項目打底1個月起上線

于是馬云大腿一拍，搞中臺，中臺能全部解決上面的問題，還能大大降低成本。

怎么搞呢？

就是把一些通用性很高的模塊，抽出來，作為公共庫的一個個“能力”，然后A業務需要這個了，來拿一下直接用，B業務需要那個了，來拿一下直接用。

大家一定會說，很像開放平臺??！對，本質上其實就是個對內的開放平臺。

于是每個新業務就不需要那么多研發人員了，通用的模塊就不用重新開發了，在既有的中臺能力庫上做功能，對業務的響應效率也會高出一個層次。

這么一想，中臺簡直是一個大殺器??！

于是阿里就大刀闊斧的開始搞中臺建設，花了幾年時間，終于陸續建成了。

這期間，隨著阿里的如日中天，江湖上吹中臺的聲音到處都是，管他大公司、小公司、做業務、還是做平臺，做全品類，還是做垂直，都是在鼓吹應該要做中臺。

不少公司投入了好多錢，也沒做出個什么水花來。甚至阻力重重，推到一半就推不下去了。

然而后來阿里又親自“推倒”了自己的中臺計劃，把中臺的服務能力拆分的更小。

一時間唱衰中臺的聲音又此起彼伏。

02 中臺為什么難做？

歸根到底，看似預期很強大的中臺建設，存在以下巨大的難點。

1、中臺對人的要求太高

搭建中臺的產品技術，必須高度了解業務，你想業務A的人只要了解業務A，業務B的人只要了解業務B，中臺的人既得了解業務A，也得了解業務B，100條業務線，得了解100條，甚至他要比A更懂A，不然咋抽象對吧

這其中涉及到多個環節：

1）看的準？

你得看的準這個業務是怎么在跑得，他的核心流程是怎么樣的，他的功能模塊有哪些、具體包含了哪些功能？其中哪些模塊適合被抽出來？

隨便舉個例子，很多東西都會偽裝，都會變種，舉個最簡單的例子，一個盲盒功能，你覺得這個盲盒是什么東西？不會真抽象一個叫盲盒的能力吧？那你就完蛋了

過兩天來了一個大轉盤需求，你去資源池里找了一圈，發現剛做的盲盒能力根本用不了？？

算了，再做一個大轉盤吧。

看到這里，大部分小伙伴已經看出來了，盲盒本質上不就是抽獎么，這兩個理應是“一樣的東西”，大盤轉的需求，“盲盒”的能力理應能被使用啊。

本質上它們都等同于“抽獎”。

2）抽的對？

看準后，就要抽的對，抽的對包含幾層意思。

i、邊界清晰

邊界清晰有多重要？不清，是要命的！直接決定了中臺的失敗。

你到底抽到什么程度？

還是盲盒的例子，盲盒活動的整個業務鏈路，涉及到了用戶、支付、訂單、抽獎。

你難道把這些都抽出來了？還是只抽抽獎那部分？

抽的太多，中臺就太厚，你讓業務干嘛；抽的太少，中臺就太薄，失去了意義。

ii、模塊的能力合理拆分

既然我們覺得把抽獎 抽出來，那么抽出來，怎么變成一種可靈活調用的能力？

如果拆的好，那么能滿足很多額外的場景需求。

哪天來了個新需求是：直接積分兌換獎品。

用抽獎其實是可以滿足的，比如你把抽獎分成3塊：【抽獎資金獲取抽獎資格】、【抽獎核心算法】、【中獎后用中獎券兌換獎品】

那么積分兌換獎品，是不是就可以使用3）的能力？

積分和中獎券，本質上都屬于一種虛擬資產，是不是能力就通用了？

iii、如何權衡

中臺也面臨需求越來越復雜的情況，比如抽獎的時候直接開獎，也有抽獎后某一時間一起開獎；比如算法策略是大家一起開獎，還是部分用戶可以優先開獎；比如是必中，還是可不中等等。

這些多樣性，在業務的發展中一定會越來越復雜。

和普通產品迭代一樣，中臺也得不斷強化和迭代能力，不然就滿足不了業務需求了。

就好比你做了可以直接開獎的能力，結果另一條業務線拋過來一個一起開獎的需求，完犢子了，又滿足不了。

所以和普通的業務迭代一樣，中臺的需求，也面臨大量決策問題。

依然需要有效甄別真需求，還是偽需求，需求優先級怎么樣，重要或是緊急，最后判斷出來該不該做，怎么做，什么時候做，做了價值大不大等等。

2、中臺的協同成本很高

中臺的協同成本高，這個很好理解，畢竟原來只要前臺和后臺配合就能完成的事，硬生生的插了一層，變成了3方配合才能完成，難度直接增加50%。配合開發難度PLUS，相應的迭代和找問題的難度也PLUS了

尤其是中臺搭建初期能力還不完善的時候，人家根本不想用你，但又礙于公司戰略，不得不用你。就變成了一種非市場機制下被迫的行為。

所以中臺早期是很難的，中臺人也是比較慘的，因為他必須要服務好每個業務線的前后臺團隊 ，而不是單一的一個需求方。

這種協同復雜度，是幾何級的上升，我給你們舉個例子：

還是拿抽獎，比如A需要有一起開獎的需要，B要算法是隨機中獎算法，C要必中。

而且大家都很急，要求盡快上線，A要求5天后，B要求7天，C要求8天內給到。

這個時候，不單單是判斷需求應該先做什么，怎么做的問題了？

還面臨著復雜的項目管理問題，資源怎么安排，來保證ABC三方都能滿意，結果開發一評估，發現A能在5日內給到，B、C怎么趕時間都不能在7、8天內給到。

于是吭哧吭哧去找B、C商量，能不能緩一緩，結果BC不同意，于是只能考慮優先排BC的需求，再找A去商量，想把A的需求后置，A當然不同意啊，憑什么我要給BC讓路，噼里啪啦一頓溝通……大家都不妥協，于是只能向上反饋，要更多的資源。

這其中，也有因為協調不好，有些業務線撇開中臺，自己去做了，因為等著誤了業務發展，業務始終是第一考慮。

這只是其中一個很小的場景，解決方式也只是舉了一個例子，但是管中窺豹，可以看出中臺在服務多業務線的過程中，所面臨的巨大協作成本和難度。

中臺從廣義上來講：從業務中來，又到業務中去。

做的好的中臺對業務一定是有幫助的，但確實因為其難度很大，真正做的好的公司少之又少。