那個設計……幾乎從來不是最好的可能設計，[因此]當前主導的系統概念可能需要改變。所以，組織的彈性對有效的設計至關重要。

——梅爾・康威（Mel Conway），〈How Do Committees Invent?〉

要設計的是「設計規則」#

現代組織面臨巨大挑戰：法規與市場條件、顧客與使用者需求、快速移動的趨勢，以及技術能力的劇烈轉變。成功的現代組織必須能夠變形以應對這些變動的處境——也就是為調適力而設計。

因此，在為「建造與營運軟體系統」設計現代組織時，最重要的不是組織本身的形狀，而是那套「當新挑戰浮現時，用來調適與改變組織」的決策規則與啟發法。

換句話說：我們要設計的是設計規則，而不只是組織。

每種互動該有多少協作？#

如第 7 章所述，團隊的兩種主要互動模式是協作（兩個技能不同的團隊一起工作）與 X 即服務（一方提供、一方消費，幾乎不需要協作）。

重要的是認識到：兩種模式沒有孰優孰劣，它們只是適用於不同種類的工作。

• 協作有利於快速探索、避開交接與延遲，缺點是認知負荷更高——協作的每一方都得更理解另一方，成員腦中要裝的東西更多。但如果組織想要極快速地創新，這筆「協作稅」是值得的。
• X 即服務則讓「誰擁有什麼」非常清晰，每個團隊需要的心智脈絡更少，因此關係雙方的認知負荷都更低。整體而言，X 即服務下的創新很可能比協作慢——正是因為雙方互動由一套乾淨的 API 所中介與定義，而它鎖住了互動的可能性。X 即服務最適合「可預期的交付比快速探索更重要」的情境。

《Accelerate》的研究支持這個取徑：

在架構能力得分高的團隊中[這直接帶來更高的效能]，交付團隊之間只需要很少的溝通就能完成工作，而系統架構的設計讓團隊能在不依賴其他團隊的情況下測試、部署與變更自己的系統。換句話說，架構與團隊都是鬆散耦合的。

協作是昂貴的，而不必要的協作尤其昂貴——特別是它可能遮蔽或隱藏底層平台或能力上的缺陷。因此，任何持續性的協作活動都必須被證成為：有價值的探索、有價值的能力建立，或有價值的缺陷填補活動。

要達到高效能組織的水準，關鍵在於決定每一組團隊對團隊的互動該有多少協作：

• 團隊 A 是否應該能不費力地從團隊 B 消費服務？
• 如果應該卻還做不到，團隊 A 是否該與團隊 B 短期協作（三週？三個月？），以更好地定義團隊 B 的 API，使團隊 A 得以「即服務」地消費它？
• 考慮到協作很可能會模糊兩隊之間系統各部分的邊界，兩隊究竟該就什麼協作？

加速新實踐的學習與採用#

刻意把兩個團隊的互動模式改成協作，可以成為「快速學習與採用新實踐、新取徑」的強大組織賦能手段。

若某個團隊在一組有價值的實踐（例如測試自動化）上有豐富經驗，而另一團隊能從中受益，那麼讓兩隊以協作模式共處幾個月，不僅有助於改善與定義兩隊之間的 API，還能為第二個團隊的能力帶來階躍式的提升。

這種「刻意協作」在「兩個群體因各自技術周邊的主流實踐差異而擁有極為不同的既往經驗」時特別有用。

示例：雲端團隊 × 嵌入式團隊

設想一個擅長建造雲端軟體的團隊，正在建造一套「接收來自一批運行嵌入式軟體之 IoT 裝置的資料」的雲端代管指標蒐集與分析軟體。讓這個團隊與一群嵌入式軟體專家（其經驗低階得多）緊密協作，不僅能幫助雙方更理解跨越「嵌入式／雲端」技術鴻溝的挑戰，還能在測試自動化上帶來好處：

• 雲端團隊很可能把測試環境視為短暫且動態的，能幫助嵌入式團隊採取更靈巧的測試取徑
• 作為回報，嵌入式團隊能幫助雲端團隊理解嵌入式 IoT 裝置的記憶體與處理限制，並調整程式碼與協定以更適配受限硬體

