建立小而被賦權的單位，對績效的第二個效應，是提高對新資訊的調適速度。

——約翰・羅伯茲（John Roberts），《The Modern Firm》

那些揮之不去的老問題#

多數組織的軟體交付多年來一直為問題所困——那些新技術總是承諾要解決、卻鮮少（或從未）解決的問題：

• 團隊投入度低落
• 技術與市場變化帶來太多反覆出現的意外
• 逆著康威定律推進
• 軟體長得對團隊而言太大
• 令人困惑的一堆組織設計選項與交付框架
• 團隊被拉往許多不同方向
• 每隔幾年就來一次痛苦的重組
• 糟糕的變更流動

並非每個組織都有全部這些問題，但多數組織有其中一些，許多組織幾乎全中——儘管他們一再試圖避免。那麼，這些持續問題的成因是什麼？

之所以這麼多組織在軟體交付上經歷這麼多問題，是因為多數組織對「軟體開發究竟是什麼」抱持一套無益的模型。

對「功能交付」的執迷，忽視了現代軟體中內在的人員與團隊動態，導致員工缺乏投入——尤其當認知負荷被超載時。

同時，康威定律的真實意涵幾乎完全被多數組織忽視：好的情況是在架構選擇上撞了好運，壞的情況則是組織持續耗費時間心力去「對抗」那股同態力，摩擦不斷。同樣地，許多組織並不知道一次選擇不當的「重組」，能如何摧毀組織在創新與可持續軟體交付上的策略能力。

此外，團隊模型與規模化交付框架多得令人眼花，彼此之間卻看不出多少區別；而團隊的行為樣式也鮮少被明確界定，使團隊在「如何與其他團隊有效互動」上缺乏清晰指引，結果不是跨團隊耦合過緊，就是一種無法真正規模化的孤立式自主。

團隊拓撲透過提出一套軟體交付的團隊優先取徑，來處理上述所有問題——它奠基於四種基本團隊類型、三種團隊互動樣式，以及「運用交付中的困難，賦予組織感知周遭環境之能力」的方法。

實際上，團隊拓撲提供了一套定義良好的團隊互動與相互關聯方式，讓最終的軟體架構更清晰、更可持續，並把跨團隊的問題轉化成自我導航型組織的珍貴訊號。

四種團隊類型與三種互動模式#

建造與營運一套軟體系統，只需要四種團隊類型就能達成；其他團隊類型可能對組織造成主動的傷害。

四種基本團隊拓撲：

• 流動對齊（stream aligned）：對齊到業務變更主流的團隊，具備跨職能的技能組合，能在不等待其他團隊的情況下交付有意義的增量。
• 平台（platform）：在底層平台上工作、支撐流動對齊團隊交付的團隊。平台簡化了原本複雜的技術，並降低使用它之團隊的認知負荷。
• 賦能（enabling）：在過渡或學習期間，協助其他團隊採用與調整軟體的團隊。
• 複雜子系統（complicated subsystem）：對某個「複雜到一般流動對齊團隊或平台團隊處理不來」的子系統負有特殊職權的團隊。選配，只在真正必要時才使用。

這幾種特定團隊類型的組合，就是「具快速流動之有效軟體交付」所需的全部。然而，這四種拓撲之間的互動模式，對於理解並滋養有效的軟體交付至關重要：

• 協作模式：兩個團隊為共同目標一起工作，特別是在探索新技術或新取徑時。因為學習步調飛快，這筆開銷是值得的。
• X 即服務模式：一個團隊消費另一個團隊所提供之物（API、工具，或一整套軟體產品）。協作降到最低。
• 促進模式：一個團隊（通常是賦能團隊）促進另一個團隊學習或採用新取徑。

團隊優先思維：認知負荷、團隊 API、團隊大小的架構#

要提升目的的清晰度並界定團隊的職責邊界，就選定一種基本團隊類型與一種互動模式。團隊拓撲把這種「團隊優先」取徑再往前推進幾步，引入了若干對可持續軟體交付有強烈成效的團隊相關準則。

團隊拓撲取徑把團隊視為交付的根本手段。這裡的團隊不只是「一群向同一個主管匯報的人」，而是一個擁有自身學習、目標、使命與合理自主性的實體。

團隊一起學習、一起交付，因為當這件事發生時，成果會遠遠勝過個人的加總。

團隊所考慮的對外「API」，不只包含程式碼，也包含文件、上手流程、與其他團隊的面對面與聊天工具互動，以及其他團隊要與其成員互動所需的一切。

