寫在前面的共識基礎
為了友善後面的内容展開, 我們需要了解幾個基本的道理.
故事的開始: 小而美的小作坊
很好了解, 一小群人, 一小撮系統(很可能就是一個), 幹就玩了。
自然而然的早期增長
如果"小作坊"試點成功了, 我們再多幹幾單就是了. 事情多了, 隊伍再大一點, 研發也簡單, "再加點功能呗"或者"抄就是了"
然後發現點"小問題"
- 系統有點大了,
- 好像有點重複了
于是...
平台出現了: 拆! 合!
這個問題容易呀, 咱是科班呀, "抽象"懂不懂, "複用"懂不懂, 咱"優雅"起來最讨厭"複制粘貼"
分一分呗:
- 重複的事情, 我們合并下, 搞個平台, 我們大家都能用. 對了, 人也是, "專業的人幹專業的事"嘛
- 其他小夥伴(藍色), 咱們繼續沖, 在業務的第一線(簡稱"業務線"), 去服務客戶, 去做産品.
"平台"怎麼run起來?
系統和人都分好了, 我們怎麼合作呢?
容易:
他為啥能快的呢? 嗨, 還不是小作坊的底子.
好呀, 那給我來個10倍增長.
貌似又難受了...
"冰糖葫蘆"/ "收費站"問題來了
去過些大廠, 帶個大項目, 你可能就有感覺
"群太多了"
"會議太多", "要拉的人好多"
"鍊路長", "平台人不夠, 等他們排個期"
是的, 系統越來越多, 鍊路越來越長(冰糖葫蘆), 人越來越多, 合作好難(層層找人,像"收費站"), 這到底是為啥呢? 還是前面說的, 不再"小而美"了.
問題的本質: 認知負荷超載
1. 系統複雜度: 人的知識有上限, 超人沒那麼多
2. 業務(資訊)複雜度: 業務花樣越來越多, 不搞花樣, 就要輸了
3. 協作(人與人)複雜度: 資訊傳遞
一種可能解法, 叫"中台"
是的, 資訊瓶頸的問題解法很多, 其中一個方向:
- 提升知識抽象層次, 産品賦能, 解決方案輸出.
"我就是開個車, 不需要學熱力動學", 搞個開放區(綠色部分), 包裝個門面.
業務線(人員)和平台線(人員)都能搞得明白的, "大家都能搞"
- 打破(融合)系統/組織邊界
對于"門面"部分, "沒啥你的我的, 都能上"
中台的基本運作原理: 解耦
這套機制會出現兩種橫豎型的項目
- 業務型項目, 就是要快速傳遞業務結構.
- 平台型項目, 就是把平台的做的"深入淺出", 給上面"标準化"的能力, 理想的情況, 是讓上面的人自己去"搭樂高", 下面的人把積木造的專業.
注意: 這裡沒有區分技術/産品經理/測試職能, 嚴格來說, 每個陣營(紅藍綠)都應該有各個職能的成員, 才能完整完成傳遞.
是以核心原理還是一樣, 本質還是形成小團隊
那要怎麼做到"中台"?
思路1: 偏技術流, "新平台"
起點一般是以技術架構, 搞個"中台系統", 把下層能力原子化, 标準化, 然後在中台系統, "重組編排", 聽上去有點像個"業務工作流引擎(BPM)".
但是這套東西, 還不隻是一個技術型, 因為要給上遊"非專業"非平台的技術人員, 産品人員看到, 是以還有一趴配套的規範/機制, "可視化"展現的東西. 總之, 要讓藍色陣營(或者說任何陣營,新手)都能快速上手,自助搞定.
一般來說, 這個過程, 是由紅色陣營發起的, 打算把"專業"的東西"搞個簡單可視化"的内容出來.
行業黑話, "aPaaS", 不過具體名字, 可能在不同廠内叫法不一, 總之聽上去很高大上.
不過嘛, 貌似過程有點艱難
感覺系統總是建不完:
- 想要的多呢, 工作流, 可視化, 可測試, 靈活釋出. 工作量大了, 那消耗就多了.
- "标準"貌似總是定不完. 每個人一個說法, 每個團隊都讨論過"什麼是産品","什麼是服務", "什麼是能力".... 還要有全局的權威拍一拍, 定個啥标準. 過段時間再優化優化, v1.0, v1.1, v1.2....
- 定了标準,有了系統, 還要往裡搬内容不是, 曆史系統,曆史知識, 重組,遷移都是巨大的工程.
總體來路,這個是漫長的路, 越大的公司越需要這些機制, 然而工作也越艱巨好大.
思路2: 先從人入手, "共建吧"
等系統是來不及了, 業務也是不等人的("需求倒排"咱都懂), 那趕緊先上吧.
上面(藍色)人多,也着急,就派人下來, 幫平台快速改造下.
下面(紅色)的人也不放心别人來設計方案, 修改系統, 也出了人,"把控"/"扶持" 上面的人.
這種方式比較實幹, 人動要比系統動更快.
這種模式運作下去, 其實可能出現的一種情況是, 出現新的角色(綠色), 是種賦能型團隊, 用這種"專家"的能力和知識來幫上面解決問題, 産出解決方案; 也牽引下面, 别讓下面閉門造車.
風險:人能動, 是優勢也是風險
因為人嘛, 學新東西是不排斥, 但是總有個度, 臨時借調還好, 長期戰役狀态, 吃不消了, 壓力大.
- 上面的人過來的人(藍轉綠), 在别人地盤上幹活, 管理/情感/考核等方面都比較難處理. 常見的雙線彙報/虛線彙報, 其實也都是比較模糊的解決這個問題.
- 下面的人來輔導(紅轉綠)
這些原因導緻的可能結果, 就離職走人了, 團隊就出現很大的穩定因素.
兩種思路, 其實是殊途同歸
還記得前面說的康威定律嗎, 組織(人)和應用架構/業務結構, 最終都會趨同.
是以面對的都是各自成熟度提升:
1. 成熟系統
曆史負載, 架構重構, 标準的持續更新維護難
2. 成熟人員
人員培養難跟進資訊增長
小結: 對抗增長的複雜度很艱難,沒有銀彈
不管大家是否主觀願意, "中台"(可能這麼叫, 也可能換個名字)都會在增長的階段出現.
是以雖然不同公司不同部門可能處于不同階段. 大家首先要了解當面的階段的原因, 别光吐槽, 也預知後續趨勢和可能出現的問題, 做好預備。
另一方面， 也不用迷信或者糾結， “我們要不要做中台”。 如何對抗增長的複雜性是個長期準備， 不同階段不同準備。
最後的筆者自我介紹:
考慮了一下, 還是寫完這篇完整, 再介紹一下筆者大概的情況, 也友善大家判斷我的執筆偏好.
- 本人在杭州某大廠從事10+年, 比較完整經曆過以上不同的周期, 是以對過程和問題一些親身體驗
- 本人經曆過本文"紅藍綠"陣營的一線或者管理角色, 了解其中的比較全面的視角.
是以本人自認視角比較中立. 但是由于能力/視野局限, 最終也是主觀成文 ,可能有不周之處, 歡迎指教.
但是謝絕空評中台好壞之類問題.