Brook定律："在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後"

以肥蝦個人的想法：" Brook's Law"不管是個人定義或是Law！所陳述的問題是在Crashing所要顧慮以及解決的問題。

就肥蝦個人淺薄的經驗發現目前對" 加人"，在公司與專案團隊之間有下列背後的駝鳥原因：

(1)逃避問題或找不出問題的推託藉口
專案經理：工作太多，作不完！人手不夠，無法完成當初專案的規劃！
高層主管：金額才那麼一點大，竟然要那麼多人作！

(2)推卸責任的推諉藉口
高層主管：照你的意思給你人了喔！還無法如期作完，是你專案經理專案管理不力！
專案經理：給的人素質、經驗都太差，來這邊是搞破壞的，專案延遲是主管找的人有問題！

這以上的對話是肥蝦個人常碰到的！然後就變成內部爭議，對專案只有雪上加霜！

其實專案延遲，一定是現況與當初所預定的計劃有了出入，有了當初未想到的問題！如果不能先找到問題的癥結，把一切都推到人手不夠，就算有一個功能強大的協同運作系統，也是無濟於事！況且新的成員對於協同運作系統也需要學習的時間，良好的協同運作系統，也僅能增進團隊運作的效率與效度！協助釐清專案的問題！但它可不是可以完全取代專案團隊在專案管理中的角色與功能。

增加資源(Crashing)所說的可不一定是加人，就算加人也要考慮幾個重點：
(1)時點：
專案晚期再加人，應考量新人學習成本與專案管理的成本，以及公司的成本！有時全面的考量終止合約，可能是比較划算的方案！

(2)經驗與配合度：
加入新的專案新成員，應先設定好他的角色與作用，需要何等程度的水平。先前肥蝦就遇過專案找進了一個經驗豐富的新成員，一來就批評那裏作錯！那裏不對！結果造成來一個走三個的困境。有時候，新成員的配合度比經驗還重要。

(3)其他選擇方案：
加快專案進度有很多種方式，基本上就有Crashing跟Fast-Tracking兩種！就算是Crashing也有提升開發環境與工具，採用外包把特定工作轉包，…。也不一定要直接於專案團隊中增加人手。

遇到專案延遲，專案經理應先跟團隊間開誠的找出問題根源，以及建議方案。如果需要加人，也要釐清新加入的成員所應負責的工作區塊，需要的技能與水準，融入專案所需要的時間。