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

      項(xiàng)目概況

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

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

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

      到這里似乎一切順利，但接下來的一個(gè)月中，未確定的需求和不斷發(fā)現(xiàn)的bug成了災(zāi)難。項(xiàng)目從原定的1/25推遲到2/8，再推遲到2/16。而這時(shí)開發(fā)團(tuán)隊(duì)也由原來的兩個(gè)人增加到五個(gè)人，增加的三個(gè)人專職測(cè)試。后終于發(fā)布了，結(jié)果發(fā)布當(dāng)天因?yàn)橐粋�(gè)小bug導(dǎo)致數(shù)十個(gè)用戶數(shù)據(jù)被誤刪。于是暫停服務(wù)繼續(xù)修改，改為封閉式開發(fā)，并且繼續(xù)增加測(cè)試隊(duì)伍到10個(gè)人，這樣整個(gè)團(tuán)隊(duì)有12個(gè)人在工作。

      這樣的狀況一直持續(xù)到二月底，項(xiàng)目總算正常發(fā)布了。

      計(jì)算一下結(jié)果

      下面是每個(gè)月的開發(fā)者數(shù)目。

      計(jì)劃 實(shí)際
      11月 2 1.5
      12月 2 2
      1月 2 5
      2月 0 8.5
      總計(jì) 6 17

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

      分析原因

      為什么這個(gè)項(xiàng)目會(huì)失��？我認(rèn)為原因在以下幾個(gè)方面。

      1. 忽視項(xiàng)目風(fēng)險(xiǎn)。這個(gè)項(xiàng)目的風(fēng)險(xiǎn)有以下幾條

      風(fēng)險(xiǎn) 影響(人月) 發(fā)生的可能性 實(shí)際影響(人月)
      未確定的需求 1 1
      原有框架的缺陷造成的實(shí)現(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
      總計(jì) 1.7

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

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

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

      風(fēng)險(xiǎn) 對(duì)策
      未確定的需求 嚴(yán)格控制流程，在詳細(xì)設(shè)計(jì)未完成之前禁止編碼
      原有框架的缺陷造成的實(shí)現(xiàn)困難 及早聯(lián)系框架開發(fā)者調(diào)整
      開發(fā)環(huán)境不完善 盡早使用較為完善的開發(fā)環(huán)境
      發(fā)布后的bug 發(fā)布β版

      3. 人月神話�！度嗽律裨挕愤@本經(jīng)典著作中提到，增加開發(fā)者并不能加快開發(fā)進(jìn)程。請(qǐng)注意2月份比1月份多出來的那3.5人月。從事后結(jié)果來看，這3.5人月并未發(fā)現(xiàn)一個(gè)有效的bug。這是因?yàn)�，這3.5人月是從其他項(xiàng)目組臨時(shí)借調(diào)過來的人員，完全不熟悉項(xiàng)目，加上不完善的測(cè)試用例，導(dǎo)致他們無法正確理解測(cè)試用例的意圖。

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

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

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

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

      結(jié)論

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

      因此無論項(xiàng)目有多么緊急，請(qǐng)務(wù)必腳踏實(shí)地地分析項(xiàng)目風(fēng)險(xiǎn)，不要抱有僥幸心理。