[康威定律]帶來一種義務，讓我們必須不斷追問：「是否存在一個更好的設計，只因為我們的組織而無法為我們所用？」

——梅爾・康威（Mel Conway），《Toward Simplifying Application Development, in a Dozen Lessons》

第 1 章討論了組織為何必須把團隊組織視為成功不可或缺的因素。本章將更細緻地探討康威定律對團隊、組織結構與軟體架構揭示了什麼。

理解並運用康威定律#

軟體系統變得比以往更大、更彼此互連，而團隊組織方式對它們的影響長期存在卻常被忽視。要理解其中運作的力量，康威定律至為關鍵。但你或許會懷疑：一條 1968 年關於軟體架構的定律，經得起時間考驗嗎？

畢竟我們已經走了很遠：微服務、雲端、容器、無伺服器。依作者經驗，這些新事物能幫助團隊在局部改善，但組織越大，就越難完整收割好處——團隊的組成與互動方式，往往建立在過往專案或遺留技術之上（反映的是最新一版組織圖設計，而它可能已是數年、甚至數十年前的產物）。

產業案例：Adidas 的轉型#

運動服飾公司 Adidas 經歷過一場有趣的轉型，明確地把康威定律當作組織設計的驅動力。

依平台工程資深總監柯納戈（Fernando Cornago）與平台工程暨架構副總勞特特（Markus Rautert）的說明，其 IT 部門原本被視為成本中心——多數軟體由單一供應商提供（需要頻繁交接），內部工程師寥寥可數（做管理多過做工程）——轉變為產品導向的團隊組織：

• 80% 的工程資源投入建立內部軟體交付能力，透過與業務需求對齊的跨職能團隊來達成
• 20% 投入一個中央平台團隊，負責工程平台與技術演化，以及顧問諮詢與新人 onboarding

結果，Adidas 將其數位產品的發布頻率提高了六十倍，同時也正面影響了軟體品質。

研究證據#

除了經驗性的實務，也有越來越多研究普遍證實康威所勾勒的傾向：

• 哈佛商學院的麥考馬克（Alan MacCormack）與同僚研究了多項開源與閉源軟體產品，發現「有力的證據支持這項假說：產品的架構傾向於映照其開發組織的結構」。
• 車輛製造與飛機引擎設計等其他產業的研究也印證了同一想法。

事實上，已有足夠的產業研究顯示，康威定律所指認的同態力廣泛適用。

馬蘭（Ruth Malan）的這句話可視為康威定律的現代版本：

「如果系統的架構與組織的架構彼此衝突，贏的是組織的架構。」

馬蘭提醒我們：組織受限，只能產出匹配或模仿其真實、在地溝通結構的設計。這對任何設計並建造軟體系統的組織——無論自建或委外——都有重大的策略意涵：

• 一個按職能穀倉排列的組織（團隊專精於 QA、DBA 或資安等特定職能），幾乎不可能產出「為端到端流動而妥善架構」的軟體系統。
• 一個主要圍繞不同地理區銷售通路排列的組織，也不太可能產出「向全球各區提供多種軟體服務」的有效軟體架構。

為什麼組織不太可能發現或維繫某些架構？康威在 1968 年的文章中提供了線索：

給定任何[特定的]團隊組織，就存在一類設計替代方案是該組織無法有效追求的，因為必要的溝通路徑並不存在。

組織內的溝通路徑（無論是否沿著正式匯報線）實質上限制了組織能構思出的解法種類。但我們可以把這一點轉為策略優勢：

• 若我們想抑制某些設計——也許是那些過度聚焦於技術內部細節的設計——就可以重塑組織來避開它們。
• 若我們希望組織發現並採用某些設計——也許是那些更有利於流動的設計——就可以重塑組織來促成它。

當然，沒有任何保證說組織一定會找到並使用我們想要的設計，但至少藉由形塑溝通路徑，我們讓它更有可能發生。運用康威定律的組織設計，因而成為一項關鍵的策略活動：它能大幅加速有效軟體設計的發現，並協助避開較無效的那些（第 8 章會更詳細討論如何帶著康威定律的視角策略性地演化組織）。

反向康威操作#