這段協作期也能幫助組織評估：雲端軟體或嵌入式裝置，能否／該否被當作平台來對待（並由平台提供方採取對應行為）。當然另一個選項是兩隊繼續協作，也許由一支賦能團隊居中調解。隨著協作持續，兩隊可能會發現彼此的變更節奏日益對齊——此時他們或許會決定組成一組「配對的」流動對齊團隊。

案例研究：TransUnion 的團隊拓撲演化（下）

——霍奇基斯（Dave Hotchkiss），TransUnion 平台建置經理（承接第 4 章）

起點（2014 年）：我們意識到開發（Dev）與維運（Ops）群組之間隔著一道巨大鴻溝。我們知道一支獨立的布道者團隊能幫助兩者靠近；但由於我們的鴻溝實在太寬，我們決定用兩支團隊。

• 從 Dev 群組中成立系統建置團隊（SB）
• 從 Ops 群組中成立平台建置團隊（PB）

然後我們專注於讓 SB 與 PB 緊密協作——這在初期比「讓所有 Dev 與 Ops 團隊都協作」是個簡單得多的問題。

第一階段：受 DevOps 團隊拓撲樣式啟發，我們畫出了一條團隊演化的時間軸。我們預期初期需要先聚焦於 Dev 團隊內部的意識與可運作性，因此最初的演化是讓 SB 團隊與各 Dev 團隊以及 PB 團隊緊密協作。這確實改善了部署自動化、度量、日誌等維運面向。

比預期更久的過渡：2014 年時，我們預期會在十二個月內把 SB 與 PB 演化成一支漂亮的賦能團隊。實際上，隨著我們開始把服務搬到 Azure，這個過渡比原先設想的多花了三年；但到 2018 年初，我們做到了。對業務的好處非常明確：更安全、更規律的正式環境變更，更少的部署失誤，以及更好的變更可追溯性（這在 TransUnion 所處的高度受監管金融業至關重要）。

最終形態（2018 年底）：我們走得更遠——終於把 SB 團隊併回各 Dev 團隊、把 PB 併回 Ops 團隊，帶來更高層次的維運意識與當責，並讓 Ops 專責管理底層平台，其中部分策略性基礎設施運行於 Azure 雲端。

我們很早就意識到「這應當是一場團隊的演化」，這對我們的成功非常重要。人們知道事情需要時間，而清晰卻會變動的職責邊界，幫助人們理解自己在這個過程中的位置。

團隊拓撲的持續演化#

協作昂貴但有利於發現新取徑，X 即服務則有利於可預期的交付；因此團隊可以被設置成匹配軟體系統各領域與各團隊的需要。但當需求或營運脈絡改變時，會發生什麼事？

• 若某團隊需要探索技術堆疊的某一部分、或當前由另一團隊處理的邏輯領域模型，他們就該協議在特定期間內使用協作模式。
• 若某團隊在與另一團隊成功探索出新取徑後，需要提升交付的可預期性，就該從協作模式移向 X 即服務，以協助定義兩隊之間的 API。

康威定律告訴我們：在協作模式下的探索與快速學習期間，軟體的職責與架構很可能比 X 即服務時更加「混融在一起」。預先設想這種模糊性，便能在團隊轉向 X 即服務時收緊 API，從而避開一些彆扭的團隊互動（「這 API 設計得不好」之類）。

最初的緊密協作，隨著技術與產品透過探索被更好地理解，會演化成「就較少事項進行的有限協作」；當產品或服務邊界更為確立後，再進一步演化為 X 即服務。

在較大型的企業中，這種「從探索到確立」的樣式應當時時刻刻都在發生，不同團隊各處於不同的發展階段。應當有多項探索活動同時進行，同時其他團隊則善用定義良好的 API，把東西當作服務消費。

在某些組織中，若創新速率極高，許多團隊可能長期以協作模式運作；另一些組織則可能傾向以 X 即服務互動為主，因為他們的問題空間定義良好，主要只需執行已被充分理解的業務問題。關鍵在於：團隊需要什麼樣的互動模式，取決於他們需要達成什麼。

最終，藉由期待並鼓勵團隊互動基於特定理由在協作與 X 即服務之間移動，組織就能取得敏捷性。

