為了在解決複雜問題時取得最好的集體表現，技術與組織應當被重新設計，讓人們間歇性地與彼此的工作隔離。

——伯恩斯坦（Ethan Bernstein）、蕭爾（Jesse Shore）、拉澤（David Lazer），〈How Intermittent Breaks in Interaction Improve Collective Intelligence〉

第二部呈現了四種基本團隊拓撲的組合，如何為「具快速流動的軟體交付」提供清晰樣式。然而，光把團隊排成某種樣式並不足以帶來高效能；我們還必須辨識這些團隊如何互動，以及何時該改變團隊與其互動。

第三部探討「團隊互動的演化」如何成為建造軟體系統之組織的策略優勢。透過「定義良好的團隊互動樣式」與「演化團隊拓撲的清晰啟發法」的組合，組織能把團隊互動當作一套感知機制，用於創新，並自我導航向更好的顧客或使用者成果。

選定一次團隊邊界就期待不再有任何變動是不夠的；組織必須預期團隊樣式需要演化，以滿足業務、組織、市場、技術與人員上的需要。

當團隊在某個領域累積更多經驗、新技術出現，或組織規模擴張與收縮時，團隊之間的動態與經濟性（尤其是規模經濟）都會改變，而團隊拓撲的選擇能幫助促成那項改變。在某些情況下，同樣兩個團隊在某個時點可能需要緊密協作，但六到九個月後卻該彼此獨立，才能達成最有效的軟體交付成果。

本章探討三種核心團隊互動模式，它們簡化並釐清了建造軟體系統之團隊間所必需的互動：協作（collaboration）、X 即服務（X-as-a-Service）、促進（facilitating）。

定義良好的互動是有效團隊的關鍵#

在許多組織中，定義不良的團隊互動與職責是摩擦與無效的來源：

• 一個團隊可能被告知它是自主、自組織的，但成員卻發現自己得與許多其他團隊互動才能完成工作——這令人挫折
• 另一個團隊可能負責提供 API 或服務，卻其實沒有足以有效做到這件事的經驗

在考慮任何團隊之間的關係時，一個關鍵決定是：要與另一個團隊協作以達成目標，還是把對方當作服務提供者？

這個「協作或消費服務」的選擇，可以在組織中的許多不同層次上做出：把基礎設施當服務消費（來自 AWS、Azure 或 Google Cloud）、在日誌與度量上協作、倚賴複雜子系統團隊建造複雜的音訊處理編解碼器，或一起處理應用部署。

必須避免的是：為了達成目的，所有團隊都得和所有其他團隊溝通。

正如爵士樂團會協調自己演奏的音樂，我們也應當審慎地策展組織內發生的溝通。

研究者近期設計了一個巧妙的實驗，評估以團隊為本的複雜問題解法之成效。伯恩斯坦與同僚發現：「那些成員只間歇性互動的群體……其解法的平均品質，與持續互動的群體幾乎相同；然而他們保留了足夠的變異，也因此找到了一些最好的解法。」

間歇性協作找到的解法，比持續互動更好。

三種基本團隊互動模式#

要理解如何以及何時調整軟體系統的團隊拓撲模型，我們必須在考量團隊優先動態與康威定律的前提下，定義並理解團隊能夠、也應當互動的三種基本方式：

• 協作（Collaboration）：與另一個團隊緊密地一起工作
• X 即服務（X-as-a-Service）：以最少的協作消費或提供某物
• 促進（Facilitating）：協助（或被協助）另一個團隊排除障礙

多數中型與大型企業很可能同時需要這三種模式的組合（而且在較小型組織中，導入這些模式的時機也比許多人預期的更早）。此外，同一個團隊可能對兩個不同的合作對象使用兩種不同的互動模式。

舉例來說，假設團隊 A 是負責個人理財軟體的流動對齊團隊。他們可能以協作模式與團隊 B 就新的雲端監控工具互動，同時以 X 即服務模式與提供軟體運行平台的團隊 C 互動。

把「建造軟體系統時團隊該如何互動」形式化，有助於更輕易地評估軟體交付諸多面向的成效，因為它更明確地定義了團隊之間的介面；而依康威定律，這些介面預期會反映在所建造的軟體系統中。

