「我參與的軟體開發專案又得延期了！」一名在大公司擔任程式設計師的學員問到：「公司高層很重視這個專案，所以從別的小組調人手過來應急，但為什麼我覺得他們越幫越忙？」
這不是他的錯覺，很多情況下，在專案延誤時添加人手，真的會讓事情更糟糕！
人員浪費、專案 delay，人手不是越多越好
當專案出現延宕的跡象時，傳統上會投入更多人力趕工，這也是大部分人直覺上會做的決策。
但，這個舉動猶如提油救火，只會越燒越大，最後變成一場必定失敗的災難。
這個說法可不是空穴來風。最早出此觀點的是被譽為「IBM System/360之父」的佛瑞德‧布魯克斯（Frederick P. Brooks, Jr.）。他曾在 IBM System/360 開發階段擔任專案經理、OS/360 設計階段擔任軟體專案經理。
在布魯克斯的職業生涯中，管理過許多大型專案、也見識過許多專案黯然收場。
他將這些經歷去蕪存菁，寫成軟體開發管理著作《人月神話》（The Mythical Man-Month）。
▲布魯克斯的《人月神話》對軟體專案管理領域影響深遠
在書中，他提出一項精闢的見解：
「在一個進度已經落後的專案中再增加人員，只會讓它更加落後。」後人稱之為布魯克斯法則（Brooks's Law）。
造成這個現象有幾大原因：
原因一：專業性高的工作不適合分割
布魯克斯表示，用人/月去衡量專案進度是個危險、欺騙性的方法，因為這會讓人產生「數量和時間可以替換」的錯覺。
如果是容易分割、人員之間完全不需要溝通且互不干擾的工作，如：刷油漆、採收水果等，才可能透過增加人手來減少作業時間；
但知識性質高的腦力工作，如：程式設計、企劃擬定、軟體開發等，工作內容不易拆分，就算拆分了也不可能所有人的同時、平行地作業，工期更不可能因此而縮短。
原因二：溝通成本大幅增加
PMBOK中提到，成員之間的溝通管道可用「n(n-1)/2」來表示，n代表人數。
這個公式清楚地展示出，每增加一個人，溝通管道就會大幅增加。其中造成資訊落差，對成員溝通的一致性、延續性都會產生很大的影響，也會劇烈地影響到進度──畢竟光是頻繁地開會就很讓人精疲力竭了！
原因三：新人需要時間適應
即使是再怎麼優秀的人才，剛進入新專案還是需要「暖機時間」，去熟悉新的開發流程跟工具，也難免犯一些錯。但是專案 delay 在即、加派人手就表示時程非常急迫了，等到新成員可以穩定的發揮產值後，可能專案已經胎死腹中了……。
原因四：放下自己的工作去帶新人，會花費更多時間
新成員需要時間熟悉，舊成員也會多出許多「隱形工作」──要重新劃分工作細項、教育訓練新成員、安排工作內容給新成員，甚至要抽身修正新成員犯的錯。這些工作費時費力，非但不可避免，還對專案進度完全沒幫助。
以上種種原因，造成「新成員產值不足、舊成員產值下降」，專案數度延誤、一拖再拖，最後宣告夭折。
結論
有句英文諺語是這麼說的："Nine women can't make a baby in one month".（九位女人也無法用一個月就生出小孩）；中文也有句俗諺：三個和尚沒水喝，都可以作為布魯克斯法則的註腳。
那專案延誤時到底該怎麼做呢？
根據布魯克斯的說法，最好的方法是──什麼也不做！就讓原本的人力按部就班地把工作完成就好了。
如果老闆非要塞人進來，比起讓新人插手你的工作，不如跟新人分享這篇文章、請他們不要打擾原本的成員，會更有幫助！
相關文章
延伸課程
作者：游振昌
撰寫：Project Club秘密寫手
●專案管理顧問有限公司 執行長
●中華國際專案經理人協會 理事長
●Project Club 發起人暨資深顧問
