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