組織應被視為複雜的調適性有機體，而非機械式的線性系統。

——娜歐米・史丹佛（Naomi Stanford），《Guide to Organisation Design》

社會技術設計從未如此重要#

技術工作者處於持續行動的狀態：以難以置信的速度創造並更新系統，組合不同類型的技術以打造引人入勝的使用者體驗。行動應用、雲端服務、網頁應用，以及嵌入式、穿戴式或工業物聯網裝置，都必須有效互通，才能達成期望的業務成果。

這些系統以日益深刻的方式，影響人們日常生活的幾乎每個面向。若軟體設計不良——更關鍵的是，若軟體、提供者與顧客三者的互動出現落差——人們就會受害：叫車應用故障，可能讓人被困在離家極遠之處；網路銀行的軟體或流程失效，可能讓人繳不出房租；醫療裝置失效，甚至可能危及生命。明確的社會技術設計（sociotechnical design）從未如此重要。

建造與營運這些高度複雜、彼此互連的軟體系統是團隊活動，需要跨平台、不同技能的人共同投入。同時，現代 IT 組織必須快速且安全地交付與營運軟體系統，並在業務或法規環境的變動與壓力中成長、調適。

企業已不能再於「為穩定而最佳化」和「為速度而最佳化」之間二選一。

儘管風險與要求如此，許多組織仍以不利於現代軟體開發與維運的方式組織人與團隊。過度倚賴組織圖與矩陣來切分及控制工作的組織，往往無法創造出「既能擁抱創新、又能維持快速交付」的必要條件。

要在這件事上成功，組織需要：

• 穩定的團隊，以及有效的團隊樣式與互動
• 投資於被賦權、有能力的團隊，作為敏捷與調適力的基礎
• 能夠感知情境變化並隨之演化的團隊與人

好消息是，只要抱持正確心態、使用同時強調調適性與可重複性的工具，並把團隊與人放在中心，快速與安全是可以兼得的。誠如施瓦茨（Mark Schwartz）等人在 2016 年論文《Thinking Environments》所言：「組織結構必須協調各項當責，以支持交付高品質、具影響力軟體的目標。」

身為管理這些介面的技術團隊成員，我們必須轉換思維：不再把團隊當成「只要遵循『對的』流程、使用『對的』工具就會成功」的可替換個體集合，而是把人與技術視為單一的人／機、碳基／矽基社會技術生態系。同時，我們必須確保團隊具備內在動機，並在這樣的系統中真正有機會做出最好的工作。

組織的溝通結構#

多數組織想要（或被要求）擁有一份關於團隊與人的單一視圖，也就是「組織圖」（org chart）。這張圖描繪團隊、部門、單位與其他組織實體，以及彼此的關係，通常呈現層級式的匯報線，並隱含著「上下流動」的溝通路徑。

在建造軟體系統的脈絡中，組織圖確實有其用途，尤其是在法規與法遵方面。然而，在高度協作、成果充滿不確定性的環境裡，把組織圖當作切分工作的主要機制會導出不切實際的期待。我們該倚靠的，是解耦、長期存續、能有效協作的團隊，以應對速度與安全的平衡難題。

照單全收組織圖的問題在於：我們最後會試圖「架構」人——彷彿他們是軟體，溝通只會乖乖留在被認可的線條裡。

但人不會把溝通侷限在圖上那些連線。我們會去找任何完成工作所需仰賴的人，必要時也會為了達成目標而變通規則。這就是為什麼真實的溝通線與組織圖差距甚大。

組織圖思維才是問題所在#

傳統組織圖無助於我們理解組織中真實的溝通樣態。組織需要的是更貼近現實的圖像——關於個人與團隊之間預期的與實際的溝通。兩者之間的落差，能反過來告訴我們哪一類系統更適合這個組織。

更麻煩的是，基於組織圖結構所做的決策，往往只為組織的一部分最佳化，忽略了上下游效應。局部最佳化幫得了直接涉入的團隊，卻不必然改善「交付給顧客的整體價值」；若工作流中存在更大的瓶頸，其影響甚至微不足道。

一個具體例子：讓團隊採用雲端與基礎設施即程式碼（infrastructure-as-code），可以把佈建新基礎設施的時間從數週、數月壓到數分鐘、數小時。但如果每次變更都需要一個每週才開一次會的委員會核准才能部署到正式環境，交付速度充其量仍是「以週計」。

系統思考聚焦於為整體最佳化：檢視整體工作流動、找出當下最大的瓶頸、消除它，然後重複。團隊拓撲聚焦的則是：如何建立動態的團隊結構與互動模式，幫助團隊快速適應新條件，達成快速且安全的軟體交付。這也許不是你今天最大的瓶頸，但終究你會撞上「僵化的團隊結構、糟糕的溝通、不合宜的流程」拖慢交付的問題。

把組織圖當成「工作如何完成、團隊如何互動」的忠實再現，會導出無效的工作與職責分配決策。正如軟體架構文件在實際開發一開始就過時，組織圖也永遠與現實不同步。