為了提高組織「建造出為流動而最佳化之有效軟體系統」的機會，可以在軟體完成之前，先執行反向康威操作（reverse／inverse Conway maneuver）來重新配置團隊間的相互溝通。你可能會遇到初期的抵抗，但只要管理層有足夠意志、團隊有足夠意識，這個做法確實可行且有效。

反向康威操作於 2015 年前後在技術圈取得聲勢，此後已在許多組織實施。《Accelerate: The Science of DevOps》一書支持了這項策略對高效能組織的重要性：

「我們的研究支持了有時被稱為『反向康威操作』的做法：組織應當演化其團隊與組織結構，以達成所欲的架構。目標是讓你的架構支撐團隊從設計到部署完成工作的能力，而不需要團隊之間的高頻寬溝通。」

反向康威操作的一個簡化示例

以下是對「組織建造軟體」中康威定律的刻意簡化，用以說明其中運作的想法與力量。

現況：四個獨立團隊，各自由前端與後端開發者組成，分別負責系統的不同部分，然後把資料庫變更交接給一位資料庫管理員（DBA）。

依康威定律自然浮現的架構：每個團隊各有獨立的前端與後端元件，加上一座單一的共享核心資料庫。

換句話說，使用共享 DBA 團隊，很可能驅動出單一共享資料庫的浮現；而使用分離的前端與後端開發者，則因溝通的性質而很可能驅動出 UI 與應用層的分離。

如果這正是我們想要的架構，那一切安好。但如果我們不想要單一共享資料庫，麻煩就來了——康威定律指認的同態力，正強力拉扯著「自然」架構從當前的組織設計與溝通路徑中長出來。

目標架構：假設我們想為新的雲端軟體系統採用微服務架構，每個服務彼此獨立、各自擁有資料存放區。

套用反向康威操作：我們可以設計團隊去「匹配」所需的軟體架構——為客戶端應用與 API 各配置開發者，並把資料庫開發者放進團隊之內而非之外。

依康威定律，適當的團隊設計會最「自然地」產出所欲的軟體架構。如果我們希望資料存放區與業務領域對齊，就必須避免出現單一的「扇入」（fan-in）資料庫人員或團隊——可行做法之一，是在應用開發團隊內部加入資料能力。

鼓勵團隊範圍內流動的軟體架構#

康威定律告訴我們：必須先理解需要什麼樣的軟體架構，才能組織團隊，否則組織中的溝通路徑與誘因終將反過來決定軟體架構。如尼加德（Michael Nygard）所說：「團隊的任務指派，就是架構的第一版草稿。」

要達成安全、快速的變更流動，我們必須考慮團隊範圍內的流動（team-scoped flow），並讓軟體架構配合它。交付的根本手段是團隊（詳見第 3 章），因此系統架構必須讓每個團隊內部的快速流動成為可能並受到鼓勵。

所幸實務上，這意味著我們可以遵循已被驗證的軟體架構良好實踐：

• 鬆散耦合（loose coupling）——元件不對其他元件持有強依賴
• 高內聚（high cohesion）——元件有清楚界定的職責，內部元素彼此高度相關
• 清晰且適當的版本相容性
• 清晰且適當的跨團隊測試

在概念層次上，軟體架構應當像它所賦能的變更流動；我們該設計的不是一串相互連接的元件，而是建立在底層平台之上的「流」（平台將在第 5 章討論）。

讓事物維持在「團隊大小」，有助於達成麥考馬克與同僚所稱的「參與式架構」（architecture for participation）——藉由限制模組大小來促進理解的容易度，藉由最小化設計變更的傳播來促進貢獻的容易度。

換句話說，我們需要的是團隊優先的軟體架構，讓人們與之協作的能力最大化。

保持解耦與團隊範圍，應當是一項關鍵且持續的組織檢驗。如羅伯茲（John Roberts）在《The Modern Firm》所說：「採用遵循[某種]解聚模型的設計，往往能取得效能上的真實增益。」這些增益一部分來自變更流動速率的提升，一部分則來自組織「改變架構以適應新情境」的能力。

《The Principles of Product Development Flow》作者萊納特森（Don Reinertsen）說：「我們也可以把架構當作快速變更的賦能者來運用。做法是切分架構，讓它得以優雅地吸收變化。」架構因而成為賦能者而非阻礙——但前提是我們採取一個由康威定律所啟發的團隊優先取徑。

組織設計需要技術專業#

