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

  一個案例

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

  （1） 需求風險 ——對需求理解不夠透徹或需求變更頻繁；

  （2） 人員風險 ——人員生病或離職，一時無法找到替代者；

  （3） 技術(shù)風險 ——某個關(guān)鍵的技術(shù)問題無法快速攻克；

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

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

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

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

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

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

  兩個控制風險的原則

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

  （1） 提高項目的可視性

  不論是哪一種風險，其后沖擊的基本上是項目本身，延期是常見的結(jié)果。如果是對可能發(fā)生的風險都一一進行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對項目延期有效的解決辦法，因為它很大程度地提高了項目的可視性。在實際操作時，我們讓團隊成員每天對其參與的每一任務(wù)都鍵入下列兩項數(shù)字：1）該任務(wù)花費時間，和2）該任務(wù)所剩時間。結(jié)果會生了類似如下的燃盡圖。