> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 布魯克斯定律

> 布魯克斯定律指出，向延誤的軟體專案增加人手會使其更加延誤。了解這一現象的原因、如何應用該定律，以及替代策略。

<Info>
  **Category**: 法則<br />
  **Type**: 專案管理<br />
  **Origin**: 軟體工程, 1975, 弗雷德·布魯克斯<br />
  **Also known as**: 人月神話
</Info>

<Note>
  **Quick Answer** —
  布魯克斯定律指出，向延誤的軟體專案增加人手會使其更加延誤。這一原則由弗雷德·布魯克斯基於其領導IBM
  OS/360專案的經驗提出，揭示了複雜專案中僅靠增加資源無法解決進度延誤問題——新成員需要培訓，且會產生協調開銷，抵消其短期貢獻。
</Note>

## 什麼是布魯克斯定律？

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

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

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

### 布魯克斯定律的三層理解

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

## 起源

**弗雷德·布魯克斯**（出生於1931年）是美國軟體工程師和電腦科學家，於20世紀60年代管理IBM的OS/360作業系統專案。OS/360專案是當時規模最大的軟體專案之一——數百萬行程式碼、数百名開發人員、雄心勃勃的跨IBM電腦線相容目標。

當專案落後於進度時，IBM管理層的常規反應是增加更多程式設計師。布魯克斯觀察到這只會讓事情變得更糟。新程式設計師必須學習龐大的程式碼庫，現有團隊成員花時間指導而非程式設計，增加的協調負擔拖慢了所有人的進度。

該專案最終發布，但晚了數年，預算嚴重超支。布魯克斯後來寫道，他從OS/360學到的最有價值的一課是：「生孩子需要九個月，無論分配多少女性都是如此。」

## 核心要點

<Steps>
  <Step title="溝通開銷隨團隊規模增長">
    每個新團隊成員都會與所有現有成員增加溝通渠道。有n個人，就有n(n-1)/2個可能的溝通路徑。10人的團隊有45條渠道；20人的團隊有190條。
  </Step>

  <Step title="新成員需要上手時間">
    在新開發人員能夠高效貢獻之前，他們必須學習程式碼庫、工具、流程和領域。在此期間，他們的消耗超過產出。
  </Step>

  <Step title="工作無法完美分割">
    許多軟體任務相互依賴，無法平行化。你無法簡單地將複雜系統分成獨立的部分並分配給不同的人而不需要協調。
  </Step>

  <Step title="最佳補救措施往往是縮減範圍">
    當進度落後時，最有效的干預措施是減少功能、改進流程或解決根本原因——而非增加更多人。
  </Step>
</Steps>

## 應用場景

<CardGroup cols={2}>
  <Card title="專案規劃" icon="calendar">
    將協調開銷納入考量，制定現實的進度計劃。要認識到將團隊規模翻倍很少能將時間線減半。
  </Card>

  <Card title="招聘決策" icon="users">
    抵制「用人解決問題」的誘惑。評估新員工能否快速上手以提供幫助。
  </Card>

  <Card title="危機管理" icon="exclamation-triangle">
    當專案落後時，首先調查根本原因。在不解決底層問題的情況下增加資源會使問題加劇。
  </Card>

  <Card title="團隊結構" icon="sitemap">
    設計自主性強、依賴性最低的團隊。康威定律表明系統架構反映團隊溝通模式。
  </Card>
</CardGroup>

## 經典案例

### OS/360專案

IBM在20世紀60年代中期的OS/360作業系統專案在規模上具有開創性——數百萬行程式碼、数百名開發人員、跨IBM電腦產品線的雄心勃勃的相容性目標。

當專案落後於進度時，IBM管理層常規地增加了更多程式設計師。布魯克斯觀察到這只會讓事情變得更糟。新程式設計師必須學習龐大的程式碼庫，現有團隊成員花時間指導而非程式設計，增加的協調負擔拖慢了所有人的進度。

該專案最終發布，但晚了數年，預算嚴重超支。布魯克斯後來寫道，他從OS/360學到的最有價值的一課是：「生孩子需要九個月，無論分配多少女性都是如此。」

## 邊界與失效場景

**法則不适用的場景：**

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

**常見誤用：**

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

## 常見誤區

<AccordionGroup>
  <Accordion title="布魯克斯定律意味著永遠不應該向專案增加人員">
    \*\*錯誤。\*\*該定律具體針對*延誤的*專案。如果工作可以分解，向進度正常但需要加速的專案增加人員可能有效。
  </Accordion>

  <Accordion title="該定律證明軟體開發人員是特殊的">
    \*\*錯誤。\*\*該原則適用於任何複雜的相互依賴的知識工作——不僅僅是軟體。創意專案、研究團隊和複雜的組織舉措都表現出類似的動態。
  </Accordion>

  <Accordion title="布魯克斯定律已過時因為現在有更好的工具">
    \*\*錯誤。\*\*雖然工具改進了，但溝通開銷和上手時間的基本挑戰仍然存在。現代敏捷方法實際上強調*更多*溝通，使該定律更加相關。
  </Accordion>
</AccordionGroup>

## 相關概念

<CardGroup cols={3}>
  <Card title="人月神話" icon="book">
    布魯克斯關於軟體專案管理的開創性著作，引入了這一定律。
  </Card>

  <Card title="康威定律" icon="sitemap">
    系統設計反映組織溝通結構的觀察。
  </Card>

  <Card title="帕金森定律" icon="clock">
    工作會擴展以填滿可用時間的觀察。
  </Card>

  <Card title="關鍵路徑分析" icon="route">
    識別決定專案工期的任務序列的專案管理技術。
  </Card>

  <Card title="敏捷方法論" icon="sync">
    強調疊代進展和團隊協作的開發方法。
  </Card>

  <Card title="範圍蔓延" icon="tape">
    專案需求超出原始目標的失控擴張。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  **記住：向延誤的專案增加人員會產生更多延誤——專注於減少範圍、改進流程或解決根本問題，而不是向進度問題投入資源。**
</Tip>