讓組織內團隊之間的相互關係保持定義良好且動態，為蘇斯納（Jeff Sussna）所稱的、面向外部與內部脈絡的「持續設計能力」提供了基礎。這種動態重塑提供了一項關鍵策略能力。組織變革專家科特（John Kotter）說：「我把[策略]想成一個持續進行的『搜尋、行動、學習、修正』的過程……組織越常演練其策略技能，就越擅長應對超競爭的環境。」

在探索階段，某種程度的協作是預期中的；但緊密協作往往無法在整個組織中規模化。目標應當是設法建立一個定義良好、有能力的平台，讓許多團隊能單純地把它當作服務使用。

隨著新的商品化服務與平台變得可得，組織應當設法從探索活動轉向確立可預期的交付。這對組織的意涵是：組織內不同團隊的人所經驗到的東西會不一樣，取決於他們當下在做哪一類工作。並非所有團隊都會以相同方式與其他團隊互動——而那正是我們要的。

組織必須自問：「我們是在試圖探索東西嗎？我們需要多快發現它們？」

• 有時需要把人共置一處——同一排桌子，或至少同一棟樓的同一層——以產生那種鼓勵「適量協作」的鄰近感
• 另一些時候，團隊可能移到不同樓層甚至不同建築，以協助強制執行一道 API 邊界；在溝通上拉開一點距離有助於此

組織內的團隊拓撲是以數個月為單位緩慢改變的，不是每天或每週。在幾個月的跨度上，應當鼓勵團隊互動模式的改變，並預期軟體架構出現對應的改變。

組合團隊拓撲以取得更高成效#

在任一時刻，組織內不同團隊會有不同的互動與協作需要。應當預期同時看見不同種類的團隊拓撲。 團隊之間某種程度的協作是預期中的，但協作往往無法在組織層級規模化；而隨著團隊數量增加，把東西當作服務消費通常更有效。

演化團隊拓撲的觸發訊號#

依第 5 章的建議，把組織在某個時間點的結構映射到四種基本團隊拓撲相當直截了當；但要有足夠的組織自覺去察覺「該演化團隊結構了」，往往很困難。

以下幾種情況可作為「重新設計團隊拓撲」的觸發訊號。學會辨識它們，能幫助組織持續隨自身需要調適與演化。

觸發一：軟體對一個團隊而言已經長得太大#

症狀

• 新創公司成長超過十五人（鄧巴數）
• 其他團隊花大量時間等待某一個團隊來做變更
• 系統中某些元件或工作流的變更，總是被指派給同一批人——即使他們已經很忙或不在
• 團隊成員抱怨系統文件不足

脈絡

成功的軟體產品傾向越長越大，因為加入了更多功能、更多顧客採用了產品。起初產品團隊裡的每個人可能對程式碼庫都有相當廣泛的理解，但隨時間推移，這變得越來越困難。

這會導致團隊內部針對系統不同元件出現（通常不明說的）專業分化：需要變更某特定元件或工作流的請求，總是被指派給同一批成員，因為他們交付得比其他人快。

這個自我強化的專業化循環是一種局部最佳化（「趕快把這個請求交付出去」），當規劃開始由「誰懂什麼」而非「現在最高優先的工作是什麼」所主導時，就會負面影響團隊的整體工作流動。這種專業化程度會在交付上引入瓶頸，而其例行化的性質也會損害個人動機。

另一個作用中的面向是：當團隊不再對系統握有整體視野時，它也失去了「察覺系統已變得太大」的自覺。雖然系統大小與程式碼行數或功能數有某種相關性，但這裡最令人擔憂的，是有效處理系統變更之認知容量的極限。

觸發二：交付節奏正在變慢#

症狀

• 成員在質性上感覺發布變更比以前花更久
• 團隊速度或吞吐量指標，相較一年前呈現明顯的下行變化（總會有些波動，請確認不是偶然）
• 成員抱怨交付流程以前更簡單、步驟更少
• 進行中工作（WIP）不斷增加，許多變更卡在等待另一個團隊行動

脈絡

