我曾經(jīng)做過一個失敗的項目。那時我對項目管理一知半解，對于風險管理、進度管理等更是一無所知，以致后花費了當初幾倍的人力來挽救它造成的損失。
項目概況
這個項目的策劃是在11月開始的，是對現(xiàn)有的一個Web應用程序進行改造。客戶寫了一份簡單的需求說明，希望能在12/25圣誕節(jié)之前投入使用。根據(jù)這份需求說明，我們整理出了一份功能列表，然后估算每個功能的代碼規(guī)模，發(fā)現(xiàn)規(guī)模大大超出期限，于是跟客戶交涉，刪減了一些功能，并將發(fā)布日期定為1/26。后結(jié)果為服務器端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ā)布了，結(jié)果發(fā)布當天因為一個小bug導致數(shù)十個用戶數(shù)據(jù)被誤刪。于是暫停服務繼續(xù)修改，改為封閉式開發(fā)，并且繼續(xù)增加測試隊伍到10個人，這樣整個團隊有12個人在工作。
這樣的狀況一直持續(xù)到二月底，項目總算正常發(fā)布了。
計算一下結(jié)果
下面是每個月的開發(fā)者數(shù)目。
計劃 實際
11月 2 1.5
12月 2 2
1月 2 5
2月 0 8.5
總計 6 17
實際的工時約為預計的3倍。
分析原因
為什么這個項目會失�。课艺J為原因在以下幾個方面。
1. 忽視項目風險。這個項目的風險有以下幾條
風險 影響(人月) 發(fā)生的可能性 實際影響(人月)
未確定的需求 1 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月底計劃結(jié)束時風險暴露，不得不增加人力來修補問題。
2. 對風險未采取相應對策。實際上，上述風險中甚至存在發(fā)生概率為的風險，但由于開發(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人月。從事后結(jié)果來看，這3.5人月并未發(fā)現(xiàn)一個有效的bug。這是因為，這3.5人月是從其他項目組臨時借調(diào)過來的人員，完全不熟悉項目，加上不完善的測試用例，導致他們無法正確理解測試用例的意圖。
通常編碼過程中的人月效應都能引起大家的重視，但實際上測試階段也存在人月效應，它的影響并不比編碼時小多少。
并不是說不能加人，加人時也要加有經(jīng)驗的開發(fā)者（比如1月份比12月份多的那3個人月）。
4. 盲目編程，跳過概要設計和詳細設計，直接進行編碼。我們都知道，隨著項目的進行，修改一個bug所花費的時間會呈指數(shù)增加。也是說，一個本應在詳細設計階段發(fā)現(xiàn)的bug，推遲到單元測試階段修改，所花時間將是詳細設計階段修改的幾十倍；如果推遲到正式部署之后再修改，所花費時間將是詳細設計階段修改的上萬倍。
因此，跳過概要設計和詳細設計，相當于增加了修改bug的時間，擴大了項目風險。
結(jié)論
軟件項目開發(fā)中的幾個重點——質(zhì)量管理、進度管理、風險管理，通常大家都會注意到前兩者，而風險管理則鮮有人知，為什么？因為風險是有概率的，不像質(zhì)量和進度那么實在，而這種不確定性使得它很容易因為開發(fā)者的自負和自我膨脹心理而被忽略。
因此無論項目有多么緊急，請務必腳踏實地地分析項目風險，不要抱有僥幸心理。