為避免軟體越長越大、最終壓垮團隊，子系統（或元件）的規模被限制在單一團隊可管理的範圍內。具體而言，就是避免超出團隊作為一個團隊所能應付的認知負荷上限，確保整個團隊都能自在面對其複雜度與心智開銷。

這種「團隊大小的架構」以人為先，相較於單體架構或微服務架構（兩者都以技術為先），是一種更可持續、更具人性的軟體架構取徑。

康威定律的策略性運用#

早在 1968 年，康威（Mel Conway）就對「組織的溝通結構」與「最終系統設計」之間的關係提出了絕妙洞見，而它已成為今日軟體密集組織的強大賦能者（同時也是限制）：

那些能導出「讓設計者之間更有效率地溝通」之技術的研究，將在系統管理的技術中扮演極為重要的角色。

在今日的脈絡與術語中，「設計者」一詞可以替換成「軟體團隊」。換句話說，重構團隊、促進（或可能是刻意限制）團隊之間的溝通，能大幅提高「建造出在正式環境運作良好、且長期演化起來感覺自然的系統」的機會。

這裡的推論是：協作增加，並不等同於溝通增加。

也就是說，如果我們知道需要以短前置時間獨立部署系統的不同部分，並為此決定採用小而解耦的服務，那我們就必須讓團隊同樣小而解耦，並具備清楚的職責邊界。

即使是績效導向的組織，也可能因為其團隊組織方式而阻礙了有效技術與實踐的採用。例如，軟體架構師所做的大型前期設計註定失敗——除非那些設計與團隊的溝通方式對齊。

微服務這類雲端軟體的建造與營運取徑，同時滿足了「人類尺度的功能區塊」與「更佳的可部署性」兩項需要。如果團隊能理解構成部件、對程式碼有擁有感，而不是被當成裝配線上的工人，他們創新與支撐系統的機會就大得多。承諾理論（見第 7 章）這類取徑，能幫助團隊提升對程式碼與 API 日常實質的擁有權。

因此，自行開發並營運軟體系統的組織，必須以與過去截然不同的方式來設立自己的組織。

團隊結構必須匹配所需的軟體架構，否則就得冒著產出非預期設計的風險。

為調適力與感知而演化組織設計#

組織不只需要考慮某個時間點的團隊結構——團隊結構與溝通路徑必須隨技術與組織成熟度而演化。

技術與產品的探索期，通常需要高度協作的環境（團隊邊界淡化）才能成功；但當探索結束（技術與產品已確立）仍維持同樣的結構，就會導致心力浪費與彼此誤解。

具體而言，組織應當預期：團隊先協作以發現新的樣式與執行模型，然後把這些成果向下推進到平台與支援性工具之中。

團隊拓撲不是靜態的，它能夠也應當隨情況改變而改變。在決定「哪一組基本團隊拓撲與互動模式最符合組織當下需要」時，有多重因素會納入考量。

光有團隊拓撲，不足以帶來 IT 成效#

團隊拓撲取徑對世界上許多組織而言是一大步進展：它提供了「不同團隊組合與互動如何運作、為何運作、何時該用」的洞見，並在特定情境下給出可依循的實務建議與樣式。

除了本書所建議的結構與動態之外，成功還需要以下重要成分：

• 健康的組織文化：一個支持個人與團隊專業發展的環境——人們感到被賦權、能安全地說出問題，而組織期待持續學習。
• 良好的工程實踐：系統所有面向的測試優先設計與開發、對持續交付與可運作性實踐的重視、以結對與群體編程進行程式碼審查、避免為事故尋找單一「根本原因」、為可測試性而設計等。
• 健康的資助與財務實踐：避開「IT 組織不同部分之間 CapEx／OpEx 分野」的惡性效應（至少透過抽樣估算 CapEx/OpEx 來緩解最糟的部分）、盡可能避免專案驅動的期限與大批量預算編列，以及把訓練預算配給團隊或群組而非個人。
• 業務願景的清晰度：高階主管或領導層為組織其餘部分提供清晰、不相互衝突的願景與方向，時間視野落在人類可感知的尺度上（如三個月、六個月、十二個月），並清楚說明優先序背後的推理，讓組織中的人理解這些是如何、又為何被選出來的。

團隊拓撲取徑就像「花木配置的說明書」，加上修剪與整枝的樣式；而文化、工程與財務要素，則像是幫助植物健康生長的土壤、水與肥料。

