我曾經(jīng)做過一個失敗的項目。那時我對項目管理一知半解，對于風(fēng)險管理、進度管理等更是一無所知，以致最后花費了當(dāng)初幾倍的人力來挽救它造成的損失。

項目概況

這個項目的策劃是在11月開始的，是對現(xiàn)有的一個Web應(yīng)用程序進行改造。客戶寫了一份簡單的需求說明，希望能在12/25圣誕節(jié)之前投入使用。根據(jù)這份需求說明，我們整理出了一份功能列表，然后估算每個功能的代碼規(guī)模，發(fā)現(xiàn)規(guī)模大大超出期限，于是跟客戶交涉，刪減了一些功能，并將發(fā)布日期定為1/26。最后結(jié)果為服務(wù)器端3KL，客戶端3KL，按照1KL/人月的保守估計，需要6個人月，投入兩個人，正好能在1月底完工。于是項目就開始了。

為檢查項目進行狀況，客戶希望在12/25之前發(fā)布beta測試版。因此主要功能必須在短短的兩個月之內(nèi)完成。為了趕工期，我們省略了概要設(shè)計和大部分的詳細設(shè)計，直接進入編碼階段。一部分用戶需求還未確定，只好先進行確定部分的編碼工作，將那些遲遲沒有定論的需求放在beta版發(fā)布之后。

我負責(zé)客戶端的開發(fā)，很不幸的是負責(zé)服務(wù)器端開發(fā)的同事在11月上旬一直在忙于另一個項目，而到了11月中旬又因病離職，導(dǎo)致11月份服務(wù)器端幾乎沒有任何進展。好在服務(wù)器端開發(fā)難度不大，項目組在12月份調(diào)入另一名強人來接班。在我倆的努力下終于在12/24如期發(fā)布了beta版。

到這里似乎一切順利，但接下來的一個月中，未確定的需求和不斷發(fā)現(xiàn)的bug成了災(zāi)難。項目從原定的1/25推遲到2/8，再推遲到2/16。而這時開發(fā)團隊也由原來的兩個人增加到五個人，增加的三個人專職測試。最后終于發(fā)布了，結(jié)果發(fā)布當(dāng)天就因為一個小bug導(dǎo)致數(shù)十個用戶數(shù)據(jù)被誤刪。于是暫停服務(wù)繼續(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

實際的工時約為預(yù)計的3倍。

分析原因

為什么這個項目會失敗？我認為原因在以下幾個方面。

1. 忽視項目風(fēng)險。這個項目的風(fēng)險有以下幾條

風(fēng)險 影響(人月) 發(fā)生的可能性 實際影響(人月)
未確定的需求 1 100% 1
原有框架的缺陷造成的實現(xiàn)困難 0.5 20% 0.1
開發(fā)環(huán)境不完善 0.2 50% 0.1
新的bug管理系統(tǒng)造成的學(xué)習(xí)困難 0.2 50% 0.1
發(fā)布后的bug 1 50% 0.5
總計 1.7

總計是1.8人月，也就是說項目應(yīng)當(dāng)在計劃的6人月上再加上1.8人月，實際的估算值應(yīng)為7.8人月。但在估算時并沒有考慮到這些風(fēng)險（或者說，雖然考慮到了但卻沒有認識到它的嚴重性），導(dǎo)致1月底計劃結(jié)束時風(fēng)險暴露，不得不增加人力來修補問題。

2. 對風(fēng)險未采取相應(yīng)對策。實際上，上述風(fēng)險中甚至存在發(fā)生概率為100%的風(fēng)險，但由于開發(fā)者過于自信（所謂的“自我膨脹”），以致并未采取相關(guān)措施。甚至在12月底，某些問題已浮出水面時依然未進行控制。

當(dāng)初如果能采取一些對策，或許就不會這么糟糕。

風(fēng)險 對策
未確定的需求 嚴格控制流程，在詳細設(shè)計未完成之前禁止編碼
原有框架的缺陷造成的實現(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)過來的人員，完全不熟悉項目，加上不完善的測試用例，導(dǎo)致他們無法正確理解測試用例的意圖。

通常編碼過程中的人月效應(yīng)都能引起大家的重視，但實際上測試階段也存在人月效應(yīng)，它的影響并不比編碼時小多少。

并不是說不能加人，加人時也要加有經(jīng)驗的開發(fā)者（比如1月份比12月份多的那3個人月）。

4. 盲目編程，跳過概要設(shè)計和詳細設(shè)計，直接進行編碼。我們都知道，隨著項目的進行，修改一個bug所花費的時間會呈指數(shù)增加。也就是說，一個本應(yīng)在詳細設(shè)計階段發(fā)現(xiàn)的bug，推遲到單元測試階段修改，所花時間將是詳細設(shè)計階段修改的幾十倍；如果推遲到正式部署之后再修改，所花費時間將是詳細設(shè)計階段修改的上萬倍。

因此，跳過概要設(shè)計和詳細設(shè)計，相當(dāng)于增加了修改bug的時間，擴大了項目風(fēng)險。

結(jié)論

軟件項目開發(fā)中的幾個重點——質(zhì)量管理、進度管理、風(fēng)險管理，通常大家都會注意到前兩者，而風(fēng)險管理則鮮有人知，為什么？因為風(fēng)險是有概率的，不像質(zhì)量和進度那么實在，而這種不確定性使得它很容易因為開發(fā)者的自負和自我膨脹心理而被忽略。

因此無論項目有多么緊急，請務(wù)必腳踏實地地分析項目風(fēng)險，不要抱有僥幸心