三十年不變的管理問題
. 如果有一個專案，由一名員工去執行，需要十二個月的時間才能完成，那麼是不是投入十二名員工，就能在一個月完成？
例如，新加入專案的人手，必須要了解專案的現況，以及具備執行的能力，而能夠向新手說明和訓練他們的人，就是目前正在執行專案的人。結果，剛加入的新手不熟練，同時也容易出錯，而生產力較高的原始成員，則為了訓練新手，暫時放下手上的工作，團隊的整體生產力需要一段適應期才能恢復。
既然增加人手無用，那麼當專案無法如期完成時，主管應該怎麼做？布魯克斯提出了三個建議：第一，主管正式宣佈專案無法如期完成。比起什麼都不說，大家卻心知肚明，正式宣佈是比較好的做法。宣佈時，同時告知大家專案預計會延遲多久才完成。布魯克斯提醒，這個時間最好抓得充裕些，即使當時覺得只需要再四個月，也要先宣佈六個月，以避免發生二次延遲的窘境。
這個說法在數學上說得通，但是在實際管理上卻大有問題。美國北卡大學計算機科學系的創系人布魯克斯（Fred Brooks），三十年前將他在ＩＢＭ管理大型軟體專案的實際經驗，寫成「人月神話」（The Mythical Man-Month）一書，書中破除機械式地將人數乘以工時，以預估一個專案所需成本及時間的迷思。
有人稱「人月神話」為「軟體工程的聖經」，事實上，這本書闡述的專案管理之道，不只侷限於軟體領域，因此這本書也成為其他產業主管的必讀經典。
在「人月神話」出版三十週年之際，仍然在北卡大學執教、今年已經七十四歲的布魯克斯，最近接受財星雜誌專訪時表示，與三十年前相比，雖然現在管理團隊所使用的工具改變了，但是管理團隊所面對的問題還是一樣。
許多主管到現在還是很容易掉入「人數乘以工時」的陷阱。如果有一個專案的進度延遲，許多主管直覺地會投入更多員工，希望趕上進度。但是，這個動作增加了專案的負擔，往往反而拖慢了進度。
又例如，專案加入了支援者，整個團隊的官僚及複雜度隨之增加。團隊必須重新分配工作、需要溝通的人數變多，都可能讓專案慢上加慢。布魯克斯因而歸納出一條守則：增加人手到已經延遲的軟體專案，只會讓它延遲更久。
第二，減少專案的工作量。決定只完成某些部份的工作。第三，將工作分階段。決定先如期完成哪些部份，其餘的部份之後再補足。例如，在推出一個電腦軟體時，可以先推出對大多數重要顧客而言，最需要的核心功能，下一個版本再增加其他的功能。
留言列表
