「雙披薩團隊」需要一個維基

亞馬遜（Amazon）的「兩張披薩團隊」模型是現代組織設計中最具影響力的概念之一。保持團隊規模足夠小，以至於兩張披薩就能讓他們吃飽（大約 5 到 8 個人）。讓每個團隊對特定的領域擁有明確的所有權。讓他們自主運作，在無需等待中央權力機構批准的情況下做出決策。

這個模型行之有效。研究一致表明，擁有明確所有權邊界的自主小團隊，其人均生產力高於大團隊。他們溝通更高效，決策更迅速，交付也更頻繁。拖慢大團隊速度的溝通路徑爆炸，在每個小團隊可控的路徑數量內得到了控制。

但該模型有一個在組織設計文獻中鮮少被討論的依賴關係：只有當團隊之間的知識層足夠強大，能夠處理小團隊結構所帶來的跨團隊協調時，它才能發揮作用。

團隊之間的問題

當你將一個 30 人的團隊拆分為五個 6 人團隊時，你顯著降低了團隊內部的協調成本（從 435 條路徑減少到五組 15 條路徑）。但你創造了一個全新的協調界面：團隊之間的邊界。

A 團隊擁有支付服務。B 團隊擁有用戶服務。C 團隊擁有 API 網關。每個團隊在自己的領域內都是自主的。但這些領域會相互作用：API 網關將請求路由到用戶服務和支付服務，而支付服務需要來自用戶服務的用戶數據。這些互動需要跨團隊的協調，而這種協調的質量取決於每個團隊的知識對其他團隊的開放程度。

如果 A 團隊關於支付服務的知識只存在於 A 團隊成員的腦海中，那麼 B 團隊每次需要了解支付如何運作時，都必須打擾 A 團隊。協調成本並沒有因為小團隊結構而消除。它只是從團隊內部轉移到了團隊之間，而團隊之間的協調往往成本更高，因為參與其中的人並不共享日常的上下文背景。

文檔依賴性

當每個團隊的領域知識都被足夠好地記錄下來，使其他團隊無需召開會議或在 Slack 上發起討論就能獲取時，小團隊模式才能發揮作用。

這意味著每個團隊都需要：

系統文檔，描述他們的服務做什麼、如何運作以及如何與之交互。不僅僅是 API 文檔，還有架構背景：為什麼要這樣構建、它在什麼限制下運行，以及如果你對其行為做出某些假設會導致什麼破壞。

決策記錄，解釋重大技術選擇背後的推理。當 B 團隊在 A 團隊的服務中遇到意外情況時，他們應該能夠通過閱讀決策記錄來理解為什麼會這樣，而不是與 A 團隊約定會議。

變更文檔，記錄更改了什麼以及原因。當 A 團隊修改其服務並影響到 B 團隊時，該變更及其影響應該在文檔中清晰可見，而不是通過 B 團隊可能會漏掉的 Slack 消息來傳達。

可搜索的知識，可在團隊邊界之間獲取。B 團隊應該能夠像搜索自己的文檔一樣輕鬆地搜索 A 團隊的文檔，並且搜索應該基於含義進行，這樣他們就無需知道 A 團隊的命名規範即可找到所需的內容。

以自動寫入作為推動因素

大多數小團隊實施方案在跨團隊文檔上投入不足的原因，在於編寫文檔的負擔落在了各個團隊身上，而他們本身就已經忙於自己的工作。要求一個六人團隊在交付自己功能的同時，還要為其他團隊的利益維護詳盡的文檔，這無異於讓文檔編寫工作永遠被降低優先級。

自動編寫文檔改變了這個方程式。每個團隊的文檔都是從他們現有的活動中生成的：PR（拉取請求）、Slack 對話、會議。文檔保持最新，因為它是從工作本身衍生而來的，而不是作為一項單獨的任務來維護。其他團隊可以搜索它，因為它是貫穿整個組織的統一知識層的一部分。

兩張披薩團隊模型是一種組織策略。而自動編寫文檔則是讓其發揮作用的知識基礎設施。沒有它，小團隊只是更小的孤島，協調成本只是轉移了，而沒有縮減。

常見問題

那團隊 API 和合約呢？ API 文檔和服務合約固然必不可少，但還不夠。它們描述了接口，但沒有描述背後的原理。一個只知道另一個團隊 API 做什麼，卻不知道為什麼要這樣設計的團隊，將會基於不完整的理解做出集成決策。決策記錄和架構文檔填補了這一空白。

我們如何處理團隊之間的依賴關係？ 在共享層中明確記錄這些依賴關係。當 A 團隊知道 B 團隊依賴其服務的特定行為時，該依賴關係應該在文檔中清晰可見，以便在交付影響該行為的更改之前進行標記。

這適用於非工程團隊嗎？ 同樣的動態適用於任何使用小型自主團隊的組織。營銷小組、銷售團隊、產品團隊：全都需要一個共享的知識層來在團隊邊界之間進行協調，而無需頻繁開會。

延伸閱讀： 知識擴展問題、布魯克斯法則依然正確、如何擴展工程團隊。相關頁面： 自動編寫文檔、一鍵搜索、適用於工程團隊。