羅瑟（Mike Rother）在思考日本製造商 Toyota 的巨大成功時寫道：「Toyota 成功的根源不在其組織結構，而在於其人員身上培養出能力與習慣。」

藉由期待並協助達成這類團隊互動，團隊會經驗到目的更清晰、投入度提升，以及對其他團隊的挫折感降低。以這種方式限制團隊互動，也刻意地處理了康威定律所帶來之「建造系統的同態面向」（見第 2 章）。

團隊應當自問：「我們該與這個團隊有什麼樣的互動？我們該與對方緊密協作嗎？我們該期待或提供一項服務嗎？還是該期待或提供促進？」

協作：創新與快速探索的驅動力，但邊界會模糊#

協作：與另一個團隊緊密地一起工作

協作模式適用於「需要高度調適性或探索」的場合，特別是在探索新技術或新技法時。協作互動模式有利於快速發現新事物，因為它避開了團隊之間昂貴的交接。

例如，也許在某個橫跨團隊 A 與團隊 B 專業的領域出現了重大創新，像是雲端感測器管理（結合雲端技術與感測器技術），或穿戴裝置的安全區域網路（結合網路知識與服飾產業的專業）。協作模式要求團隊之間有良好的對齊，以及高度的協作意願與能力。

在新系統開發的早期階段，以及那些需要快速發現新資訊、技術限制與合適實踐的時期，協作模式極具價值——因為使用協作的團隊拓撲能迅速揭露新的工作方式與技術的非預期行為。

這種協作發生在技能組合不同的群體之間，藉此匯聚許多人的知識與經驗來解決有挑戰性的問題。協作帶來對技術如何運作的新洞見，並把學習帶回其他團隊（這呼應金京希與皮爾斯所述的「發散式思考」取徑）。

當一個團隊處於「探索或快速學習」的脈絡中，且該脈絡超出單一團隊的專業範圍時，它就該與另一個技能不同的團隊緊密協作。

然而，持續協作的認知負荷，可能遠高於純粹在團隊「天然」領域內工作。這意味著溝通開銷會更高，若把兩個團隊各自當作單一團隊來看，可能顯得成效下降。

實情是：這筆投資是投在兩隊合體的整體效能上——透過快速發現新的實踐。這反過來意味著：當兩個團隊以協作模式互動時，由於協作成本高昂，一起工作必須帶來高價值，回報必須是具體可見的。同時，團隊之間也應當幾乎沒有摩擦，因為任何摩擦都會讓協作變得困難。

此外，康威定律告訴我們：伴隨協作模式而來的探索與快速學習，會讓軟體的職責與架構傾向於更加混融在一起。

若你需要的是「兩個團隊之間服務或系統的清晰、定義良好的介面」，那麼長期使用協作模式很可能不是最好的選擇。短期或輕度的偶發協作（用於建立或精修介面）沒問題；但持續協作的需求，暗示著領域邊界與／或團隊職責劃錯了，或團隊內的技能組合不對。

典型用途：流動對齊團隊 × 複雜子系統團隊；流動對齊團隊 × 平台團隊；複雜子系統團隊 × 平台團隊。

X 即服務：職責清晰、交付可預期，但需要良好的產品管理#

X 即服務：以最少的協作消費或提供某物

X 即服務模式適用於「一個或多個團隊需要使用一個不太費力就『就是能動』的程式庫、元件、API 或平台」的情境——也就是系統的某個元件或面向，能由一個獨立的團隊或團隊群組有效地「以服務的形式」提供出來。

在系統開發的較晚階段，以及需要可預期交付（而非探索新取徑）的時期，X 即服務模型運作得最好。在此模型中，團隊可以倚賴技術地景中的某些面向由其他團隊（內部或外部）以服務形式提供，讓自己專注於交付本職工作。

服務中那些有挑戰性的面向，早已在先前透過緊密協作的「發散」取徑中被探索完畢，留下最有效的解法以服務形式運行。

倚賴某物「即服務」需要提供方團隊的出色工作——這不容易做到——但結果是交付團隊對非核心面向需要理解得更少，因而能更快交付。

