Brook定律
"在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後"
最近在一本書上看到這句話，覺得真是心有戚戚焉.....
在以前的工作經驗中，曾經看到過一個類似這樣的情況:
A專案是F公司在幫某個類似公家單位的機構Y公司，開發一套符合他們內部流程管理系統
當A專案從F公司業務移交到專案單位之後，合約中有規定ㄧ個月內
必須提出專案管理計畫(Project Management Plan)，並送交Y公司的業務單位審核
審核完成之後，整個專案才正式進入開發階段
可是整個專案完成的時間，是有Deadline的，整個專案必須在6個月之內完成提出驗收申請
提出驗收申請表示系統的硬體環境建置、測試、軟體設計、開發、測試、轉檔等等都必須完成
所以時間上其實並不充裕.......
即使在這樣的情況之下，由於Y公司文化非常近似公家單位(意指做事效率差)
光是核准專案管理計畫，文件來來回回就浪費了將近三個月的時間
F公司的PM這邊依照當初起案時確立的溝通管理計畫，不斷的反應，效果並不大
所以整個系統的開發時間，一開始就有Delay的狀況出現
時間越接近當初合約訂的Deadline，當然F公司的PM只能尋求更多資源的投入(投入更多工程師)
其主管也同意，可是投入的人手，卻是F公司同一個集團之中的S公司的軟體工程師
這時更大的問題就來了:
ㄧ、由於公司文化的不同，S公司的軟體工程師並不知道如何解讀F公司系統的規格，所以還必須重新教育訓練
二、即使教育訓練完了，S公司的軟體工程師還必須花時間去熟悉F公司開發的流程跟工具
三、好不容易開發出來的程式問題仍然很多，並不符合需求
四、S公司的工程師管轄權還是在他們原本那裡，請假、調職、、等異動，F公司的PM無法掌握
種種原因導致A專案的時程Delay，成本超支，而且必須Rework的部份重複很多，成為一個失敗的專案。
PMBOK中提到有關溝通的管道:n(n-1)/2
每增加一個人，因而產生的溝通管道是越來越多的
尤其在軟體專案中，溝通的ㄧ致性、延續性都會產生很大的影響
以上的例子，恰好就能印證Brook定律
查了一下, wikipedia有一篇文章關於Brook's Law:
http://en.wikipedia.org/wiki/Brooks%27_law
如同這篇文章所說的, Brook本人都說了, 他的這個定律"過度簡化到不像話(outrageous oversimplification)", 所以呢? 過度簡化的定律不過是"個人定義"罷了. 況且寫這"law"時是在1975年或之前, 那時的軟體工程和現代的軟體工程並不同, 也沒有強大的協同運作系統, 難道一個延宕的工程就該放任不管? 專案會延宕, 一定是有很多的錯誤造成的, 加一個一般的人或許不能改善, 但是加一個更專業的人, 可能更有機會讓專案完成. 專案的目的是完成, 造成專案延宕的錯誤仍在, 不即時加入新血, 專案只有宣告失敗一途, Brook's Law的目的並非阻止新人的加入, 而是激勵延宕專案的管理人不要在"太晚"的時候加人. 應該要及時勇於面對問題. 至於文化的衝突, 這是軟體工程中必然發生的, Deal with it or fail it.
以肥蝦個人的想法：" Brook's Law"不管是個人定義或是Law！所陳述的問題是在Crashing所要顧慮以及解決的問題。
就肥蝦個人淺薄的經驗發現目前對" 加人"，在公司與專案團隊之間有下列背後的駝鳥原因：
(1)逃避問題或找不出問題的推託藉口
專案經理：工作太多，作不完！人手不夠，無法完成當初專案的規劃！
高層主管：金額才那麼一點大，竟然要那麼多人作！
(2)推卸責任的推諉藉口
高層主管：照你的意思給你人了喔！還無法如期作完，是你專案經理專案管理不力！
專案經理：給的人素質、經驗都太差，來這邊是搞破壞的，專案延遲是主管找的人有問題！
這以上的對話是肥蝦個人常碰到的！然後就變成內部爭議，對專案只有雪上加霜！
其實專案延遲，一定是現況與當初所預定的計劃有了出入，有了當初未想到的問題！如果不能先找到問題的癥結，把一切都推到人手不夠，就算有一個功能強大的協同運作系統，也是無濟於事！況且新的成員對於協同運作系統也需要學習的時間，良好的協同運作系統，也僅能增進團隊運作的效率與效度！協助釐清專案的問題！但它可不是可以完全取代專案團隊在專案管理中的角色與功能。
增加資源(Crashing)所說的可不一定是加人，就算加人也要考慮幾個重點：
(1)時點：
專案晚期再加人，應考量新人學習成本與專案管理的成本，以及公司的成本！有時全面的考量終止合約，可能是比較划算的方案！
(2)經驗與配合度：
加入新的專案新成員，應先設定好他的角色與作用，需要何等程度的水平。先前肥蝦就遇過專案找進了一個經驗豐富的新成員，一來就批評那裏作錯！那裏不對！結果造成來一個走三個的困境。有時候，新成員的配合度比經驗還重要。
(3)其他選擇方案：
加快專案進度有很多種方式，基本上就有Crashing跟Fast-Tracking兩種！就算是Crashing也有提升開發環境與工具，採用外包把特定工作轉包，…。也不一定要直接於專案團隊中增加人手。
遇到專案延遲，專案經理應先跟團隊間開誠的找出問題根源，以及建議方案。如果需要加人，也要釐清新加入的成員所應負責的工作區塊，需要的技能與水準，融入專案所需要的時間。
smallstartw
iThome鐵人賽
看影片追技術