我曾經(jīng)做過一個失敗的項目。那時我對項目管理一知半解，對于風險管理、進度管理等更是一無所知，以致最后花費了當初幾倍的人力來挽救它造成的損失。
項目概況
這個項目的策劃是在11月開始的，是對現(xiàn)有的一個Web應用程序進行改造?？蛻魧懥艘环莺唵蔚男枨笳f明，希望能在12/25圣誕節(jié)之前投入使用。根據(jù)這份需求說明，我們整理出了一份功能列表，然后估算每個功能的代碼規(guī)模，發(fā)現(xiàn)規(guī)模大大超出期限，于是跟客戶交涉，刪減了一些功能，并將發(fā)布日期定為1/26。最后結果為服務器端3KL，客戶端3KL，按照1KL/人月的保守估計，需要6個人月，投入兩個人，正好能在1月底完工。于是項目就開始了。
為檢查項目進行狀況，客戶希望在12/25之前發(fā)布beta測試版。因此主要功能必須在短短的兩個月之內(nèi)完成。為了趕工期，我們省略了概要設計和大部分的詳細設計，直接進入編碼階段。一部分用戶需求還未確定，只好先進行確定部分的編碼工作，將那些遲遲沒有定論的需求放在beta版發(fā)布之后。
我負責客戶端的開發(fā)，很不幸的是負責服務器端開發(fā)的同事在11月上旬一直在忙于另一個項目，而到了11月中旬又因病離職，導致11月份服務器端幾乎沒有任何進展。好在服務器端開發(fā)難度不大，項目組在12月份調(diào)入另一名強人來接班。在我倆的努力下終于在12/24如期發(fā)布了beta版。
到這里似乎一切順利，但接下來的一個月中，未確定的需求和不斷發(fā)現(xiàn)的bug成了災難。項目從原定的1/25推遲到2/8，再推遲到2/16。而這時開發(fā)團隊也由原來的兩個人增加到五個人，增加的三個人專職測試。最后終于發(fā)布了，結果發(fā)布當天就因為一個小bug導致數(shù)十個用戶數(shù)據(jù)被誤刪。于是暫停服務繼續(xù)修改，改為封閉式開發(fā)，并且繼續(xù)增加測試隊伍到10個人，這樣整個團隊就有12個人在工作。
這樣的狀況一直持續(xù)到二月底，項目總算正常發(fā)布了。
計算一下結果
下面是每個月的開發(fā)者數(shù)目。
計劃 實際
11月 2 1.5
12月 2 2
1月 2 5
2月 0 8.5
總計 6 17
實際的工時約為預計的3倍。
分析原因
為什么這個項目會失?。课艺J為原因在以下幾個方面。
1. 忽視項目風險。這個項目的風險有以下幾條
風險 影響(人月) 發(fā)生的可能性 實際影響(人月)
未確定的需求 1 100% 1
原有框架的缺陷造成的實現(xiàn)困難 0.5 20% 0.1
開發(fā)環(huán)境不完善 0.2 50% 0.1
新的bug管理系統(tǒng)造成的學習困難 0.2 50% 0.1
發(fā)布后的bug 1 50% 0.5
總計 1.7
總計是1.8人月，也就是說項目應當在計劃的6人月上再加上1.8人月，實際的估算值應為7.8人月。但在估算時并沒有考慮到這些風險（或者說，雖然考慮到了但卻沒有認識到它的嚴重性），導致1月底計劃結束時風險暴露，不得不增加人力來修補問題。
2. 對風險未采取相應對策。實際上，上述風險中甚至存在發(fā)生概率為100%的風險，但由于開發(fā)者過于自信（所謂的“自我膨脹”），以致并未采取相關措施。甚至在12月底，某些問題已浮出水面時依然未進行控制。
當初如果能采取一些對策，或許就不會這么糟糕。
風險 對策
未確定的需求 嚴格控制流程，在詳細設計未完成之前禁止編碼
原有框架的缺陷造成的實現(xiàn)困難 及早聯(lián)系框架開發(fā)者調(diào)整
開發(fā)環(huán)境不完善 盡早使用較為完善的開發(fā)環(huán)境
發(fā)布后的bug 發(fā)布β版
3. 人月神話?！度嗽律裨挕愤@本經(jīng)典著作中提到，增加開發(fā)者并不能加快開發(fā)進程。請注意2月份比1月份多出來的那3.5人月。從事后結果來看，這3.5人月并未發(fā)現(xiàn)一個有效的bug。這是因為，這3.5人月是從其他項目組臨時借調(diào)過來的人員，完全不熟悉項目，加上不完善的測試