採用 X 即服務時，誰擁有什麼非常清晰：一個團隊消費另一個團隊提供的東西。相較於協作模式，每個團隊需要的脈絡更少，因此雙方的認知負荷都可以更低。依設計，跨越該邊界的創新會比協作模式來得慢——正是因為 X 即服務有一套漂亮、乾淨、把服務定義得很好的 API。

要讓某個元件或系統面向能有效地以服務形式提供，不只職責邊界必須在業務或技術領域的脈絡下說得通，提供服務的團隊還必須擅長理解消費團隊的需要，並以服務管理原則（版本化、產品管理等）來管理自己那部分的系統。

在 X 即服務模式中，兩個互動團隊幾乎不需要日常協作就能使用或提供該元件／API／功能。

這正是 X 即服務模型的一項明確效益：若被提供的東西幾乎不需要消費團隊的互動，那麼它幾乎按定義就是高度合乎目的的，正在幫助消費團隊有效地完成工作。

這意味著在 X 即服務模型下，「某些團隊能夠忽略其所消費服務的低階細節」必須帶來高價值，讓他們得以快速前進而不必操心實作細節。

X 即服務模型只有在服務邊界選得好、實作得好，且提供方團隊具備良好服務管理實踐時，才會運作良好。

無論提供的是元件、API、測試工具還是一整套交付平台，負責的團隊都必須對「消費者」與「所提供之物的可行性」有強烈的責任感：

• 必須讓開發者體驗（DevEx）極具吸引力
• 所提供的服務應當易於使用、測試、部署與／或除錯
• 使用文件應當清晰、寫得好、保持更新
• 服務必須以「讓它長期保持可行」的方式被管理

消費團隊提出的新功能請求會被納入考慮，但不會只因為某個團隊要求就去建造。

取而代之，這個東西的目的與職權範圍，是以所有消費者的最佳利益為念而演化的，增強功能經過審慎排程，並與其他團隊商議後規劃。

即使是一個做低階 XML 轉換的簡單程式庫，也能從套用產品管理與 DevEx 原則中獲益：建造並支援它的團隊應當思考版本化與向後相容、溝通舊版本退場的路線圖、協助使用者移轉到新版本等等。對於任何比程式庫更大的東西，這些 X 即服務取徑的需求只會更強烈。

典型用途：流動對齊團隊與複雜子系統團隊從平台團隊消費「平台即服務」；流動對齊團隊與複雜子系統團隊從複雜子系統團隊消費某個元件或程式庫作為服務。

促進：感知並縮小能力落差#

促進：協助（或被協助）另一個團隊排除障礙

促進模式適用於「一個或多個團隊能從另一個團隊主動協助（或教練）其工作的某個面向中獲益」的情境。促進互動模式是賦能團隊的主要運作模式（見第 5 章），它向許多其他團隊提供支援與能力，協助提升這些團隊的生產力與成效。

執行促進之團隊的職權範圍是：

• 讓其他團隊更有效能、學得更快、更理解某項新技術
• 發現並移除跨團隊的共同問題或障礙
• 也可以協助發現其他團隊所使用之既有元件與服務中的落差或不一致

以促進模式互動的團隊，通常橫跨許多其他團隊工作，偵測並減少跨團隊問題，並協助形塑「由其他團隊或組織以服務形式提供之程式庫、API 與平台」的方向與能力。

具促進職權的團隊不參與建造主要的軟體系統、支援元件或平台，而是專注於「建造與運行軟體的其他團隊之間的互動品質」。

例如，一個促進三個流動對齊團隊之效能的團隊，可能會發現平台所提供的日誌服務相當難以設定——三個團隊都覺得難用。於是這個團隊便能促成平台在日誌服務上的一些改善。

由於促進互動中的兩個團隊只有一方在建造主要軟體系統，康威定律的效應已被預先設想：做促進的那個團隊，是依所欲的系統架構去定義並釐清其他團隊之間的溝通。

典型用途：賦能團隊協助流動對齊／複雜子系統／平台團隊；或流動對齊／複雜子系統／平台團隊協助流動對齊團隊。

