外科手術團隊

核心困境#

Brooks 在本章面對一個根本性的矛盾：

小團隊最好——但大系統需要很多人。

前一章證明了增加人力會帶來溝通成本的平方成長，因此小團隊在效率上具有壓倒性優勢。然而，一個真正的大型系統——如作業系統——的工作量遠超一個小團隊在合理時間內能完成的範圍。如何調和這個矛盾？

Brooks 引用了 Sackman、Erikson 和 Grant 的研究，該研究揭示了一個驚人的事實：即使是有經驗的程式設計師之間，生產力差異也高達 10:1。最佳程式設計師不僅寫得快，他們寫出的程式在執行速度和空間效率上也遠優於其他人。

這意味著一個由少數頂尖程式設計師組成的小團隊，其產出可能超過一個由普通程式設計師組成的大團隊。但問題在於：即使是最頂尖的小團隊，面對一個需要數百人年的系統，也無法在合理時間內完成。

10:1 的生產力差異不是新手與老手的對比，而是同樣有經驗的程式設計師之間的差距。這暗示著人才密度比團隊規模更重要。

解決方案來自 Harlan Mills 的提案：將團隊組織成外科手術團隊（Surgical Team），而非屠宰團隊（Hog-butchering Team）。

在傳統團隊中，工作被平均分配給所有成員，每個人負責設計和實作自己的部分。而在外科手術團隊中，外科醫生一人負責所有關鍵的設計與編碼，其餘成員則扮演支援角色，使外科醫生能夠以最高效率工作。

關鍵差異在於：傳統團隊將工作分割給平等的成員；外科手術團隊將角色分割，讓最優秀的人做最關鍵的創造性工作，其他人提供全方位支援。

Brooks 詳細描述了團隊中的每個角色：

外科醫生（The Surgeon）——即首席程式設計師。負責定義功能規格、設計程式、編寫程式碼、測試和撰寫文件。他需要極高的才能和十年以上的經驗。整個系統的概念完整性由他一人掌控。
副駕駛（The Copilot）——外科醫生的另一個自我（alter ego）。他了解所有程式碼，能夠執行任何部分的工作，但主要作為思考夥伴和保險機制。他可能會為外科醫生探索替代方案或進行設計研究。

程式檔案員（The Program Clerk）——負責維護團隊的所有技術紀錄。在當時的環境下，這意味著管理所有機器可讀和人類可讀的文件，確保版本的一致性。
工具匠（The Toolsmith）——為外科醫生打造專用工具。大型專案中，每個團隊都需要自己的專用工具——互動式除錯工具、特殊的測試輔助程式等。工具匠的存在使外科醫生不必分心於工具建設。
測試員（The Tester）——從功能規格出發，設計測試案例和測試鷹架（test scaffolding）。他既為日常的元件測試準備測試資料，也為系統測試規劃測試計畫。
語言律師（The Language Lawyer）——精通程式語言細節和奧祕的專家。這個角色可以跨團隊共享，因為一個專案中通常只需要一兩位這樣的專家。

外科手術團隊的精髓不在於特定的角色劃分，而在於核心原則：讓最優秀的人做設計，讓其他所有人支援他。具體的角色可以依據時代和技術環境進行調整。

外科手術團隊看起來像一個 10 人小團隊，但運作方式截然不同：

一個 200 人的專案可以組織為約 20 個外科手術團隊，每個團隊負責系統的一個子部分。跨團隊的概念完整性則由一個架構團隊（architecture team）來維護——這正是後續章節的主題。

這種組織方式的優點在於：每個子系統內部由單一外科醫生維持一致性，而整體系統的一致性由架構團隊確保。溝通不再是 200 人的 n(n-1)/2，而是 20 位外科醫生之間的協調——大幅降低了溝通成本。

外科手術團隊的組織方式同時解決了兩個問題：透過小團隊結構保持效率，透過多團隊並行解決大規模系統的人力需求。