IT項(xiàng)目管理從某個(gè)意義上來說，是風(fēng)險(xiǎn)管理。從理論上講風(fēng)險(xiǎn)管理可以分為三個(gè)部分：風(fēng)險(xiǎn)識別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)解決。 傳統(tǒng)的風(fēng)險(xiǎn)管理系統(tǒng)只能幫我們較正規(guī)地統(tǒng)計(jì)和管理風(fēng)險(xiǎn)，這些系統(tǒng)本身是不能規(guī)避或解決任何風(fēng)險(xiǎn)的。在實(shí)際操作上，由于可能發(fā)生風(fēng)險(xiǎn)的種類很多，處理起來所耗費(fèi)的人力物力也相當(dāng)可觀。在下列的案例中，我們建議的不是一套昂貴而且全面的風(fēng)險(xiǎn)管理系統(tǒng)，而是一套扼住關(guān)鍵部位，高效且低成本，適合于千萬中小企業(yè)的小型解決方案。

  一個(gè)案例

  在2009年某家在北京海淀區(qū)的嵌入式產(chǎn)品公司跟我們討論項(xiàng)目管理時(shí)，該公司的王總監(jiān)跟我們做了以下溝通。他們項(xiàng)目風(fēng)險(xiǎn)種類可以概略分為四類：

  （1） 需求風(fēng)險(xiǎn) ??對需求理解不夠透徹或需求變更頻繁；

  （2） 人員風(fēng)險(xiǎn) ??人員生病或離職，一時(shí)無法找到替代者；

  （3） 技術(shù)風(fēng)險(xiǎn) ??某個(gè)關(guān)鍵的技術(shù)問題無法快速攻克；

  （4） 管理風(fēng)險(xiǎn) ??管理人員協(xié)調(diào)能力和執(zhí)行力能力不足，計(jì)劃偏差，流程更改和溝通不良等。

  這些風(fēng)險(xiǎn)的發(fā)生導(dǎo)致的結(jié)果是項(xiàng)目延期和成本大幅攀升。無法有效處理這些風(fēng)險(xiǎn)的兩個(gè)大問題在于：

  （1）對風(fēng)險(xiǎn)的反應(yīng)遲鈍 ??常常是太晚發(fā)現(xiàn)問題，以至于無法彌補(bǔ)或是彌補(bǔ)成本太大；

  （2） 對過程難以掌控 ??雖已有既定的流程，但由于人員變動、流程變動、系統(tǒng)出錯(cuò)等問題，很難照著走。

  為了讓我們更理解，王總監(jiān)很生動的解釋了以上兩個(gè)問題。對風(fēng)險(xiǎn)反應(yīng)遲鈍的問題，他說，在做項(xiàng)目計(jì)劃時(shí)為求實(shí)際，總會多估個(gè)20%到40%的時(shí)間。如果項(xiàng)目需求清晰，或是團(tuán)隊(duì)做過類似項(xiàng)目，用20%或多些；如果是新項(xiàng)目，或風(fēng)險(xiǎn)因素多便用30%到40%。所以，當(dāng)某些風(fēng)險(xiǎn)（如，需求變更或人員變動）發(fā)生了，一般也未必馬上造成項(xiàng)目延期？墒牵绻L(fēng)險(xiǎn)發(fā)生量繼續(xù)增加，或是某一兩個(gè)風(fēng)險(xiǎn)產(chǎn)生較嚴(yán)重的沖擊，在某個(gè)時(shí)刻會過了臨界點(diǎn)。難的地方是項(xiàng)目大人員多，是連項(xiàng)目經(jīng)理也是見樹不見林。

  對過程難以掌控的問題，王總監(jiān)舉了個(gè)例子。公司的研發(fā)制度里規(guī)定，為保證需求的準(zhǔn)確性，一個(gè)需求的變更要經(jīng)過（1）該項(xiàng)目經(jīng)理，（2）一位程序員，和（3）該產(chǎn)品經(jīng)理，等三個(gè)關(guān)鍵人審核后才可以進(jìn)行更改。王總監(jiān)說：需求變更的過程在邏輯上看似簡單，但在實(shí)際操作時(shí)卻不斷地發(fā)生問題。舉例來說，內(nèi)部溝通主要是以郵件通知的方式進(jìn)行，需求變更的文檔寄來寄去，版本很多，而且郵件總是遺失。另有一次更嚴(yán)重，產(chǎn)品經(jīng)理因?yàn)樾菁，沒能及時(shí)查郵件。在等了兩天后，因怕誤了工期，項(xiàng)目經(jīng)理便越權(quán)要求程序員把代碼寫了。不巧，產(chǎn)品經(jīng)理對這需求的更改有他強(qiáng)烈的意見。當(dāng)他看到在沒得到他的同意下把代碼寫了，火冒三丈，直接在會議中和項(xiàng)目經(jīng)理吵了起來。

  兩個(gè)控制風(fēng)險(xiǎn)的原則

  雖然風(fēng)險(xiǎn)總是發(fā)生，但如同大多數(shù)的公司一樣，該公司也不愿意花費(fèi)太多的精力和時(shí)間在這風(fēng)險(xiǎn)管控上，所以在尋求一個(gè)低成本又高效的管控方法。王總監(jiān)和我們在研討后，使用工具DevSuite基于下列兩個(gè)原則做了處理。（為避免篇幅太大，以下我們僅把精彩的點(diǎn)列出來。）

  （1） 提高項(xiàng)目的可視性

  不論是哪一種風(fēng)險(xiǎn)，其后沖擊的基本上是項(xiàng)目本身，延期是常見的結(jié)果。如果是對可能發(fā)生的風(fēng)險(xiǎn)都一一進(jìn)行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對項(xiàng)目延期有效的解決辦法，因?yàn)樗艽蟪潭鹊靥岣吡隧?xiàng)目的可視性。在實(shí)際操作時(shí)，我們讓團(tuán)隊(duì)成員每天對其參與的每一任務(wù)都鍵入下列兩項(xiàng)數(shù)字：1）該任務(wù)花費(fèi)時(shí)間，和2）該任務(wù)所剩時(shí)間。結(jié)果會生了類似如下的燃盡圖。
 

  如圖所示，起初這項(xiàng)目被估計(jì)是要3480小時(shí)完成。大致上來說，一般的研發(fā)團(tuán)隊(duì)因著人員請假、會議和其他突發(fā)事情，平均每人每天只能有六小時(shí)花在實(shí)際項(xiàng)目工作上，F(xiàn)這項(xiàng)目有七個(gè)人參與，估算出來大約需要四個(gè)月完成。（也是從2009年11月29日到2010年3月29日，圖中紅色直立線為起始線，藍(lán)色直立線為終止線。）這圖里共有三條曲線。紅色號碼?/span>表示到現(xiàn)在為止在該項(xiàng)目的總花費(fèi)時(shí)間，紅色號碼?表示估算的項(xiàng)目剩余時(shí)間，紅色號碼?是到目前為止所花的時(shí)間與剩余時(shí)間之和的曲線。到了2010年3月21日得到了上面的這個(gè)圖。到了這，我們發(fā)現(xiàn)原本估計(jì)的3480總小時(shí)數(shù)是低估了，更可能的是?所示的3740小時(shí)。

  以縱軸的性質(zhì)區(qū)分，燃盡圖可以分為兩大類，即縱軸可以是時(shí)間或是事件。以范圍區(qū)分，燃盡圖至少可以分為三類：項(xiàng)目級的、任務(wù)級的和需求級的。透過燃盡圖，我們可以看到項(xiàng)目進(jìn)行的情況，項(xiàng)目需求是否按計(jì)劃進(jìn)入開發(fā)流程，工作是否有延時(shí)，或者工作安排的飽和度是否適合。如上圖所示，我們可以輕易地看到，照著現(xiàn)在的進(jìn)度，這項(xiàng)目可能會延期6到7工作天。當(dāng)高層看到這圖時(shí)，可以在資源上做調(diào)動，以避免延期產(chǎn)生的不良后果。

  我們刻意使用了這個(gè)較理想的圖做講解，為的是讓讀者更容易理解。它不是個(gè)典型的圖。在大多情況，使用燃盡圖會是比較復(fù)雜的，因?yàn)樗赡馨诵枨笏鸭⒕幊、單元測試、集成測試和缺陷修復(fù)，并且還可能有迭代。所以估算時(shí)間會較困難。這個(gè)燃盡圖的過程是比較穩(wěn)定的，結(jié)果是比較理想的，其原因至少有二：（一）項(xiàng)目里單純地只有編程、單元測試和缺陷修復(fù)任務(wù)，全都由程序員搞定；它里頭沒有需求搜集、集成測試或其他任務(wù)。（二）這個(gè)項(xiàng)目復(fù)雜度低，約一半的編碼任務(wù)是機(jī)械性的，所以估出來的時(shí)間較為準(zhǔn)確。

  （2） 固化工作流以管控過程

  對于公司里既定的流程，我們在DevSuite里以圖形化的工作流將其固化。下圖是以前面王總監(jiān)提到的需求變更流程設(shè)計(jì)出來的。

  這工作流指明了，在一個(gè)變更事件被創(chuàng)建后，它需要經(jīng)過一個(gè)《評審》狀態(tài)。在評審階段里，有三個(gè)人（A，B和C）要全部同意，才能到達(dá)《通過》狀態(tài)。有任何一人不同意，狀態(tài)轉(zhuǎn)到《拒絕》。當(dāng)一到達(dá)《評審》狀態(tài)，系統(tǒng)馬上促發(fā)郵件和手機(jī)通知，將信息寄給A，B和C。系統(tǒng)可以預(yù)先設(shè)定這三人有兩天的時(shí)間評審該變更。假如兩天過了，狀態(tài)仍為《評審》，那是有人未及時(shí)處理該事件。這時(shí)候，系統(tǒng)會自動將事件升級，把狀態(tài)轉(zhuǎn)換為《升級處理》，系統(tǒng)馬上促發(fā)郵件，將信息寄給研發(fā)部王總監(jiān)。王總監(jiān)可以斟酌情況，做妥善的處理。
 

  使用固化的工作流至少有四個(gè)優(yōu)點(diǎn)：1）提高通知效率 ?郵件和手機(jī)自動通知提高效率，溝通出錯(cuò)的機(jī)會減少了；2）避免流程出錯(cuò) ?DevSuite的工作流將流程完全自動化，每個(gè)人在收到郵件或短信通知時(shí)，照著工作流中既定的步驟操作行了，省心又省力； 3）工作流變動時(shí)處理很容易 ?當(dāng)流程或人員變動時(shí)，系統(tǒng)配置員可以輕易地花幾分鐘做完調(diào)整，之后所有團(tuán)隊(duì)成員照著流程走便行了；4）避免摩擦?人是有情緒的，固化的工作流使得操作完全對事不對人，避免了人和人之間不必要的摩擦。

  以上提到的軟件項(xiàng)目風(fēng)險(xiǎn)實(shí)例幾乎在每個(gè)項(xiàng)目中都出現(xiàn)，而且，它們造成的損失也是嚴(yán)重的。所幸，從實(shí)際操作中，我們發(fā)現(xiàn)處理它們的成本并不高：1）培訓(xùn)團(tuán)隊(duì)成員照工作流中既定的步驟操作，學(xué)會填寫任務(wù)花費(fèi)時(shí)間和任務(wù)所剩時(shí)間，并理解意圖，所花時(shí)間不超過1小時(shí)，2）系統(tǒng)配置員要了解需求，設(shè)計(jì)工作流，并設(shè)置人員（如例子中的A、B、C和走流程的人）的權(quán)限等，所花費(fèi)時(shí)間在1到3天之間，也算合理，3）以往當(dāng)團(tuán)隊(duì)人員或評審流程有變動，管理人員要更改文檔并向所有人宣布；現(xiàn)系統(tǒng)配置員只要花幾分鐘改系統(tǒng)配置，一切緒了。

  小結(jié)

  這并不是一個(gè)全方位的風(fēng)險(xiǎn)管控系統(tǒng)；相反的，它是個(gè)相當(dāng)簡化，只對關(guān)鍵點(diǎn)作處理的系統(tǒng)。雖然只是做在關(guān)鍵點(diǎn)上，但效果卻十分明顯。拿需求變更來說，需求變更一直都是項(xiàng)目中讓人恨得牙癢癢的瘤。既然需求變更是不可避免，那我們所能做的是，盡可能減少變更的次數(shù)，降低變更造成的沖擊。以往大多數(shù)人審核需求變更時(shí)較為草率，導(dǎo)致同一個(gè)功能點(diǎn)變了又變。在一輪又一輪的返工后，程序員和測試人員會產(chǎn)生倦怠感，編碼和測試的質(zhì)量一再下降。使用了DevSuite后，所有的操作都在系統(tǒng)里留下記錄，這統(tǒng)計(jì)在年終時(shí)可以作為考評的參考材料。自然而然地，審核人員很嚴(yán)謹(jǐn)?shù)貙徍嗣恳粋(gè)需求變更。而且，因?yàn)橄到y(tǒng)設(shè)置了每人只有兩天的時(shí)間處理，審核人員處理需求變更時(shí)不僅是快，而且較仔細(xì)。單單這個(gè)變化，使得整個(gè)團(tuán)隊(duì)的氣象煥然一新。

  在系統(tǒng)實(shí)施后半年，我們做了客戶回訪，我劈頭問王總監(jiān)，說的那位產(chǎn)品經(jīng)理還跟項(xiàng)目經(jīng)理還吵架嗎？瞪了我一眼，停了一下，然后皺了皺眉頭說：倒是不吵架了。他們倆現(xiàn)在成了好朋友，聯(lián)合起來一起對付我了。他自己呵呵呵地笑了起來