🎯 什麼情境該想到我
當你發現「系統架構總是長得像組織圖」、或跨團隊協作成本高到架構改不動時。
⚙️ 怎麼用
「設計系統的組織，其產出的架構會複製該組織的溝通結構。」
- 想要某種架構，先設計對應的團隊結構（逆康威）：想要獨立的微服務，就要有能獨立負責的小團隊。
- 一個服務由一個團隊擁有：邊界對齊團隊，減少跨團隊的協調摩擦。
- 團隊之間的介面 = 服務之間的介面：把高頻溝通留在團隊內，團隊間走清楚的契約。
- 組織重組時，預期架構也會（該）跟著變。
★ 原始陳述與它真正的含意
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
—— Melvin Conway, 1967
白話：系統的架構，會長成你的組織溝通結構的樣子。
為什麼必然如此：
兩個模組要能協作 → 兩群人要能溝通
溝通成本高的兩群人 → ★ 會傾向把介面定義得「簡單、少變動」
溝通成本低的一群人 → ★ 會傾向讓模組之間緊密耦合（因為改起來很方便）
★ 這不是「應該」的規範，是「已經發生」的觀察。
你的架構圖畫什麼不重要；真正決定架構的是「誰跟誰能輕鬆講上話」。
★ 逆康威手法（Inverse Conway Maneuver）
既然組織結構會決定架構，那就「先改組織，讓它長成你要的架構」。
想要：三個獨立部署、鬆耦合的服務
❌ 做法：一個大團隊分工寫三個服務
→ ★ 因為他們天天在一起，介面會越切越細、越耦合，最後還是一坨
✅ 做法：先分成三個「有完整能力、能獨立出貨」的團隊
→ 跨團隊溝通有成本 → 自然會把介面定得粗、穩定、少變動
★ 這是組織設計成為技術決策的少數場合之一，而且它的效果遠大於任何架構規範文件。
★ 「完整能力團隊」的判準
| ❌ 依技能分（水平切） | ✅ 依價值流分（垂直切） |
|---|---|
| 前端組、後端組、DBA 組、QA 組 | ★ 每個團隊有前端、後端、資料、測試 |
| ★ 一個功能要跨四個組排程 | ★ 一個團隊能從需求到上線自己走完 |
| 交接多、等待多 | 交接少 |
| ★ 沒人對「結果」負責 | 團隊對結果負責 |
★ 判準：這個團隊能不能「自己把一個功能送到使用者手上」？
不能 → 它會產生大量的跨團隊協調成本，而那個成本最終會以「耦合的架構」的形式固化下來。
★ 團隊拓撲（Team Topologies）的四種團隊
| 類型 | 做什麼 |
|---|---|
| ★ 串流對齊團隊（stream-aligned） | 對某條價值流負責，端到端。大多數團隊都該是這種 |
| 賦能團隊（enabling） | 幫其他團隊提升能力，不代做 |
| 複雜子系統團隊 | 需要專業知識的部分（推薦演算法、風控引擎） |
| ★ 平台團隊 | 提供自助服務的內部平台，降低其他團隊的認知負荷 |
★ 平台團隊的關鍵是「自助」：
如果其他團隊要「開單請平台團隊幫忙」，那它不是平台，是瓶頸
——而且這個瓶頸會在架構上表現為「所有服務都依賴某個中心元件」
（見 自助服務平台）。
★ 認知負荷才是團隊規模的真正限制
一個團隊能負責多少東西，取決於它的認知負荷上限，不是人數。
團隊負責的服務越多、技術棧越雜、領域越廣
→ ★ 認知負荷超載 → 品質下降、交付變慢、人員流失
★ 這解釋了「兩個披薩團隊」為什麼有效——不是因為 6–8 人這個數字神奇，
而是因為超過這個規模，溝通路徑（）與認知負荷就開始失控
（見 兩個披薩團隊、工具-布魯克斯定律）。
降低認知負荷的手段：縮小團隊負責的領域、提供好的平台與工具、減少團隊需要知道的「別人的細節」（這正是好的邊界在做的事）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★ 逆康威手法的代價很高。改組織會影響人的職涯、歸屬感與士氣。
不要為了一個架構偏好就重組——要有清楚的業務理由。 - ★ 改組織不會自動改好架構。既有的程式碼不會因為組織變了就重構——
它只是讓「往正確方向演進」變得比較容易。 還是要有人去做那個重構。 - 康威定律是描述性的，不是規範性的。它告訴你「會發生什麼」，不告訴你「該怎麼組織」。
- ★ 地理與時區也是溝通結構。跨時區的團隊之間，介面自然會變粗——
這可能是好事（強制解耦），也可能是災難（需要頻繁協調的部分被硬切開）。 - 遠端工作改變了「溝通成本」的結構，所以也改變了康威定律的作用方式。不要照搬 1967 年的假設。
- 小團隊不適用。十個人的公司，康威定律說的是「你們會產生一個單體」——而那是對的。
🔗 相關工具
- 工具-限界上下文 —— 組織邊界與模型邊界的對應
- 工具-服務邊界與演進式拆分 —— 架構邊界怎麼演進
- 兩個披薩團隊 —— 團隊規模與溝通路徑
- 工具-布魯克斯定律 —— 加人不會讓延遲的專案更快
- 自助服務平台 —— 平台團隊不該是瓶頸
- 康威定律作為設計工具 —— DevOps 視角的同一個概念
- 工具-心理安全感 —— 團隊能不能有效溝通的前提
- 人月神話