IT項目管理從某個意義上來說，就是風險管理。從理論上講風險管理可以分為三個部分：風險識別、風險分析和風險解決。 傳統(tǒng)的風險管理系統(tǒng)只能幫我們較正規(guī)地統(tǒng)計和管理風險，這些系統(tǒng)本身是不能規(guī)避或解決任何風險的。在實際操作上，由于可能發(fā)生風險的種類很多，處理起來所耗費的人力物力也相當可觀。在下列的案例中，我們建議的不是一套昂貴而且全面的風險管理系統(tǒng)，而是一套扼住最關鍵部位，高效且低成本，適合于千萬中小企業(yè)的小型解決方案。
一個案例
在2009年某家在北京海淀區(qū)的嵌入式產品公司跟我們討論項目管理時，該公司的王總監(jiān)跟我們做了以下溝通。他們項目風險種類可以概略分為四類：
（1）需求風險 ——對需求理解不夠透徹或需求變更頻繁；
（2）人員風險 ——人員生病或離職，一時無法找到替代者；
（3）技術風險 ——某個關鍵的技術問題無法快速攻克；
（4）管理風險 ——管理人員協(xié)調能力和執(zhí)行力能力不足，計劃偏差，流程更改和溝通不良等。
這些風險的發(fā)生導致的結果就是項目延期和成本大幅攀升。無法有效處理這些風險的兩個最大問題在于：
（1）對風險的反應遲鈍 ——常常是太晚發(fā)現問題，以至于無法彌補或是彌補成本太大；
（2）對過程難以掌控 ——雖已有既定的流程，但由于人員變動、流程變動、系統(tǒng)出錯等問題，很難照著走。
為了讓我們更理解，王總監(jiān)很生動的解釋了以上兩個問題。對風險反應遲鈍的問題，他說，在做項目計劃時為求實際，總會多估個20%到40%的時間。如果項目需求清晰，或是團隊做過類似項目，就用20%或多些；如果是新項目，或風險因素多便用30%到40%。所以，當某些風險（如，需求變更或人員變動）發(fā)生了，一般也未必馬上就造成項目延期。可是，如果風險發(fā)生量繼續(xù)增加，或是某一兩個風險產生較嚴重的沖擊，在某個時刻就會過了臨界點。難的地方就是項目大人員多，就是連項目經理也是見樹不見林。
對過程難以掌控的問題，王總監(jiān)舉了個例子。公司的研發(fā)制度里規(guī)定，為保證需求的準確性，一個需求的變更要經過（1）該項目經理，（2）一位資深程序員，和（3）該產品經理，等三個關鍵人審核后才可以進行更改。王總監(jiān)說：需求變更的過程在邏輯上看似簡單，但在實際操作時卻不斷地發(fā)生問題。舉例來說，內部溝通主要是以郵件通知的方式進行，需求變更的文檔寄來寄去，版本很多，而且郵件總是遺失。另有一次更嚴重，產品經理因為休假，沒能及時查郵件。在等了兩天后，因怕誤了工期，項目經理便越權要求程序員把代碼寫了。不巧，產品經理對這需求的更改有他強烈的意見。當他看到在沒得到他的同意下就把代碼寫了，火冒三丈，直接在會議中就和項目經理吵了起來。
兩個控制風險的原則
雖然風險總是發(fā)生，但就如同大多數的公司一樣，該公司也不愿意花費太多的精力和時間在這風險管控上，所以在尋求一個低成本又高效的管控方法。王總監(jiān)和我們在研討后，使用工具DevSuite基于下列兩個原則做了處理。（為避免篇幅太大，以下我們僅把最精彩的點列出來。）
（1）提高項目的可視性
不論是哪一種風險，其最后沖擊的基本上就是項目本身，延期是最常見的結果。如果是對可能發(fā)生的風險都一一進行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對項目延期最有效的解決辦法，因為它很大程度地提高了項目的可視性。在實際操作時，我們讓團隊成員每天對其參與的每一任務都鍵入下列兩項數字：1）該任務花費時間，和2）該任務所剩時間。結果就會生了類似如下的燃盡圖。
如圖所示，起初這項目被估計是要3480小時完成。大致上來說，一般的研發(fā)團隊因著人員請假、會議和其他突發(fā)事情，平均每人每天只能有六小時花在實際項目工作上。現這項目有七個人參與，估算出來大約需要四個月完成。（也就是從2009年11月29日到2010年3月29日，圖中紅色直立線為起始線，藍色直立線為終止線。）這圖里共有三條曲線。紅色號碼?/span>表示到現在為止在該項目的總花費時間，紅色號碼?表示估算的項目剩余時間，紅色號碼?是到目前為止所花的時間與剩余時間之和的曲線。到了2010年3月21日就得到了上面的這個圖。到了這一天，我們發(fā)現原本估計的3480總小時數是低估了，更可能的是?所示的3740小時。
以縱軸的性質區(qū)分，燃盡圖可以分為兩大類，即縱軸可以是時間或是事件。以范圍區(qū)分，燃盡圖至少可以分為三類：項目級的、任務級的和需求級的。透過燃盡圖，我們可以看到項目進行的情況，項目需求是否按計劃進入開發(fā)流程，工作是否有延時，或者工作安排的飽和度是否適合。如上圖所示，我們可以輕易地看到，照著現在的進度，這項目最可能會延期6到7工作天。當高層看到這圖時，就可以在資源上做調動，以避免延期產生的不良后果。
我們刻意使用了這個較理想的圖做講解，為的是讓讀者更容易理解。它不是個典型的圖。在大多情況，使用燃盡圖會是比較復雜的，因為它可能包含了需求搜集、編程、單元測試、集成測試和缺陷修復，并且還可能有迭代。所以估算時間會較困難。這個燃盡圖的過程是比較穩(wěn)定的，結果是比較理想的，其原因至少有二：（一）項目里單純地只有編程、單元測試和缺陷修復任務，全都由程序員搞定；它里頭沒有需求搜集、集成測試或其他任務。（二）這個項目復雜度低，約一半的編碼任務是機械性的，所以估出來的時間較為準確。
（2）固化工作流以管控過程
對于公司里既定的流程，我們在DevSuite里以圖形化的工作流將其固化。下圖就是以前面王總監(jiān)提到的需求變更流程設計出來的。
這工作流指明了，在一個變更事件被創(chuàng)建后，它需要經過一個《評審》狀態(tài)。在評審階段里，有三個人（A，B和C）要全部同意，才能到達《通過》狀態(tài)。有任何一人不同意，狀態(tài)就轉到《拒絕》。當一到達《評審》狀態(tài)，系統(tǒng)馬上促發(fā)郵件和手機通知，將信息寄給A，B和C。系統(tǒng)可以預先設定這三人有兩天的時間評審該變更。假如兩天過了，狀態(tài)仍為《評審》，那就是有人未及時處理該事件。這時候，系統(tǒng)會自動將事件升級，把狀態(tài)轉換為《升級處理》，系統(tǒng)馬上促發(fā)郵件，將信息寄給研發(fā)部王總監(jiān)。王總監(jiān)可以斟酌情況，做最妥善的處理。
使用固化的工作流至少有四個優(yōu)點：1）提高通知效率 ？郵件和手機自動通知提高效率，溝通出錯的機會減少了；2）避免流程出錯 ？DevSuite的工作流將流程完全自動化，每個人在收到郵件或短信通知時，照著工作流中既定的步驟操作就行了，省心又省力； 3）工作流變動時處理很容易 ？當流程或人員變動時，系統(tǒng)配置員可以輕易地花幾分鐘就做完調整，之后所有團隊成員就照著流程走便行了；4）避免摩擦？人是有情緒的，固化的工作流使得操作完全對事不對人，避免了人和人之間不必要的摩擦。
以上提到的軟件項目風險實例幾乎在每個項目中都出現，而且，它們造成的損失也是嚴重的。所幸，從實際操作中，我們發(fā)現處理它們的成本并不高：1）培訓團隊成員照工作流中既定的步驟操作，學會填寫任務花費時間和任務所剩時間，并理解意圖，所花時間不超過1小時，2）系統(tǒng)配置員要了解需求，設計工作流，并設置人員（如例子中的A、B、C和走流程的人）的權限等，所花費時間在1到3天之間，也算合理，3）以往當團隊人員或評審流程有變動，管理人員要更改文檔并向所有人宣布；現系統(tǒng)配置員只要花幾分鐘改系統(tǒng)配置，一切就就緒了。
小結
這并不是一個全方位的風險管控系統(tǒng)；相反的，它是個相當簡化，只對關鍵點作處理的系統(tǒng)。雖然只是做在關鍵點上，但效果卻十分明顯。就拿需求變更來說，需求變更一直都是項目中讓人恨得牙癢癢的瘤。既然需求變更是不可避免，那我們所能做的就是，盡可能減少變更的次數，降低變更造成的沖擊。以往大多數人審核需求變更時較為草率，導致同一個功能點變了又變。在一輪又一輪的返工后，程序員和測試人員會產生倦怠感，編碼和測試的質量一再下降。使用了DevSuite后，所有的操作都在系統(tǒng)里留下記錄，這統(tǒng)計在年終時可以作為考評的參考材料。自然而然地，審核人員就很嚴謹地審核每一個需求變更。而且，因為系統(tǒng)設置了每人只有兩天的時間處理，審核人員處理需求變更時不僅是快，而且較仔細。單單就這個變化，就使得整個團隊的氣象煥然一新。
在系統(tǒng)實施后半年，我們做了客戶回訪，我劈頭就問王總監(jiān)，說的那位產品經理還跟項目經理還吵架嗎？瞪了我一眼，停了一下，然后皺了皺眉頭說：倒是不吵架了。他們倆現在成了好朋友，聯(lián)合起來一起對付我了。他自己呵呵呵地笑了起來