各互動模式對應的團隊行為#

每種團隊互動模式都搭配一組最適合它的團隊行為。這些行為可以想成行為的「風格」，就像一個管樂團會依脈絡採用不同的演出風格：爵士、搖擺、管弦電影配樂等等。樂團（團隊）成員是同一批人，但他們作為一個群體所採用的風格，會隨所需效果而變。 當樂團需要與另一組人（四重奏或合唱團）同台演出時亦然：樂團的演出風格會改變，好讓兩個結合的群體共同成功。

同理，遵循團隊拓撲取徑的團隊，也應當依「正在與哪個或哪些團隊互動」而採用不同的行為「風格」。

技術領袖厄克哈特（James Urquhart）帶著康威定律的視角討論團隊相互溝通時，描述了對「一條能避開人對人溝通中大量政治、頻寬限制與純粹低效之溝通後備通道」的需要。這正是本章「定義良好的團隊互動」該提供的成果。

此外，行為研究顯示：當我們能預測他人的行為時，我們與他人合作得最好。 身為人類，我們藉由為組織中的其他人提供一致的體驗來建立信任。清晰的角色與職責邊界透過定義預期行為來幫助這件事，並避開某些人所稱的「隱形電籬笆」。

承諾理論（promise theory）由技術專家兼研究者伯吉斯（Mark Burgess）提出，說明了為何以「承諾」而非「命令與可強制執行的契約」來構築跨團隊關係更為可取。舉例來說，只要遵守語意化版本（SemVer）所標示之 major/minor/patch/build 編號的意義，團隊就等於承諾不會弄壞依賴其程式碼的軟體。

協作模式：「高度互動與相互尊重」#

以協作模式互動的團隊，應當預期與協作對象有高度互動與相互尊重。這通常意味著成員應當預期：各項活動會比原本預想的花上更久，因為協作中「跨越邊界」的部分會發現並解決先前未知的問題。

讓一個團隊因另一個團隊的工作而獲得獎勵，有助於對齊行為——這是萊納特森所稱的「重疊衡量原則」（Principle of Overlapping Measurement）。

如何為協作模式做訓練：在結對編程、群體編程、白板速寫等基本協作技能上的一些訓練或教練，加上針對「跨邊界協作」的特定訓練，對以協作模式互動的團隊很有價值。

X 即服務模式：「強調使用者體驗」#

以 X 即服務模式互動的團隊，應當預期強調「所提供之物的使用者體驗」。

舉例來說，若平台團隊為流動對齊團隊提供一組動態雲端測試環境，雙方都應當強調與這些環境互動的體驗：API 用起來感覺如何？看見所使用的資源有多容易？各項功能用起來有多吸引人？平台的功能性當然也重要，但要驅動團隊之間最佳、最有成果的互動，對「使用平台的體驗」的關注不可或缺。

促進模式：「幫助他人，也被他人幫助」#

以促進模式互動的團隊，應當預期既幫助人也被人幫助。

假設一個流動對齊團隊正被賦能團隊協助採用新實踐，那麼流動對齊團隊的人就必須願意被幫助：他們需要對新取徑抱持開放心態，並意識到賦能團隊很可能見過一些更好的做法。

選擇合適的團隊互動模式#

四種基本團隊拓撲各有其特徵行為，使它們在組織脈絡中運作良好。有時，某個團隊可能需要（暫時或永久地）對其他團隊採用不同的互動模式，以改善成果。

這張表也提示了每種團隊可能需要的人際技能：

• 平台團隊需要強大的產品與服務管理專業
• 賦能團隊需要具備強大指導與促進經驗的人

選擇基本的團隊組織方式#

理解了團隊互動模式之後，我們就能選擇一套「有望產出所需軟體架構」的初始組織設計。

應當與同事們建立這樣的期待：互動模式與團隊結構至少會需要一些改變，隨著組織逐步「感知」出所選邊界是否真的是最好的邊界。

案例研究：2014 年前後 IBM 的團隊互動多樣性

——米尼克（Eric Minick），IBM 持續交付專案總監