一支長壽的高效能產品團隊，應當能隨著找到更有效率的合作方式與消除交付瓶頸，而穩定改善交付節奏。然而這些團隊要能茁壯，前提是被授予產品整個生命週期的自主權——意即不存在對外部團隊的硬依賴（例如等另一個團隊來建新的基礎設施）。透過內部平台自助佈建新基礎設施則屬於軟依賴（假設該自助佈建由平台團隊維護）。

這種程度的自主在許多組織中難以達成。事實上，常見的是相反的情況：藉由在團隊之間引入新的硬依賴來削減自主性。

例如，為了提高測試覆蓋率而成立一個 QA 團隊來集中測試所有產品，理論上能更有效率地分派工作給測試者。目標值得讚許，但這種團隊設計引入了一個職能穀倉（QA），所有交付軟體的團隊都得等 QA 團隊有空來測他們的更新。

DevOps 的出現凸顯了 2010 年代開發與維運團隊之間的分裂；但對所有介入產品交付生命週期的穀倉來說，這是同一個問題，只是程度不同。

另請注意：交付變慢也可能是因為累積的技術債。在這種情境下，程式碼庫的複雜度可能已達到「即使小變更也代價高昂且經常引發回歸」的狀態，使得交付從開發到穩定所花的時間，遠比程式碼庫剛建立時更久。

觸發三：多個業務服務仰賴一大批底層服務#

症狀

• 流動對齊團隊對自身服務領域內的端到端流動能見度有限
• 由於子系統整合的數量與複雜度，難以達成順暢快速的變更流動
• 「重用」既有的一整組服務與子系統，變得越來越有挑戰性

脈絡

在金融、保險、法律、政府等高度受監管的產業，數個不同的高階業務服務可能仰賴一大批彼此分立的底層服務、API 或子系統。例如：

• 保險公司可能需要對工廠機械進行冗長的實體檢查，才能提供更新的保費報價
• 銀行可能需要等待地址證明文件送達，才能開立新帳戶

這些高階業務服務所仰賴的低階系統，可能提供專門的支付機制、資料清理、身分驗證、法律背景查核等，每一項都需要多個團隊投入以演化與維繫。業務流程管理（BPM）——或許再輔以機器學習（ML）——能自動化其中部分工作；但仍需要投入且具備意識的團隊去設定與測試 BPM 工作流情境。其中有些服務與子系統可能自建，有些則由外部供應商提供。

若各個流必須各自分別與每個底層服務整合，就很難評估流動的成效，也很難診斷那些可能包含人為決策輸入的長時程流程中的錯誤。例如，底層服務可能不暴露追蹤機制，或各自有一套識別交易的方式。

解法有兩個面向：

1. 把低階服務與 API「平台化」——加上一層薄薄的「平台包裝」（platform wrapper），為流動對齊團隊提供一致的開發者體驗（DevEx），包含請求追蹤關聯 ID、健康檢查端點、測試框架、服務水準目標與診斷 API。這個「外層平台」建立在更低層的平台之上，但那對流動對齊團隊維持隱藏。
2. 為每個高階業務服務配置流動對齊團隊，負責維運遙測與故障診斷——建造並演化「剛剛好夠用」的遙測整合與診斷能力，使其能偵測問題發生在哪裡。掌控遙測與診斷，讓流動對齊團隊得以追蹤並改善自身流中的變更流動。

作為每個高階業務服務豐富遙測的一部分，流動對齊團隊建造並擁有：

1. 一層輕量的數位服務「包裝」，在呼叫平台中不同的底層服務與 API 時，提供一致的日誌時間戳、一致的關聯 ID、請求／回應識別與記錄等
2. 該數位服務包裝的日誌、指標與儀表板，使所有「流這一側」的協調都能被追蹤與追溯（即使初期「平台那一側」的能見度參差不齊）

要支撐高階業務服務中持續而可預期的流動，平台包裝必須改善平台服務周邊的 DevEx——在日誌、指標、儀表板、關聯 ID 等方面的一致性與標準——好讓流動對齊團隊所建的數位服務包裝能取得更高的可追溯性。

讓設計與開發自我導航#

歷史上，許多組織把「開發」與「營運」當作軟體交付的兩個分立階段，兩者之間互動極少，而且幾乎沒有從營運回饋到開發的迴路。

現代軟體交付必須採取截然不同的取徑：軟體的營運本身，就應當作為並提供有價值的訊號給開發活動。

