Conway’s Law 與組織設計#

本章探討如何運用 Conway’s Law 來設計組織結構和系統架構，以支持 DevOps 轉型的目標。Conway’s Law 指出：

組織所設計的系統，其結構必然會複製該組織的溝通結構。

換句話說，如果我們有四個團隊負責一個編譯器，我們最終會得到一個四階段的編譯器。這意味著組織結構和技術架構是緊密耦合的——要改變一個，往往需要同時改變另一個。

組織原型#

書中描述了三種主要的組織結構原型：

功能導向（Functional-Oriented）#

• 按專業領域組織（如伺服器管理員、資料庫管理員、網路工程師）
• 優勢：專業知識深度和技能發展
• 劣勢：跨團隊協作困難，交接等待時間長

矩陣導向（Matrix-Oriented）#

• 試圖結合功能導向和市場導向的優勢
• 個人同時向功能主管和專案/產品主管報告
• 實務上往往導致混淆和衝突，員工需要同時滿足多個主管

市場導向（Market-Oriented）#

• 按客戶、產品或價值流組織
• 每個團隊是跨功能的，擁有交付客戶價值所需的全部技能
• 優勢：快速回應市場需求，減少跨團隊交接
• 這是 DevOps 最推崇的組織方式

在技術價值流中，採用市場導向的團隊結構，意味著每個產品團隊應包含（或能取用）開發、QA、安全和營運的能力，使其能夠獨立地設計、開發、測試、部署和運營服務。

過度功能導向的問題#

當組織過度採用功能導向結構時，常見的問題包括：

• 長交接等待時間：工作在團隊間傳遞時產生大量等待
• 大批量工作：為了減少交接次數，工作被累積成大批量，增加前置時間
• 缺乏端到端責任：沒有人對整個價值流的成果負責
• 回饋循環斷裂：開發人員與其程式碼的生產行為隔離

啟用市場導向團隊#

為了實現快速流動和可靠性，需要小型、跨功能的團隊，他們能夠：

• 獨立開發、測試和部署程式碼到生產環境
• 對其服務的完整生命週期負責（“you build it, you run it”）
• 與其他團隊保持鬆耦合的關係，減少協調開銷

團隊規模：兩個披薩原則#

Amazon 的 Jeff Bezos 提出的**「兩個披薩團隊」**（two-pizza team）原則——團隊應小到兩個披薩就能餵飽（通常 5-10 人）。小團隊的好處：

• 減少溝通開銷
• 建立更高的信任和共識
• 更快做出決策
• 更容易維護共享的程式碼標準

使架構支持團隊自主#

僅僅改變組織結構是不夠的——系統架構也必須支持團隊的自主性。如果多個團隊共享一個緊密耦合的單體應用（monolithic application），即使團隊是跨功能的，他們仍然無法獨立部署。

架構特徵的重要性#

• 鬆耦合架構（如 microservices）讓團隊能獨立開發和部署
• 有界上下文（Bounded Context）：每個服務應封裝其領域邏輯，透過版本化的 API 與外界溝通
• 避免共享資料庫：共享資料庫是緊密耦合的常見來源

2015 State of DevOps Report 發現，與架構相關的實踐（如使用有界上下文和建立鬆耦合系統）是持續交付的最強預測因子之一，甚至強於團隊使用何種工具。

保持團隊小而自主#

每個服務或專案應該由一個小團隊「擁有」，該團隊負責：

• 編寫和維護程式碼
• 自動化測試
• 部署到生產環境
• 支援生產中的服務（on-call）

當團隊成長太大或系統太複雜時，應考慮拆分團隊和服務，而非持續增加人力。

結論#

透過理解和運用 Conway’s Law，我們可以有意識地設計組織結構和系統架構，使其相互支持而非相互阻礙。市場導向的小型跨功能團隊，搭配鬆耦合的服務架構，是實現 DevOps 目標——快速流動、快速回饋和持續學習——的組織基礎。