不健康的文化、糟糕的工程實踐、負面的財務影響，在這座花園裡全都是毒藥或生長抑制劑。即使團隊拓撲提供了絕佳的修剪與種植樣式，若環境條件充滿敵意，也不能指望軟體生長茁壯。

而業務願景的欠缺，就好比要一支園藝團隊去「造一座花園」，卻完全不說明這座花園的用途：我們該種水果還是蔬菜？是要一年四季繽紛，還是只在夏天？這座花園是用來冥想，還是另有他用？同理，組織中目的與願景的清晰，能為所有人設定好脈絡，讓大家的行動都朝向那個目的。

下一步：如何開始運用團隊拓撲#

一、從團隊開始#

首先，作為一個組織，自問：團隊需要什麼，才能夠……

• 作為一個有效的團隊行動與運作？
• 有效地擁有軟體的一部分？
• 專注於滿足使用者的需要？
• 減少不必要的認知負荷？
• 向其他團隊消費與提供軟體及資訊？

誠實地回答這些問題，應當會導出以下這些團隊優先的取徑：辦公空間、開發者工具、平台可用性、務實的子系統／領域切分、對團隊友善的架構、豐富的遙測等等。

從團隊出發之後，你就能處理現代軟體快速流動的其他重要面向：對齊到流、平台，以及支持並增強團隊工作的額外能力。

二、辨識合適的變更流#

每個組織都必須選出一組變更流，作為最重要之變更所流經的「管道」。這些流是組織內流動的主要焦點，組織內所有其他工作的存在（直接或間接地）都是為了促進這些流中的流動。

究竟該選什麼作為流，高度取決於組織的性質，但典型的流可能是：

流動對齊團隊應當對齊到你所辨識出的這些流。這些高階的流，應當匹配來自組織核心的「變更壓力」。

若目前沒有一組清晰或明顯的變更流，通常值得先把它們辨識出來，再往下走。

三、辨識一個最薄可行平台（TVP）#

辨識出組織最相關的流之後，接著辨識「支撐這些流中可靠而迅速之變更流動」所需的服務。實務上，這些服務會構成流所依賴的平台。

如第 5 章所述，平台不必是龐大而昂貴的投資。相反地，平台可以「剛好夠大」到滿足這些流的流動需要——從「一份幫助團隊使用底層服務的 wiki 文件」，到「為滿足流動對齊團隊專門需要而自建的完整客製技術解決方案」皆可。

平台自然會隨技術生態系演化而演化。平台團隊起初可能需要為（例如）基礎設施佈建自建解法，但幾年後可能丟棄那些工作，改用一個新出現、更契合產業趨勢的開源或雲端供應商方案。

請記得：技術永遠只是平台的一部分。路線圖、引導式的演化、清晰的文件、對 DevEx 的關注，以及對底層複雜度的適當封裝，全都是「對流動對齊團隊而言有效之交付平台」的關鍵組成。

四、辨識在教練、指導、服務管理與文件上的能力落差#

以團隊優先取徑為基礎、圍繞由平台賦能的核心變更流，是組織很好的起點；然而，要讓這套配置運作起來所需的能力與技能，比許多組織所預期的更為多樣、也更不常見。

你必須確保團隊中不只有專注於程式碼或電腦系統的技術人員，還要有具備其他技能的人。特別是理解並實踐以下事項的人：

• 團隊教練（team coaching）
• 指導（mentoring，尤其是對資深員工）
• 服務管理（適用於各類團隊與領域，不只是正式環境系統）
• 寫得好的文件
• 流程改善

這類能力幫助組織內的團隊持續改善其實踐、溝通並與其他團隊互動，這反過來又幫助整個組織安全地提升變更流動的速率。

五、分享並演練不同的互動模式，說明新工作方式背後的原則#

許多人從未真正經驗過團隊優先的工作方式，因此那對他們而言會顯得陌生。

• 花時間說明並示範團隊互動模式
• 說明為什麼有些團隊靠得更近、有些團隊離得更遠
• 說明康威定律的基本原理，以及有意識地設計團隊與相互溝通如何能藉由收窄解法搜尋空間、為所有人省下時間心力，來改善所建系統的軟體架構

最重要的是，強調團隊拓撲的人本面向：對團隊的重視、對認知負荷的明確限制、團隊優先辦公空間帶來的噪音與打斷減少，以及對「人人皆可對人人溝通」的限制。

指出焦點在於核心業務流的快速變更流動，並由「最薄可行平台」及相關團隊與教練支撐。

最重要的是——分享團隊拓撲取徑如何為人、軟體系統與組織本身帶來更好的成果。