康威定律是馬爾文·康威1967提出的：“設計系統的架構受制於產生這些設計的組織的溝通結構。” 中文直譯的意思是：設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。更直白的說：你想要什麼樣的系統，就搭建什麼樣的團隊。
“康威定律”從提出至今，已經半個多世紀了。“康威定律”仍然有效嗎？
康威定律經常被用來證明團隊組織的變化是合理的。在開啓數字化轉型之旅時，各組織應遵循“康威定律”，改組自己的工程團隊，包括文化、彙報結構和激勵計劃，以配合他們的架構和技術發展戰略。然而，許多組織並沒有這樣做，卻對轉型無法帶來顯著的生產率提升感到詫異。
康威定律認爲一個系統的技術架構反映了構建這個系統的人員組織架構。作爲軟件從業者的我們，不難發現這樣的規律：組織的團隊結構在處理得當時，仍然是一個關鍵的推動因素，而在處理得不好時，則會變成嚴重的障礙。
康威定律是一條雙行道
技術設計影響人員組織設計，同時研發團隊的架構也會對根據該架構建立的系統產生重大影響。數字化時代，如何搭建成熟的大型研發團隊，康威定律是非常關鍵的推動因素。
“團隊優先”的概念是美國陸軍四星上將麥克里斯特爾其暢銷書《賦能：打造應對不確定性的敏捷團隊》中指出的：表現最突出的團隊“之所以能夠取得非凡的成就，不僅僅是因爲團隊成員的個人素質，還在於這些成員凝聚成了一個整體”。
在軟件開發中，現代軟件密集型系統所需的速度、頻率、複雜性和變更的多樣性意味着團隊是必不可少的。依賴個體本質是不可持續的。谷歌在針對他們自己團隊的研究中發現，團隊活力遠比誰在團隊中更重要。因此，我們必須從團隊入手實現高效的軟件交付。有許多方面值得思考和培養，比如團隊規模和團隊關係。
團隊規模
我們經常會遇到下面的問題
團隊人數不夠怎麼辦？
團隊成員能力不足怎麼辦？
在《人月神話》中有個著名的論斷：“向進度落後的項目中增加人手，只會使進度更加落後”。其中一個很大的原因是，新員工總是需要老員工進行指導，這其中就會產生看不見的溝通成本。這些溝通成本擠佔了老員工原本的計劃工作時間，造成在短期內無法提升項目進度——增加的人手越多，溝通成本所帶來的影響越大。
同時，因爲被迫不斷擴大的團隊規模，導致業務梳理分裂、技術設計碎片、人員能力也難以得到提升。這在大型系統的設計和開發中成爲了常見問題。
怎麼做呢？
“話說天下大勢，分久必合，合久必分。”系統越複雜，越需要增加人手，人手越多，溝通成本也呈指數增長。分而治之便是大多數公司選擇的解決方案：分不同的層級，分不同的小團隊，讓團隊內部完成自治理，統一對外溝通。
我們來看一個例子：如果一個團隊有3個team在協作，而每個team都是前端、後端、測試職責分明。
如果嘗試進行能力合併，則是全功能團隊，可能的模式就變成下圖所示：
全功能團隊負責編寫代碼、單元測試、接口測試、集成測試等環節，以敏捷的方式實現端到端的協同，整體效率開始提升；但我們面對的是大型的系統研發，即需要至少超過50人的研發團隊。我們再嘗試一種變化：
這是一種從外部視角來組合組織關係的方法：嘗試通過抽象、構建通用組件來嘗試達到能力複用。
這有點像不斷演進的平臺型組織架構，小到一個研發團隊，大到一個組織設計，其中的道理是相通的：你需要構建什麼樣的系統，就搭建什麼樣的組織結構。這句話有一種逆向作用力：如果控制不好，就會導致重複建設、效率低下、部門牆，且最終可能沒有對任何一個問題域打穿，陷入各自爲政的尷尬境地。
所以，在團隊人數不夠，或是團隊能力不足的時候，我們首先思考的應該是能否以及如何將問題域打穿。因此，我們需要一個動態的平臺型組織，其核心原則是協同與賦能。
舉例：平臺型組織的架構設計
團隊關係
《人月神話》中總結出了隨着人員的增加溝通成本呈指數增長的規律：
5人項目組，需要溝通的渠道是 5*(5–1)/2 = 10
50人項目組，需要溝通的渠道是50*(50–1)/2 = 1,225
150人項目組，需要溝通的渠道是150*(150–1)/2 = 11,175
這也是爲什麼敏捷組織都追求小團隊的原因之一。溝通的問題會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果。
組織設計的產品/設計等價於這個組織的溝通結構。通俗地說，就是你組織是什麼風格，你交付的產品就是什麼風格。
阿里的組織架構和溝通機制比較層級化，因此阿里的產品架構也非常嚴謹，先頂層設計，後逐步細化。阿里善於總結和提煉，所以在去SuperCell學習後，回來就將中臺吸納、提升爲中臺概念。
騰訊的組織架構和溝通機制更偏社交，組織架構相對比較“散”，所以QQ、微信都很成功。而且騰訊將SuperCell收購之後，依然是獨立管理。
在設計溝通方式的時候，我們需要用端到端的視角來看待整個研發團隊，特別是要以業務價值爲導向，而不是以研發人員的產出爲導向。比如，絕對化的代碼行數、功能數、用戶故事數就是非常局部的度量方式，而前置時間(Lead Time)、週期時間(Cycle Time)是目前用戶比較推崇的整體度量指標——軟件產品最終是交付給用戶的，用戶往往只關注產品何時能夠按質量交付，也就是端到端的整體效率。
您可以拿康威定律套一下您自己所在團隊，看看這個定律在您公司是否也一樣生效。
分佈式團隊
我們現在看到越來越多的企業正在組建分佈式的數字化團隊，其好處不言而喻：
降低成本
使員工能夠專注於核心業務
使用遠程開發團隊解決產能問題
獲得智力資本：每個地區都有自己獨特的思考方式和所擅長的技術
凱捷研究院有一期專刊，講的是《未來遠程混合工作模式的挑戰和機會》。這時候我們需要思考，如何利用康威定律，更高效地組建分佈式團隊。
下面我們舉個具體的例子：
系統設計受限於組織自身的溝通結構。組織的規模越大，靈活性就越差。這種現象就越明顯。平臺團隊的設計，就是爲了解決這樣的問題。
一個個工作單元可以有XXX名工作級顧問，通常按技術棧配備（前端、後端、移動端）
根據項目情況配備有N名入門級顧問，時間上按需投入
工作單元可以有行業屬性（汽車、零售、商業地產、高科技、供應鏈等）
我目前所在的團隊面臨着大型複雜的系統的設計和開發，需要大團隊協同作戰。如今十分流行的中臺組織架構、敏捷組織，秉承同樣的核心思想：你的組織構架會決定團隊寫出的產品代碼，這是由顛覆不變的康威定律決定的，相對應的我們需要不斷地優化組織結構以超越康威定律。
總結
博物學家斯蒂芬.傑.古爾德曾在書裏講過一個故事：兩個女孩在遊樂場聊天，其中，一個女孩問：“如果蜘蛛能變得和大象一樣大，還能到處爬，那豈不是很可怕嗎？”另一個女孩回答說：“纔不會。如果蜘蛛有大象那麼大，那它就會變得跟大象一樣笨重了，笨。”
古爾德解釋說，第二個女孩說得對，因爲組織體的大小很大程度上決定了其形態。如果蜘蛛真的變得和大象一樣大，那麼它的形態和行爲也會變得和大象類似，因爲這是體積變大的必然結果。
對軟件項目，我們可以提出一個類似的問題：如果一個敏捷項目變得非常大，會不會很可怕呢？也許不至於很可怕，上文關於大象和蜘蛛大小的一系列分析，對項目來說同樣適用。
這個故事的寓意與我今天分享的主要思想是不謀而合的。現在的絕大多數企業的數字化只聚焦在工具和數字，而非基於流程和組織的重新思考。希望我們在從康威定律看團隊結構的時候，能運用以下的思維模式來指導我們的實踐：
2、團隊關係：要用一切手段提升溝通效率，比如看板，always on。每個人、每個系統都有明確的分工，權責明晰。