把維運當作開發的豐富感官輸入來對待，就架起了一套控制論回饋系統，使組織得以自我導航。

把團隊與團隊互動當作感官與訊號#

當定義良好、穩定的團隊有效擁有軟體系統的不同部分，並以定義良好的溝通樣式互動時，組織就能啟動一項強大的策略能力：組織感知（organizational sensing）。

組織感知把團隊及其內外部溝通當作組織的「感官」（視、聽、觸、嗅、味）——杜拉克（Peter Drucker）稱之為「面向外界的合成感覺器官」。

沒有穩定、定義良好的神經溝通路徑，任何活體都無法有效感知任何事物。要感知事物（並使事物變得可理解），有機體需要明確、可靠的溝通路徑。同理，有了團隊之間定義良好且穩定的溝通路徑，組織就能偵測來自組織內外的訊號，變得像一個有機體。

許多組織——那些團隊不穩定、定義不清，倚賴關鍵個人，且（往往）壓抑大量員工聲音的組織——實際上在兩個意義上都是「senseless」的：他們既無法感知自身所處的環境處境，所作所為也毫無道理。

當變化速度以月或年計時（如同過去），組織尚能以極慢而有限的環境感知度日；然而在今日網路連結的世界中，高保真的感知對組織存活至關重要——正如動物或其他有機體需要感官才能在競爭而動態的自然環境中生存。

組織不只需要高保真地感知事物，也需要快速回應。有機體通常有分立的專門器官負責感知（眼、耳等）與回應輸入（四肢、身體等）。不同團隊能偵測到的訊號種類會有所不同，取決於團隊做什麼、離外部顧客／內部顧客／其他團隊有多近；但每個團隊都有能力為組織提供感官輸入，並藉由調整其團隊互動樣式來回應資訊。

所幸，我們有現代數位工具能協助史丹佛（Naomi Stanford）所稱的「環境掃描」：來自數位指標與日誌的豐富遙測，幫助團隊即時掌握其軟體系統的健康與效能；輕量的網路連結裝置（IoT 與第四次工業革命）則從數以千計的實體地點提供定期的感測資料。

那麼，組織該感知哪些東西？以下問題能幫助組織找到答案：

• 我們是否誤解了使用者需要／想要如何行為？
• 我們是否需要改變團隊互動模式，以增進組織的運作方式？
• 東西 X 我們還該自建嗎？還是該向外部供應商租用？
• 團隊 A 與團隊 B 之間的緊密協作仍然有效嗎？該轉向 X 即服務模型了嗎？
• 團隊 C 的工作流動已經盡可能順暢了嗎？是什麼在妨礙流動？
• 給團隊 D、E、F、G 的平台，提供了他們所需要的一切嗎？是否需要一支賦能團隊介入一段時間？
• 這兩個團隊之間的承諾仍然有效且可達成嗎？需要改變什麼才能讓承諾更符合現實？

把 IT 維運當作開發的高價值感官輸入#

快速移動仰賴關於環境的感官回饋。要維繫軟體變更的快速流動，組織必須投資於組織感知與控制論式的調控。

這種感官回饋的一個關鍵面向，是把 IT 維運團隊當作開發團隊的高保真感官輸入，這需要「運行系統的團隊（Ops）」與「建造系統的團隊（Dev）」之間串接起來的溝通。

遺憾的是，許多組織自己阻擋了自己快速而安全地前進。如納拉揚（Sriram Narayan）所說：「想降低成本的專案贊助者，會另找一組成本較低的人來做維護工作。這是假的經濟效益。它傷害更大的業務成果，並降低 IT 的敏捷性。」

與其試圖為所謂的「維護」工作最佳化到最低成本，組織必須把來自維護工作的訊號當作軟體開發活動的輸入。《DevOps Handbook》為現代高效能組織定義了 DevOps 三步工作法：

1. 系統思考：為整個組織的快速流動最佳化，而不只是局部
2. 回饋循環：讓開發被維運告知並引導
3. 持續實驗與學習的文化：每一次團隊互動都有感知與回饋

第二與第三步都仰賴 Ops 與 Dev 之間強健的溝通路徑。

