布魯克斯定律

​

什麼是布魯克斯定律？

布魯克斯定律是軟體專案管理中的一項基本原則，描述了團隊規模與專案進度之間違反直覺的關係。該定律指出，向已經延誤的專案增加更多人會使專案進一步延誤——並非因為新人能力不足，而是因為入職、溝通和協調本身存在固有成本。

「向延誤的軟體專案增加人手，會使其更加延誤。」—— 弗雷德·布魯克斯

核心洞察在於軟體開發不同於製造業。在工廠中，增加工人通常會相應增加產出。但在複雜的知識工作中，溝通開銷呈非線性增長。每個新人都必須接受培訓、融入工作流程，並與現有團隊成員協調——這些工作會分散實際進展的注意力。

​

布魯克斯定律的三層理解

• 入門: 理解向陷入困境的專案增加人員往往會使情況變得更糟，而非更好。新成員的初始熱情會被培訓和協調成本所抵消。
• 實務: 在向延誤專案增加資源之前，先計算新成員的「上手時間」和協調開銷。通常，減少範圍或改進流程比增加人員更有效。
• 進階: 認識到布魯克斯定律在高度相互依賴的專案中最為適用。高度模組化的專案可以更容易地吸收新成員。還要了解何時可以規避該定律——向「功能農場」（低耦合）增加人員。

​

起源

弗雷德·布魯克斯（出生於1931年）是美國軟體工程師和電腦科學家，於20世紀60年代管理IBM的OS/360作業系統專案。OS/360專案是當時規模最大的軟體專案之一——數百萬行程式碼、数百名開發人員、雄心勃勃的跨IBM電腦線相容目標。 當專案落後於進度時，IBM管理層的常規反應是增加更多程式設計師。布魯克斯觀察到這只會讓事情變得更糟。新程式設計師必須學習龐大的程式碼庫，現有團隊成員花時間指導而非程式設計，增加的協調負擔拖慢了所有人的進度。 該專案最終發布，但晚了數年，預算嚴重超支。布魯克斯後來寫道，他從OS/360學到的最有價值的一課是：「生孩子需要九個月，無論分配多少女性都是如此。」

​

核心要點

​

應用場景

​

經典案例

​

OS/360專案

IBM在20世紀60年代中期的OS/360作業系統專案在規模上具有開創性——數百萬行程式碼、数百名開發人員、跨IBM電腦產品線的雄心勃勃的相容性目標。 當專案落後於進度時，IBM管理層常規地增加了更多程式設計師。布魯克斯觀察到這只會讓事情變得更糟。新程式設計師必須學習龐大的程式碼庫，現有團隊成員花時間指導而非程式設計，增加的協調負擔拖慢了所有人的進度。 該專案最終發布，但晚了數年，預算嚴重超支。布魯克斯後來寫道，他從OS/360學到的最有價值的一課是：「生孩子需要九個月，無論分配多少女性都是如此。」

​

邊界與失效場景

法則不适用的場景：

• 高度模組化的專案: 如果工作可以乾淨地分成獨立模組，增加人員可能有所幫助。關鍵是任務是否具有真正的依賴性。
• 專案早期階段: 向剛啟動的專案增加人員可能成本較低，因為需要學習的上下文較少。
• 純順序任務: 如果工作是純附加性的（如資料輸入），更多人確實可以提高吞吐量。

常見誤用：

• 用布魯克斯定律為人員不足辯護: 定律並非說你永遠不應該增加人員——它說的是向延誤的專案增加人員是反效果的。從一開始就配備充足人員仍然很重要。
• 在緊急情況下忽略該定律: 一些管理者恐慌並仍然增加人員，反覆吸取這一教訓。
• 將其應用於所有領域: 布魯克斯定律具體針對軟體；其在其他領域的適用性各不相同。

​

常見誤區

​

相關概念

​

一句話總結