概念地圖・布魯克斯法則
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
布魯克斯法則：加人，為什麼更晚交件
一個專案眼看要遲了，最直覺的動作是加人。布魯克斯（Frederick Brooks）在《人月神話》裡丟下一句反直覺的話：對一個已經落後的軟體專案增加人力，只會讓它更晚完成。理由不玄——新人要有人帶、要花時間熟悉，而每多一個人，團隊裡要維持的溝通線路就以 n(n-1)/2 的速度往上翻。這張圖把兩件事疊在同一個座標上：淡色柱是溝通路徑數，紅線是預計完工的週數。你會看到那條紅線先往下、再狠狠往上翹。
每加一個人，帳單上會多出三筆
「加人」在試算表上是一格加法，在現場卻同時觸發三件事。把它們列出來對照，就知道那條紅線為什麼會翹起來。
| 團隊人數 | 要維持的溝通路徑 | 新人前三週在做什麼 | 老手被拿走的時間 |
|---|---|---|---|
| 3 人 | 3 條 | 看文件、問問題 | 每天約半小時 |
| 6 人 | 15 條 | 還在摸環境與規格 | 每天約一小時半 |
| 9 人 | 36 條 | 交叉問到互相打斷 | 每天超過三小時 |
| 12 人 | 66 條 | 開始出現重工與衝突 | 幾乎整天在帶人 |
表格裡最刺眼的是最後一欄。你以為加進來的是產能，實際上先扣掉的是最懂這個專案的那個人的時間——而他正是唯一能把進度救回來的人。專案越急，這一扣越致命。
加人之前，先把四件事問清楚
布魯克斯法則真正在講的是：加人有三筆成本，你得先算得出來。四個自問，決定你這次加人是加速還是踩煞車。
一、這件工作切得開嗎。布魯克斯用過一個很好記的比喻：一個女人生一個小孩要九個月，九個女人生不出一個月大的小孩。有些工作天生不可分割——一份需求規格要一個人想通、一段核心邏輯要一個腦袋一次拉完。可切割的工作（測試案例、資料清理、上百頁的內容搬移、獨立的模組）加人才有意義。判斷方式很土：把工作攤在白板上，看你能不能真的畫出兩塊「彼此不需要對話就能做完」的區域。自問：我畫得出兩塊互不打擾就能完成的工作嗎？
二、上手要多久，剩下的時間夠不夠回本。新人有一段完全沒有產出、還會消耗老手的期間，這段時間依複雜度從一週到兩個月不等。粗略算法：上手期 × 2（因為老手也被佔用）＝ 這次加人的先付成本。如果專案只剩四週、上手期要三週，那筆先付成本你根本來不及回收。反過來，如果距離交付還有半年，加人幾乎一定划算。自問：剩下的時程，是上手期的三倍以上嗎？
三、多出來的溝通，誰來吸收。n(n-1)/2 是「全部互通」的最壞情況。真實團隊會用結構把它壓下來：分成兩個各自完整的小組、指定一個對外窗口、把介面規格先凍結。這些做法的本質都是「切斷不必要的路徑」。沒有做這件事就直接把人塞進同一個群組，路徑數就真的照公式膨脹。自問：新人進來以後，他每天固定要跟幾個人對話？超過三個就該重畫分組。
四、要加的是人手，還是決策。很多專案真正卡住的地方，是有一個沒人敢拍板的問題懸在那裡——規格改不改、要不要砍功能、誰說了算。這種卡住加十個人也沒用，因為十個人一起等同一個答案。動手加人之前，先看最近兩週的進度日誌，找出「因為等某個回覆而停擺」的時數佔多少。自問：過去兩週真正的阻塞，是缺工時還是缺答案？
一次七月的政府標案，加了四個人之後
一家四十人規模的系統整合商，接了一個縣市政府的線上申辦系統，交期壓在年底。十月底盤點，進度落後大約三週。專案經理的第一個動作是從別的專案調四個工程師過來，團隊從五人變九人。
- 調人前：五人團隊，每日站立會議十五分鐘，溝通路徑 10 條。節奏穩
- 調人後第一週：站立會議變成四十分鐘，路徑數 36 條，資深工程師整天在回答問題。產出反而下降
- 第三週：新人開始交東西，但介面對不上，出現兩處重工。又賠掉五個工作天
- 第五週：改成兩個獨立小組，一組顧申辦流程、一組顧後台審核，中間只用一份凍結的介面文件對話。路徑數壓回 6＋6
- 結案：比原訂晚兩週上線，比落後盤點時的三週略有改善。但那四個人的成本沒有回本
最值得記下來的是第五週那個動作：真正救回局面的，是把九個人重新切成兩個互不打擾的小組——被修好的是溝通結構，那四個人只是順便被安置到了對的位置。事後檢討時大家才承認，十月底真正該做的決定其實是砍掉兩個「有比較好、沒有也能上線」的功能——那個決定不用花一毛錢，效果比調四個人大得多，只是需要有人願意去跟甲方開口。以上為說明結構用的示意情境，數字僅供比例參考。
這條法則，有三個地方會被誤用
布魯克斯法則很常被拿來當拒絕增員的擋箭牌。它有它的邊界。
- 它講的是「已經落後的專案」，不是所有專案。原句的主詞很明確：對落後的軟體專案加人。專案還在早期、時程還寬裕、工作可切割時，加人的效益很正常。把這句話擴大成「團隊永遠不該變大」，等於用一條特定情境的警語去封鎖所有成長。判斷的關鍵永遠是那個時間差：離交付還剩多久，夠不夠攤提上手期。
- 它假設新人完全陌生。如果調進來的人以前就在這個系統上待過、熟悉這套工具、認識這群人，上手期可能只有兩天，三筆成本裡最重的一筆幾乎歸零。所以「內部熟人回鍋」跟「外部新血空降」是完全不同的兩件事，卻常被放進同一句「加人沒用」裡討論。
- 它容易被拿來合理化過勞。現場最常見的誤用是：主管引用布魯克斯法則否決增員，然後要現有五個人加班撐完。這其實偷換了問題——法則說的是「加人救不了時程」，從來沒說「所以請原班人馬用健康換」。落後專案真正剩下的選項只有三個：砍範圍、延期、降品質。加人不在選項裡，而加班也只是把延期偽裝成健康損耗。
用痛點的眼光，再看一次那條曲線
加人是一個看得見的動作，因此它經常被拿來取代一個看不見的決定。
專案落後的時候，主管站在一個很難受的位置：老闆要交代、客戶在等、團隊在燒。這時「我調了四個人進去」是一句可以馬上說出口的話，而「我打算砍掉兩個功能」需要先去跟人吵架。前者立刻緩解了主管自己的痛，後者才緩解專案的痛——兩種痛不是同一個人的痛，而動作往往服務比較痛的那一個。這就是為什麼這條法則寫在一九七五年，五十年後大家還在犯。把它接回《痛點》那把尺會更清楚：P 是誰在痛，這一格如果答成「我」而不是「這個專案」，後面三格就會全部歪掉。所以看到自己想加人的時候，先做一件很小的事——把「這次加人要解決的具體阻塞」寫成一句話，寫不出來，那條紅線就會往上翹給你看。
關於布魯克斯法則，常被問到的幾件事
布魯克斯法則只適用於軟體嗎？
原句是針對軟體專案講的，但底層的三筆成本（訓練、溝通、工作不可分割）在任何知識工作裡都成立：一份報告、一支影片、一場活動的企劃。差別在於程度。體力密集、切割容易的工作（搬東西、貼標籤、鋪貨）幾乎不受這條法則影響，加人就是加產能；而越需要「大家腦中有同一張圖」的工作，受影響越深。判斷方法是問自己：這件事要做對，需要多少共識？需要越多共識，加人越危險。
那專案落後時到底該怎麼辦？
選項其實只有三個：縮小範圍、延後交期、降低完成標準。三個都不好看，但它們是真的能改變結果的槓桿。實務上最有效也最少人做的是第一個——把功能清單攤開，逐項問「少了這個，上線會不會出事」，通常能砍掉兩到三成。第二有效的是把交期誠實往後移，越早講傷害越小，拖到最後一週才講會同時失去信任跟時間。加人可以做，但要當成下一階段的投資，不是這一次的解藥。
要加人的話，加在哪個位置最不痛？
加在「可以獨立完成、且不需要大量背景知識」的邊緣工作上：測試、資料整理、文件、環境建置、驗收準備。這些工作切得開、上手快、幾乎不增加核心開發者的溝通負擔。反過來最糟的是把新人塞進正在趕的核心模組，那等於同時付出三筆成本。另一個實務做法是讓新人先接手老手身上的雜事，把老手完整地釋放到關鍵路徑上——加的是人手，省下來的是最稀缺的那顆腦袋。
遠端工作和協作工具，有沒有讓這條法則失效？
工具讓溝通變便宜，但沒有讓溝通變少，某些情況反而更多——訊息、頻道、會議連結的數量往往比實體時期還高。真正把路徑數壓下來的一直是組織設計這件事本身：把團隊切成小而完整的單位、把介面講清楚、讓每個人固定只跟少數幾個人對話。這也是為什麼近年談團隊拆法的做法會強調「一個團隊要能獨立交付一件事」，它處理的正是同一個公式。
團隊多大最理想？
沒有普世答案，但業界的經驗值落在五到九人之間，理由跟路徑數直接相關：九個人是 36 條，再往上就開始難以維持共同認知。所以成熟團隊到了這個規模，通常會讓它分裂成兩個各自完整的小單位。要注意的是分裂必須連工作範圍一起分，只分人不分事，路徑數不會下降，只是換了個群組名稱。
想知道加人之後那些溝通負擔會壓在誰頭上，可以接著看認知負荷；如果你的專案卡的是「範圍、時間、品質三選二」，專案管理三角那張圖會更直接。至於這條法則的出處，《人月神話》的拆書把它放回一九七五年的現場，讀起來會更有畫面。
同一個概念，站上還有別的講法——
拆給你聽：案子已經落後，為什麼加人反而更慢？喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。