組織圖之外的三種結構#

若組織圖不是組織結構的準確再現，那什麼才是？《Organize for Complexity》作者普雷金（Niels Pflaeging）指出，每個組織其實同時存在三種組織結構：

1. 正式結構（組織圖）——促成法遵
2. 非正式結構——個人之間的「影響力場域」
3. 價值創造結構——工作實際如何完成，取決於人際與團隊間的聲譽

普雷金主張，知識工作型組織能否成功，關鍵在於非正式結構與價值創造結構之間的互動——也就是人與團隊之間的互動。拉盧（Frédéric Laloux）的《Reinventing Organizations》與羅伯森（Brian Robertson）的合弄制（Holacracy）也提出了類似的刻畫。

團隊拓撲取徑承認普雷金所定義的非正式結構與價值創造結構之重要性：

• 賦權團隊、把團隊當作基本構件：團隊內的個人因而更靠近彼此，行動如一個團隊，而非只是一群人。
• 明確地就互動模式達成共識：對行為的期待變得清晰，團隊之間的信任隨之增長。

靜態結構與重組之痛#

過去數十年出現過許多組織經營的新取徑，但新設計通常仍停留在組織的靜態視角，未考慮重組之後真正浮現的行為與結構。例如 1990 年代開始、其後二十年相當流行的「矩陣式管理」，試圖以「個人同時向業務主管與職能主管匯報」來處理高度不確定、高度技能工作的內在複雜性。相較於純職能式的團隊組織，它確實更聚焦於商業價值，但這仍是一種靜態世界觀，會隨業務與技術領域的快速演化而過時。

對員工而言，導入矩陣式管理這類重組往往帶來大量恐懼與擔憂，經常被視為「更可能讓業務倒退而非前進」的時間與心力消耗。而一旦下一波技術或方法論革命來襲，企業又再啟動一次重組，打斷既有的溝通形式，拆散那些好不容易才進入狀況的團隊。

倚賴單一的靜態組織結構（無論是組織圖還是矩陣式管理），對現代軟體系統而言顯然已無法支撐有效成果。我們需要的不是單一結構，而是一個能適應當前處境、把「團隊如何成長與互動」納入考量的模型。

團隊拓撲取徑補上了傳統組織設計所缺少、而技術組織所需要的動態面向與感知面向。

團隊拓撲：思考團隊的新方式#

團隊拓撲取徑為「企業軟體交付的有效團隊結構」帶來新的思考。它提供一套一致、可付諸行動的指引，用以演化團隊設計，持續應對技術、人員與業務的變化，涵蓋建造與營運現代軟體系統之團隊的規模、形態、位置、職責、邊界與互動。

團隊拓撲提供：

• 四種基本團隊類型——流動對齊（stream-aligned）、平台（platform）、賦能（enabling）、複雜子系統（complicated-subsystem）
• 三種核心團隊互動模式——協作（collaboration）、X 即服務（X-as-a-Service）、促進（facilitating）

再加上對康威定律、團隊認知負荷，以及「如何成為能感知的組織」的認識，團隊拓撲共同構成一套有效且具人本精神的軟體系統建造與營運取徑。

它特別關注不同團隊拓撲如何隨技術與組織成熟度演化。技術與產品的探索期通常需要高度協作的環境（團隊邊界重疊）才能成功；但當探索結束（技術與產品已然確立）仍維持同樣的結構，就會導致心力浪費與彼此誤解。

藉由強調組織設計的調適性模型、主動優先考慮團隊之間的相互關係，團隊拓撲為現代軟體密集企業提供了一個技術中立的關鍵機制：去感知何時需要改變策略（無論從業務或技術視角）。最終目標是幫助團隊產出貼合顧客需求、且更易於建造、營運與擁有的軟體。

團隊拓撲也強調設計與建造軟體系統的人本取徑。它把團隊視為軟體交付不可分割的元素，並承認團隊的認知容量有限、必須被尊重。結合穩固奠基於康威定律的動態團隊設計，團隊拓撲成為一項用於解法探索的策略工具。

康威定律的復興#

我們提到康威定律是團隊設計與演化的驅動力。但這條定律究竟是什麼？

1968 年，電腦系統研究者康威（Mel Conway）在《Datamation》發表論文〈How Do Committees Invent?〉，探討組織結構與系統設計成果之間的關係。文章充滿精彩洞見，而其中這句話成了眾所周知的康威定律：

「設計系統的組織……受限而只能產出複製其自身溝通結構的設計。」

康威的觀察建立在建造早期電子計算機系統的組織之上。用他的話說，這條「定律」指出組織真實溝通路徑（即普雷金所說的價值創造結構）與最終軟體架構之間的強烈相關性——作者凱利（Allan Kelly）稱之為同態力（homomorphic force）。這股力量傾向於讓軟體架構與團隊結構長成同樣的形狀。

換句話說，建造軟體必須先理解跨團隊的溝通，才能務實地判斷哪些軟體架構是可行的。若理想中的理論架構不符合組織模型，兩者之中必有一者得改變。