如果我們接受康威所描述的自相似力（介於架構與團隊組織之間）是真實的，那我們也必須接受：任何對工程團隊之形態與配置做出決策的人，都在強烈影響軟體系統架構。

這是康威定律的一個邏輯推論。用馬蘭的話說：「如果我們讓管理者決定……哪些服務會被建造、由哪些團隊建造，那我們其實就是讓管理者在決定系統架構。」

人資部門對軟體系統的了解有多少？那群決定如何在團隊間分配預算的部門主管，知道自己的選擇對軟體架構可行性可能造成什麼影響嗎？

既然康威定律背後的同態性證據越來越充分，建造軟體系統的組織若在沒有技術領導者參與的情況下決定團隊的形態、職責與邊界，就是極其無效（也許甚至是不負責任）的做法。

組織設計與軟體設計在實務上是同一枚硬幣的兩面，兩者都必須由同一群知情的人來承擔。凱利（Allan Kelly）對軟體架構師角色的看法進一步延伸了這個想法：

我比以往更加相信，一個自稱架構師的人同時需要技術與社會技能，他們需要理解人並在社會框架中工作。他們的職權範圍也需要超越純技術——他們需要在組織結構與人事議題上有發言權，也就是說，他們也需要是個管理者。

從根本上說，我們之所以需要技術人員參與組織設計，是因為他們理解 API 與介面、抽象化、封裝等關鍵軟體設計概念。史丹佛（Naomi Stanford）的說法是：「部門與事業處、系統與商業流程……都可以被獨立設計，只要與更大組織之間的介面和邊界構成設計的一部分。」

限制不必要的溝通#

康威定律的一項關鍵意涵是：並非所有溝通與協作都是好的。 因此，界定「團隊介面」以設定期待——哪類工作需要強力協作、哪類不需要——就顯得重要。許多組織假設溝通越多越好，但事實並非如此。

我們需要的是特定團隊之間有聚焦的溝通。我們該去尋找那些「意料之外的溝通」並處理其成因；正如索薩（Manuel Sosa）與同僚 2004 年對飛機製造的研究所發現的：「管理者應把心力放在理解未被處理的設計介面……以及跨模組系統之間未被預期的團隊互動……之成因。」

Scrum 產品開發取徑的創始者之一柯恩（Mike Cohn），用以下問題評估組織內跨團隊溝通的健康度：

• 這個結構是否最小化了團隊之間的溝通路徑數量？
• 這個結構是否鼓勵了原本不會溝通的團隊去溝通？

柯恩在此點出的需求是：如果依軟體架構設計、邏輯上兩個團隊本就不需要溝通，那麼當它們在溝通時，必然有什麼地方出了錯。

是 API 不夠好嗎？是平台不合用嗎？是缺了某個元件嗎？

如果我們能在團隊之間達成低頻寬——甚至零頻寬——的溝通，同時仍能安全、有效、快速地建造與發布軟體，那我們就應該這麼做。

不是每個人都需要和每個人溝通#

在開放式辦公室，尤其是在聊天工具帶來無所不在的即時溝通之後，任何人都能和任何其他人溝通。在這種情況下，人們可能不知不覺落入一種「每個人都得和每個人溝通才能完成工作」的溝通與互動樣態——把「篩選出什麼才相關」的負擔丟給接收方。

從康威定律的視角看，這會為軟體系統帶來非預期的後果，尤其是子系統之間缺乏模組性。

如果組織期待「每個人都該看到聊天室裡的每則訊息」「每個人都得參加大型站立會議」「每個人都得出席會議才能核可決策」，那我們就有組織設計問題。康威定律指出，這種多對多的溝通傾向於產出單體、糾結、高度耦合、彼此依賴、無法支撐快速流動的系統。

溝通更多，不必然是好事。

當心：對康威定律的天真運用#

誤解康威定律是有風險的：可能建出一組「看似能良好對應到所需架構、實際上卻嚴重妨礙快速流動」的團隊。此外，跨團隊工具與溝通之間的關係經常被忽略，但這類工具其實是自相似設計的強力驅動因子。

工具選擇驅動溝通樣態#

