現在再討論中臺問題不知道算不算炒冷飯，但是我確實最近一段時間纔開始從事相關的工作，查閱了一些資料結合一些自己的思考最終決定寫一些隻言片語。
要不要做中臺？
我一直覺得軍事上的規則和策略因爲具有敏感的意義和價值所以從合理的角度來講可以適用於很多領域，比如:讓能聽見炮火的人指揮戰鬥、只有具備敢使用核武器的膽量，才能不戰而屈人之兵等等。
中臺被比喻成可以快速實施遠程打擊的“炮火羣”，那麼梵蒂岡是不是需要炮火羣呢？我覺得從性價比上考慮是不需要的，只有0.44平方公里，800人口的國家，找幾個人組成一個巡邏隊基本就可以滿足日常的國防需求，所以同理業務規模小的企業是不需要中臺的，那是不是大國就需要建設“炮火羣”呢？也不盡然，比如智利，狹長的國土地形，一面臨海，一面對着多國的邊境線，很難建設一個功能統一、強大的“炮火羣”滿足截然不同的個性化防衛需求，所以我的結論是如果一個公司的業務規模達到一定規模，業務模式在不同的產品線上大致雷同，日常的管理維護、升級迭代成本對公司的盈利造成了比較大的影響，那麼中臺化勢在必行。
這樣的公司多不多呢？以我目前的視力所及是多的。舉個栗子？這裏開個小差，提出一個觀點如果不能找到合適的栗子，要麼你對這個觀點理解還不夠深刻、要麼這個觀點就是有待商榷的，至少目前這個時間點還不適合拿出來討論。
拉回來看看這顆栗子，一個水果店，經營狀況良好，但由於老闆動手能力強、又迫切的想擴大業務規模，就自己動手建設了一個小程序，把生意做到線上，結果效果良好，隔壁的蔬菜店得知之後，也請店主建設了一個線上的銷售工具，水果店主調研了一番後發現，把自己的小程序複製一份，修修改改就可以了交付了，並且賺取了可觀的酬勞，肉店、服裝店都來了，水果店主發現自己精力不夠覆蓋複製後的修修改改了，結合拿到的酬勞考慮，可以爲每一個客戶專門招一個技術人員來建設，前期走的也非常順，因爲有源源不斷的客源進來，支付了技術人員的工資之後還有足夠的利潤，但是好景不長，隨着線上業務的普及和技術的成熟，市場上竟然出現了競爭者，分流到自己這裏的新增系統建設需求也沒有多少了，前期積累的利潤很快就被幾個技術人員的薪水消耗的所剩無幾，可是已經交付的諸多系統還有一些升級迭代需求，也是一筆不錯的收入，顯得比較雞肋，繼續運營耗時耗力，利潤微薄，放棄又實在捨不得，這個時候中臺就要應運而生了。水果店主把各個業務線上的技術人員集中在一起，把系統重複的部分抽象出來，重新建設，建設完成之後原來90%的工作量都不需要專人維護了，1個技術人員可以滿足多個店鋪的升級需求，多餘的人力可以開闢一些新業務，增加一些其他收入，水果店主的軟件生意又回到了正軌。單就這個例子而言，技術人員可能會說，你設計系統的時候爲什麼不考慮兼容性，爲什麼不能提前抽象化一些，這樣就可以避免後邊的尷尬了，確實，這個小栗子是可以靠一些專業的設計能力去覆蓋，但是誰也沒有預測未來的能力，如果第一個蔬菜店主沒有找上門，你前期設計的過於複雜，實施成本提升、交付時間拉長，可能第一版水果店的線上工具都胎死腹中了，何談未來。在商業邏輯上，先低成本試錯、隨着業務發展逐漸調整的模式是更常見的。所以我看需要中臺化的公司不在少數。
目前中臺的建設有兩種聲音，一種是中臺無限好，一種說中臺完全就是妖魔鬼怪，我雞賊的發現說中臺好的基本是建成了、受益了，說中臺是妖魔鬼怪的大多是沒做成、沒做好，又付出了比較多的成本，氣急敗壞、歇斯底里。所以在我看這個問題不是在討論中臺要不要建設的問題，而是在討論怎麼才能建成、建好？
參考了一些中臺建設成功和失敗的案例，總結了幾點注意事項，下面請聽我一一道來：
第一步要判斷我們自己的企業目前是不是到了上述例子中的歷史進程、我們的產品線是不是冗餘程度比較高，這個判斷由誰來做？當然是企業的老闆、至少是高層管理，只有站到了足夠的高度，才能看清企業的發展階段和各環節的支出收益比，才能決定中臺項目要不要提上日程？什麼時候推進？但是這個過程基本上是迅速的、堅決的，因爲老闆們是先有切膚之痛，纔有濟世良方，這也是中臺概念能大行其道的主要原因，另外發散一下，互聯網進入下半場，跑馬圈地、價格戰換取用戶的時期在大多數業務領域已經是過去式了，下半場更多的是深耕存量用戶、業務，精準運營、降低成本、提升利潤率，中臺概念提供了這樣的可能，所以成爲風口。
第二步就是怎麼做了，這裏邊各企業個性化的部分很多，沒有制式的標準和方案，那就意味着失敗的可能性也多，再分開說一下：
1、業務和中臺邊界的劃分
看過一個文章中說這個邊界的劃分直接影響中臺建設的成敗和建成之後的意義，我深以爲然。但是各個企業業務千姿百態，組織結構也錯綜複雜，沒有通用的解決方案，但是有一個框架可以遵守，那就是取最大公約數、不要取最小公倍數，中臺建成之後和業務的交互模式是：業務端保留自己的定製化需求和開發、通過輕量的對接可以實現快速的推廣、試錯。與之相反的兩種情況是業務什麼都不需要做，也什麼都做不了，中臺支持定製化開發，這個是最小公倍數的方案，那麼無非是把各業務線的代碼挪到中臺來寫而已，很難大幅降低工作量，還有就是中臺只管技術抽象，完全不考慮業務，最後業務串聯開發量仍然很大，完全跑不快。簡單一句話：做全部業務和完全不做業務的中臺都是耍流氓。
2、中臺建設團隊的成員組成
這裏說兩個極端，一種是完全啓用新人，或找有經驗的外包團隊做，請原諒我很難相信他們可以精準快速的找到各個業務線的最大公約數，另一種是完全由業務線的成員抽調組成，由於先入爲主的思維方式，具體負責業務的成員會習慣的想我需要這樣的功能、需要那樣的功能才能實現目前的業務，這也是不利於對共有部分進行抽象的，所以各兵種聯合作戰的組織結構是我比較認可的，其次，在人員組成相對合理後，讓項目組成員充分的瞭解項目背景、未來願景和困難程度顯得尤爲關鍵，當然只要有人的地方就有江湖，爲了提升溝通效率、落實項目意圖、增強執行力，做不到完全理想化或者採取一些強制化手段也未嘗不可。營造一個衆人拾柴火焰高的氛圍可以事半功倍，這在所有工作中幾乎都是適用的，只不過中臺項目總體溝通量大、涉及溝通鏈路長，團隊協作才顯得尤爲重要。
總而言之、言而總之，中臺建設是一個有指導思想但是沒有標準工作步驟的工作，是需要公司領導層、中臺建設者、各個業務線在各個時期分工合作，羣策羣力的，它足夠複雜也足夠有威力，需要智慧和膽識，如果各方面時機成熟的的確確是可以做的，也是能做得成的。