康威定律：組織結構決定產品架構

事件

1967 年，系統設計師梅爾文．康威發表一個簡潔卻深刻的觀察：任何設計的系統，其結構必然反映製造它的組織結構。他用一個經典例子說明──若一個公司分成 4 個獨立團隊去開發編譯器，最終的編譯器幾乎必然是 4 遍編譯（4-pass compiler）。

這不是巧合，而是組織溝通成本的必然結果。微軟早期的 Office 套件印證了這個定律的反面：Word、Excel、Outlook 各自由不同團隊開發，團隊之間的溝通成本極高，導致最終產品之間互動困難、介面不一致、集成體驗糟糕。

亞馬遜執行長貝佐斯在 2002 年發佈著名的命令，試圖打破這個詛咒。他強制所有團隊必須將內部功能以服務介面的形式公開暴露，禁止直接呼叫他人程式碼。這個看似激進的組織改造，實際上是為了強制架構去耦合。當團隊之間只能透過清晰定義的服務邊界通訊時，產品架構自然而然就變成了微服務導向的模組化設計。

商業邏輯

康威定律揭示了一個管理悖論：大多數組織希望產品是模組化、可互操作的，卻忽視了實現這一目標的前置條件──組織本身也必須是模組化的。

這意味著，對於初創企業來說，招聘決策不應該是被動反應市場需求，而應該是主動設計未來。創辦人必須先清晰想像產品在 3-5 年後的樣子（可拆解嗎？邊界在哪裡？哪些模組會獨立演化？），然後據此建構早期團隊結構。招聘的不只是填補空位，而是在塑造組織的溝通圖譜。

反過來，當產品架構開始腐爛時，根本原因往往不是技術決策差，而是組織結構已經不適配。此時的解藥不是推倒重寫，而是先重組。許多大型科技公司的內部平台團隊、API 標準化運動、跨部門委員會，本質上都是在試圖重塑組織溝通邊界。