自 2013 年起，米尼克主導了新實踐在 IBM 全球技術團隊中的導入與擴散。

我 2013 年加入 IBM 時，企業軟體產業正經歷雲端技術與無所不在之自動化所帶來的重大變化。我當時的部分職責，是把彼時仍屬新穎的 DevOps 與敏捷實踐帶給分布在六大洲數十個據點的四萬名開發者。

當時有許多不同種類的團隊互動同時發生。為了促成向新工作方式的轉變，我們設置了一支「布道者」（advocates）團隊。

布道者團隊包含少數全職人員與一些兼職者。它從世界各地的團隊蒐集成功樣式，用以鼓勵與教育其他人，幫助這些想法在 IBM 組織內擴散。做法包括為團隊及其主管提供正式訓練；與此同時，還有像內部網路研討會這樣持續不斷的內容輸出，能吸引數千名技術人員參與。

布道者團隊大概無法乾淨地歸入某一種團隊拓撲，因為我們把自己看作一支暫時的團隊，幾年後就不該再被需要。或者用我當時在 Twitter 上說的話：「DevOps 團隊」的目標，應該是透過賦能組織其餘部分，讓自己歇業。

以協作與促進互動搭配反向康威操作#

當我們執行反向康威操作（見第 2 章）時，康威定律所指認的「自相似同態拉力」已被預先設想：組織被安排成匹配軟體與系統架構所需的溝通路徑。

然而，不能期待新架構在新團隊結構被設計並實施之後就立刻浮現。正因為康威定律背後的那些力量，既有的軟體架構起初會「反推」新的團隊結構。

要讓新的組織結構運作起來——並感知新的職責邊界是否真的正確——反向康威操作應當搭配：

• 建造軟體之團隊之間暫時但明確的協作模式
• 一個或多個賦能團隊（可能還有其他團隊）以促進模式運作

藉由在新邊界上使用暫時、明確的協作，並對流動對齊團隊與複雜子系統團隊高度使用促進，新職責邊界上的任何問題都能被快速辨識，讓團隊有機會在建造出太多東西之前，及早調整設計。

協作期間的職責可能需要「反過來」安排：例如，假設一個大型軟體單體需要被拆成不同區段（對齊到流、元件，或平台的新面向）。那些「邏輯上」擁有較高層元件的團隊，可能需要有一段時間去做**較低層（平台）**的工作，才能把那些程式碼拆出來——尤其當一開始寫出過度耦合程式碼的正是他們自己時。隨著協作期推進，邏輯上擁有較低層的團隊可以逐步從原團隊手中承接更多職責，直到完全接手。

透過刻意演化團隊拓撲，發現團隊之間有效的 API#

如第 5 章所述，專責的架構團隊通常是應當避免的反樣式。然而，當「架構」的職權範圍是去發現、調整並重塑團隊之間的互動（因而也是系統的架構）時，一小群軟體與系統架構師能在組織中發揮巨大效能。

這是因為在康威定律於系統建造組織中發揮作用時，組織的架構就是系統的架構。或如馬蘭所說：「組織上的分界，終將驅動出系統中真實的接縫。」

架構師應當思考的是：「對這兩個團隊而言，哪種互動模式是合適的？系統的這兩個部分之間、這兩個團隊之間，我們需要什麼樣的溝通？」

在遵循團隊拓撲取徑的組織中，架構師因而是團隊 API 的設計者——那些預先設想了所欲軟體架構的 API。

實際上，與其完全倚賴團隊內的個人去執行跨邊界溝通（那既有壓力，又同時需要良好的社會與技術技能），不如運用擅長 API 設計的人，去設計組織內團隊與團隊之間的 API。

選擇互動模式以降低不確定性、增強流動#

用協作模式去發現可行的 X 即服務互動#

X 即服務互動模式在幫助軟體交付團隊達成快速流動上可以極為有效。然而，就像任何服務一樣，若服務邊界劃得不好、服務提供得太多或太少又缺乏彈性，X 即服務互動就不會有效——那個服務將無法滿足消費團隊的需要。