團隊使用軟體溝通工具的方式，會強烈影響團隊之間的溝通樣態。在難以建造與營運現代軟體系統的組織中，一個常見問題是團隊／部門的職責邊界與工具的職責邊界不匹配：有時組織用了多套工具，其實一套就夠（可提供共通的共享視圖）；有時只用一套工具，卻因為團隊需要各自分離的工具而生出問題。

判準很簡單：

• 若我們希望團隊協作，共享工具是合理的。
• 若我們需要團隊之間有清楚的職責邊界，分離的工具（或同一工具的分離實例）可能更好。

舉例來說，若需要軟體開發團隊與 IT 維運團隊密切協作，卻給兩者分離的工單或事故管理工具，很可能導致糟糕的跨團隊溝通；此時應選擇能同時滿足兩方需求的工具。

同樣地，應避免那種「僅限具正式環境安全存取權之團隊使用」的特殊「僅限生產」工具。若該工具與正在建造的軟體互動或對其進行度量，受限的存取權很可能在「有權限」與「無權限」的團隊之間製造出溝通鴻溝。工具可以幫助也可以妨礙溝通流動，因而影響團隊互動的成效。

日誌聚合工具為「需要查閱正式環境日誌（例如除錯）但沒有正式環境存取權」的應用團隊提供了簡單解法。這類工具把所有日誌送到外部位置，在該處統一處理與索引（必要時匿名化），使搜尋與事件關聯比翻找個別日誌快得多。團隊取得所需資訊，而正式環境的安全控制保持完整（前提是日誌傳輸本身是安全的）。

反過來，當兩個團隊的職責邊界並不重疊（角色差異很大、無太多協作需要）時，堅持兩者使用同一套事故追蹤工具、甚至同一套監控工具，就得不到多少價值——尤其當其中一方是組織外部的服務提供者時。

總結：不要在未先考慮團隊相互關係的情況下，就為整個組織挑選單一工具。獨立的團隊用分離的工具，協作的團隊用共享的工具。

過多的元件團隊#

有些組織天真地運用康威定律，建立了大量聚焦於建造系統小部件的元件團隊。

元件團隊——更好的稱呼是複雜子系統團隊（complicated-subsystem team，見第 5 章）——偶爾確實需要，但僅限於需要極為細緻專業的例外情況。一般而言，我們要為快速流動而最佳化，因此流動對齊團隊才是首選。

製造領地或裁減人力的反覆重組#

過去許多「重組」的底層目的，是裁減人力或為管理者與領導者製造權力領地。

當我們為了配合康威定律而改變組織結構時，目標是改善組織「以軟體系統搜尋解法」的空間（脈絡、限制等）。這兩種取徑是互斥的。

說得更強烈一點：為了管理便利或裁減人力而定期重組，會主動摧毀組織有效建造與營運軟體系統的能力。忽視康威定律、團隊認知負荷及相關動態的重組，風險就像讓孩童執行心臟直視手術：極具破壞性。

對軟體與「產品」公司而言，結構應當預先設想產品架構。結合團隊優先取徑，那種因管理理由而定期進行的重組，就該成為過去式。

本章總結：康威定律是技術領域高效團隊設計的關鍵#

康威定律告訴我們：組織的結構與團隊之間的實際溝通路徑，會頑固地留存在所建系統的最終架構裡。它否定了「把軟體設計當成獨立於團隊設計之外的活動」這種嘗試。

這條簡單定律的影響極為深遠：

• 一方面，組織的設計限制了特定系統架構的可能解法數量。
• 另一方面，軟體交付的速度強烈受制於組織設計植入了多少團隊依賴。

快速流動要求限制團隊之間的溝通。在需要探索與專業才能推進的灰色地帶，團隊協作很重要；但在執行（而非探索）為主的區域，溝通就變成不必要的開銷。

達成所欲軟體架構（以及交付速度、故障恢復時間等相關效益）的一項關鍵做法，就是套用反向康威操作：設計團隊去匹配所欲的架構。

本章提供的簡單範例是：組織可以把資料庫技能嵌入應用團隊，使其有足夠自主性去維護獨立的資料存放區（也許仍仰賴中央 DBA 團隊在資料庫設計或跨庫同步上提供建議），藉此避開單體資料庫。

簡言之，在設計軟體架構或重組團隊結構時把康威定律的影響納入考量，你就能善用那股正在作用、使軟體架構與團隊設計彼此收斂的同構力。