工具-布魯克斯定律

🎯 什麼情境該想到我

當專案已經落後、你（或老闆）想「多找幾個人來趕上進度」時——先讀這條。

⚙️ 怎麼用

「為落後的軟體專案增加人手，只會讓它更落後。」
原因：

1. 新人要學習時間，還會佔用現有成員來帶。
2. 溝通成本呈平方成長：n 個人有 n(n-1)/2 條溝通路徑。
3. 可分割但需協作的任務，切得越碎、協調越貴。

該怎麼做：

• 及早重新規劃範圍/砍需求，而不是加人。
• 真要加人，越早越好（越接近死線越無效），且要能切出獨立、少溝通的工作。
• 保護 工具-概念完整性，別讓加人稀釋設計一致性。

★ 書中的算術：加人為什麼救不了進度

《人月神話》第 2 章的例子：

原計畫：估計 12 人月的任務，3 個人做 4 個月，每個月底有一個里程碑。

狀況：兩個月過去，第一個里程碑才剛達成（落後一個月）。

經理的判斷	剩下的工作	剩下的時間	算出來要幾個人
只有第一段估錯	9 人月	2 個月	4.5 人 → 加 2 人
整體都估低了	18 人月	2 個月	9 人 → 加 6 人

以「加 2 人」為例，書算給你看為什麼不行：

1. 新人需要一位有經驗的成員帶一個月——3 個人月花在原計畫以外的事情上。
2. 原本切成 3 份的工作要重新切成 5 份，有些已完成的工作會浪費，系統測試也要延長。
3. 結果：第三個月底還剩 7 人月以上的工作，卻只有 5 個有效人月——跟沒加人一樣延期。

書的結論：光考慮培訓時間，就需要加 4 個而不是 2 個人；再算上任務重新切分和額外的測試，還要更多——到那時，已經不是 3 人小組，而是 7 人以上的團隊，組織方式完全不同。而到了第三個月底，進度還是很糟，經理又會想再加人——同樣的循環再來一次。

★ 溝通成本的公式

書中的說法：如果每個人都要和其他每個人協調，工作量按 $n(n-1)/2$ 增加——

人數	溝通路徑
2	1
3	3（兩人的 3 倍）
4	6（兩人的 6 倍）
10	45
20	190

而需要三四個人一起開會解決的問題，情況更糟。書把工作分成三種，說明人與時間的關係：

任務類型	加人的效果
完全可分割、不需溝通（例：採收棉花）	人月可互換，加人就縮短時間
無法分割（例：懷孕）	加人完全沒用
可分割但需要溝通	加人有幫助，但效果遞減
關係錯綜複雜（軟體開發屬於這種）	溝通成本抵銷甚至超過分工的好處，加人反而延長時間

★ 落後時的正確選項

書列出的另外兩個選項：

1. 重新安排進度：書引用硬體工程師 P. Fagg 的忠告「不要做小的調整」（Take no small slips）——新進度要留足夠的時間，確保不必再調一次。
2. 削減功能：當延期的後續成本很高時，這常常是唯一可行的方法。要正式地調整範圍，而不是默默地讓功能因為倉促的設計和不完整的測試而被砍掉。

★ 書的時程經驗法則

布魯克斯多年使用的軟體時程分配：

階段	比例
計畫	1/3
編碼	1/6
元件測試與早期系統測試	1/4
系統測試（所有元件完成）	1/4

最容易估算的部分（編碼）只佔 1/6；測試佔將近一半。書觀察到，很少有專案計畫給測試一半的時間，但大多數專案實際上花了一半的時間在測試——延遲因此都在專案快結束時才爆發。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 例外是「完全可平行、無需溝通」的任務；但軟體開發極少屬於此類。

• 現代的修正：開源專案和成熟的平台工程顯示，模組邊界清楚、文件完整、上手流程自動化的系統，加人的成本可以大幅降低。布魯克斯定律不是「永遠不要加人」，而是「加人的成本主要來自溝通與上手，先降低這兩者」。

🔗 相關工具

• 工具-概念完整性 —— 為什麼加人會變慢的根本原因：人一多，設計的一致性就散掉
• 工具-降低在製品WIP —— 落後時真正有效的做法，不是加人而是少開幾條戰線
• 工具-找出並管理約束點 —— 加人之前該先問的問題：瓶頸在哪，加在非瓶頸處等於零