雷蒙（Eric Raymond）在《The New Hacker’s Dictionary》中幽默地表達了同一件事：「如果你有四組人在做一個編譯器，你會得到一個四階段（4-pass）的編譯器。」

自 1968 年以來，康威定律持續適用於所有被建造出來的軟體，這一點越來越清楚。凡是建造過必須符合某份「架構藍圖」之系統的人，大概都記得那種「彷彿在與架構搏鬥、而非被架構引導」的時刻——那正是康威定律在起作用。

反向康威操作#

康威定律在 2015 年前後迎來一波「復興」，當時微服務（microservices）架構正在興起。ThoughtWorks 技術總監路易斯（James Lewis）等人提出了反向康威操作（inverse／reverse Conway maneuver）的構想：組織不再期待團隊去遵循某個被指定的架構設計，而是專注於組織團隊結構去匹配他們希望系統呈現的架構。

這裡的關鍵啟示是：把軟體架構當成一個可以獨立設計、再交由任何一組團隊實作的獨立概念，根本上是錯的。

這道「架構與團隊結構之間的鴻溝」在所有架構類型中都看得見——從主從式（client-server）到 SOA，甚至微服務皆然。

團隊結構必須匹配所需的軟體架構，否則就得冒著產出非預期設計的風險。這也正是為什麼單體（monolith）需要被拆解——尤其是任何超出單一團隊認知容量的不可分割軟體部件——同時仍保持團隊視角。此主題將在第 6 章深入討論。

認知負荷與瓶頸#

談到認知負荷（cognitive load），我們很容易理解：任一個人在任一時刻能存放於腦中的資訊量都有極限。把團隊成員的認知容量加總起來，同一件事也發生在任一團隊身上。

然而，我們在指派職責或分配軟體部件給某個團隊時，卻幾乎從不討論認知負荷。也許是因為「可用容量」與「將產生的認知負荷」都難以量化；也許是因為我們預設團隊就該無條件適應被交辦的一切。

當認知負荷未被納入考量，團隊會被攤得太薄——試圖涵蓋過量的職責與領域。這樣的團隊沒有餘裕去追求專業精熟，並持續承受情境切換的成本。

雖然上述實例中的團隊提供的是給開發團隊的內部服務，但對於為外部顧客開發軟體的團隊，效應完全相同：產品團隊所負責的服務與元件數量（也就是對團隊的需求）通常會隨時間持續成長；然而新服務的開發卻常被規劃成「彷彿團隊有全職可用時間、且起始認知負荷為零」。這種忽視相當要命，因為團隊同時仍被要求修復與增強既有服務。最終，團隊的認知容量被大幅超載，成為交付瓶頸，導致延遲、品質問題，以及成員動機的下滑。

我們必須把團隊放在第一位，主張限制其認知負荷。明確地思考認知負荷，可以成為決定團隊規模、指派職責、以及建立與其他團隊之邊界的強大工具（詳見第 3 章）。

整體而言，團隊拓撲取徑主張的組織設計，是為變更的流動與來自運行中系統的回饋而最佳化。這要求我們限制團隊的認知負荷，並明確設計團隊之間的相互溝通，以（依康威定律）產出我們所需要的軟體系統架構。

本章總結：重新思考團隊的結構、目的與互動#

為現代互連的系統與服務有效開發並營運軟體，要求組織考慮許多不同面向。歷史上，多數組織把軟體開發視為一種製造業——由分屬各職能專長的獨立個人完成，大型專案事先完整規劃，幾乎不考慮社會技術動態。這導致了種種普遍存在的問題。

敏捷（Agile）、精實 IT（Lean IT）與 DevOps 運動幫助證明了「更小、更自主、與業務流動對齊的團隊」具有巨大價值——以小而反覆的週期開發與發布，並依使用者回饋修正航向。精實 IT 與 DevOps 也推動了系統與團隊在遙測與度量工具上的大步進展，讓建造與營運軟體的人能依過往趨勢做出主動、提早的決策，而非只是在事故與問題發生時被動回應。

傳統組織往往因其組織模型，而無法完整收割敏捷、精實 IT 與 DevOps 的好處。

難怪大家會強烈聚焦於較立即可見的自動化與工具導入，而文化與組織的改變卻被草率帶過——後者的改變更難被具象化，遑論衡量其成效。然而，擁有正確的團隊結構、取徑與互動，並理解它們需要隨時間演化，才是長期成功的關鍵差異因子。

具體來說，傳統組織圖與這個新現實已然脫節——在充滿不確定與新意的環境中，協作式知識工作需要頻繁地（重新）形塑團隊。取而代之，我們需要善用：

• 康威定律——組織設計勝過軟體架構設計
• 認知負荷的限制
• 團隊優先取徑

以此設計出目的清晰的團隊，並促成那些以「軟體交付的流動」與「策略調適力」為優先的團隊互動。

團隊拓撲的目標，是給你一套取徑與心智工具，讓你的組織能夠調適，並動態地找出何時何地需要協作，以及何時最好專注執行、降低溝通開銷。