如第 5 章所述，確保「高保真資訊從 Ops 持續流向 Dev」最簡單的方式之一，就是讓 Ops 與 Dev 在同一個團隊，或至少作為一組流動對齊的配對團隊對齊到同一條變更流，並在維運事故時採取蜂擁（swarming）。

對於尚未移向此模型、或仍有獨立維運群組的組織，建立並滋養 Ops 與 Dev 之間的溝通路徑至關重要。這能提供關於可運作性、可靠度、可用性、可安全化等維運面向的高保真資訊，讓 Dev 團隊得以修正航向，導向「降低維運開銷、提升可靠度」的軟體設計。

把 Ops 當作 Dev 的輸入，需要對這兩個常被分開的群組的角色做出根本的重新思考。蘇斯納說：

企業通常把維運當作設計的輸出……然而要能同理，就必須能夠聽見；要能聽見，就需要來自維運的輸入。維運因而成為設計的輸入。

這裡的目標，是去同理我們所建軟體與服務的各類使用者群體。藉由對使用者發展出更深的同理，我們就能改善與他們的互動，增進其體驗、更好地滿足其需要。

照護的連續性：避免「維護團隊」#

軟體越來越不像一個「給使用者的產品」，而更像一場「與使用者持續進行的對話」。

要讓這場持續對話有效且成功，組織需要對其軟體有一種「照護的連續性」（continuity of care）：設計並建造軟體的團隊，必須參與其運行與維運面向，才可能一開始就把它建造得好。而提供這種「設計並運行」之照護連續性的團隊，也需要對軟體服務的商業可行性負起部分責任；否則決策將在與財務現實隔絕的真空中做出。

那麼，如何鼓勵團隊在功能寫完之後，仍長期關心那個軟體？

改善照護連續性最重要的改變之一，是避免那種職權範圍只是「維護既有軟體」的「維護」或「日常維運（BAU）」團隊。 納拉揚說：「分立的維護團隊與矩陣式組織……與回應力背道而馳。」

把維護工作與初始設計工作分開，會切斷從 Ops 到 Dev 的回饋循環，而「營運該軟體」對「軟體的設計」可能帶來的任何影響也隨之流失。

為新東西與 BAU 分設團隊，還往往阻礙兩個群體之間的學習：

• 新服務團隊得以實作新技術與新取徑，卻沒有任何能力看見這些取徑是否有效。新做法可能是有害的，但新服務團隊沒什麼誘因去在意，因為只有 BAU 團隊會嘗到這些糟糕選擇的苦頭。
• BAU 團隊通常沒什麼機會把較新的遙測技術套用到既有軟體上，使他們對「那些可能顯示顧客滿意或不滿的訊號」視而不見。

更有效的做法，是讓同一個團隊並肩負責新服務與既有系統的 BAU。這幫助團隊藉由把新系統的遙測回裝到舊系統上，提升舊系統訊號的品質，並增強組織感知環境與自我導航的能力。

實際上，每個流動對齊團隊都應當預期：在他們正在建造與運行的新系統之外，還要照看一套或多套舊系統。 這幫助他們學到更廣泛的使用者與系統行為，並避免重蹈早期系統的覆轍。

要從第一線的維運系統產生並接收高保真資訊，需要高技能、高意識的人。

這意味著——與過去許多 IT 維運團隊的人力配置方式相反——IT 維運的人必須能夠快速而準確地辨識與分診問題，為那些專注於建造新功能的同事提供準確、有用的資訊。IT 維運服務台不該由最資淺的人力配置，而應由組織中一些最有經驗的工程師來擔綱，或至少與部分較資淺的成員搭配。

本章總結：演化中的團隊拓撲#

技術、市場、顧客與使用者需求、法規要求的快速變化，意味著成功的組織必須預期定期調適並演化其組織結構。

然而，建造與營運軟體系統的組織，必須確保其團隊互動是為流動、康威定律與團隊優先取徑（包含團隊認知負荷）而最佳化的。

• 如何、何時、為何需要與其他團隊協作
• 如何、何時、為何該消費或提供某物「即服務」
• 如何、何時、為何該向另一團隊提供或尋求促進

因此，隨著組織回應新的挑戰，它應當預期在任一時刻，都能看見不同種類團隊之間存在不同種類的互動。