要處理「服務邊界劃得不好」的問題，可以動用協作模式去把服務邊界重劃到新的位置，收縮或擴張服務的職權範圍（或增加彈性），使服務更適合消費團隊。

事實上，我們應當預期在服務邊界上持續進行輕量的協作互動，以確保所有服務都盡可能有效。我們要的是在服務邊界上「剛剛好夠用」的協作，用以調整服務範疇來滿足消費方與提供方團隊的需要。

若組織正試圖建立一個新的 X 即服務互動，同樣的樣式適用：先緊密協作以建立可行的「即服務」邊界，然後持續以輕量協作來驗證邊界是否有效。

協作模式也可以用來驅動應用與平台／基礎設施雙方的創新速率，這對新興的產品或服務尤其有用。

暫時改變互動模式，幫助團隊增長經驗與同理#

若團隊之間當前的互動模式已維持一段時間、可能需要一些活化，暫時改變互動模式能幫助成員刷新並增長經驗，也增加對另一團隊的同理。

Pivotal 的威利（Evan Wiley）描述，對於依賴另一團隊的團隊，「這些團隊可能會安排交換結對搭檔，某個人會從一個團隊到另一個團隊待上幾天或一週，把那個功能做完」。海爾芬德（Heidi Helfand）則說：「當你刻意規劃組織中的[團隊變動]時，你就為人們提供了新的學習機會。」

至關重要的是，這些改變必須是刻意的（也很可能是暫時的），且取得涉入者的完全同意、理解與熱忱。

用互動中的彆扭感，感知缺失的能力與錯置的邊界#

團隊互動的樣態可以用來偵測並回應系統設計上的問題，甚至在程式碼進入正式環境之前就預見軟體問題。

例子一：一個本該從複雜子系統團隊「以服務形式」消費某計算元件的流動對齊團隊，卻花大量時間在即時通訊與面對面找該團隊，只為了設法用那個元件。

我們知道 X 即服務互動應當是低摩擦、只需要偶爾或有限溝通的。若流動對齊團隊得花好幾小時才用得起一個元件，那就是有什麼不對勁的訊號：

• 元件邊界劃在對的地方嗎？
• 元件 API 規格定得夠清楚嗎？
• 元件夠好用嗎？
• 複雜子系統團隊是否缺了某項團隊內能力，例如 UX 或 DevEx？

例子二：一個平台團隊本預期與某流動對齊團隊緊密協作以評估新的技術取徑，卻幾乎得不到對方的互動。

此時，跨團隊溝通的「缺席」本身就是訊號，顯示流動對齊團隊那邊出了問題：

• 他們理解此刻採用協作模式的價值嗎？
• 他們有足夠技能承擔這項協作嗎？還是另一個團隊更合適？
• 兩隊試圖跨越的那道邊界，是不是太過野心勃勃了？

誠如萊納特森所說：「我們必須對角色之間的空白地帶保持警覺——那些沒有人覺得自己該負責的縫隙。」

領域驅動設計（DDD）的技術，例如事件風暴（event storming）與上下文映射（context mapping），能加速我們對合適邊界的覺察（DDD 詳見第 6 章）。

本章總結：三種定義良好的團隊互動模式#

一個有效的現代軟體組織，是團隊之間互動的產物。然而許多組織從未定義「好的團隊互動長什麼樣」，結果就是困惑、惱怒與無效。

光是定義一組帶有職責邊界的團隊，不足以產出有效的社會技術系統；還必須定義團隊之間合理而有效的互動。

三種核心互動模式，為組織內所有團隊互動提供了所需的清晰度：

• 協作——兩個團隊在一段界定的期間內緊密合作，以發現新的樣式、取徑與限制。職責共享、邊界模糊，但問題能被快速解決，組織學得很快。
• X 即服務——一個團隊消費另一個團隊「以服務形式」提供的東西（如服務或 API）。職責界線分明；若邊界有效，消費團隊就能快速交付。提供服務的團隊致力於讓自己的服務盡可能容易消費。
• 促進——一個團隊在一段界定的期間內，協助另一個團隊學習或採用新取徑。提供促進的團隊以「盡快讓對方自給自足」為目標，而接受促進的團隊則對學習抱持開放心態。