IT項(xiàng)目管理從某個(gè)意義上來(lái)說(shuō)，就是風(fēng)險(xiǎn)管理。從理論上講風(fēng)險(xiǎn)管理可以分為三個(gè)部分：風(fēng)險(xiǎn)識(shí)別、風(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)的種類很多，處理起來(lái)所耗費(fèi)的人力物力也相當(dāng)可觀。在下列的案例中，我們建議的不是一套昂貴而且全面的風(fēng)險(xiǎn)管理系統(tǒng)，而是一套扼住最關(guān)鍵部位，高效且低成本，適合于千萬(wàn)中小企業(yè)的小型解決方案。
一個(gè)案例
在2009年某家在北京海淀區(qū)的嵌入式產(chǎn)品公司跟我們討論項(xiàng)目管理時(shí)，該公司的王總監(jiān)跟我們做了以下溝通。他們項(xiàng)目風(fēng)險(xiǎn)種類可以概略分為四類：
（1） 需求風(fēng)險(xiǎn) ——對(duì)需求理解不夠透徹或需求變更頻繁；
（2） 人員風(fēng)險(xiǎn) ——人員生病或離職，一時(shí)無(wú)法找到替代者；
（3） 技術(shù)風(fēng)險(xiǎn) ——某個(gè)關(guān)鍵的技術(shù)問(wèn)題無(wú)法快速攻克；
（4） 管理風(fēng)險(xiǎn) ——管理人員協(xié)調(diào)能力和執(zhí)行力能力不足，計(jì)劃偏差，流程更改和溝通不良等。
這些風(fēng)險(xiǎn)的發(fā)生導(dǎo)致的結(jié)果就是項(xiàng)目延期和成本大幅攀升。無(wú)法有效處理這些風(fēng)險(xiǎn)的兩個(gè)最大問(wèn)題在于：
（1）對(duì)風(fēng)險(xiǎn)的反應(yīng)遲鈍 ——常常是太晚發(fā)現(xiàn)問(wèn)題，以至于無(wú)法彌補(bǔ)或是彌補(bǔ)成本太大；
（2） 對(duì)過(guò)程難以掌控 ——雖已有既定的流程，但由于人員變動(dòng)、流程變動(dòng)、系統(tǒng)出錯(cuò)等問(wèn)題，很難照著走。
為了讓我們更理解，王總監(jiān)很生動(dòng)的解釋了以上兩個(gè)問(wèn)題。對(duì)風(fēng)險(xiǎn)反應(yīng)遲鈍的問(wèn)題，他說(shuō)，在做項(xiàng)目計(jì)劃時(shí)為求實(shí)際，總會(huì)多估個(gè)20%到40%的時(shí)間。如果項(xiàng)目需求清晰，或是團(tuán)隊(duì)做過(guò)類似項(xiàng)目，就用20%或多些；如果是新項(xiàng)目，或風(fēng)險(xiǎn)因素多便用30%到40%。所以，當(dāng)某些風(fēng)險(xiǎn)（如，需求變更或人員變動(dòng)）發(fā)生了，一般也未必馬上就造成項(xiàng)目延期?？墒?，如果風(fēng)險(xiǎn)發(fā)生量繼續(xù)增加，或是某一兩個(gè)風(fēng)險(xiǎn)產(chǎn)生較嚴(yán)重的沖擊，在某個(gè)時(shí)刻就會(huì)過(guò)了臨界點(diǎn)。難的地方就是項(xiàng)目大人員多，就是連項(xiàng)目經(jīng)理也是見(jiàn)樹(shù)不見(jiàn)林。
對(duì)過(guò)程難以掌控的問(wèn)題，王總監(jiān)舉了個(gè)例子。公司的研發(fā)制度里規(guī)定，為保證需求的準(zhǔn)確性，一個(gè)需求的變更要經(jīng)過(guò)（1）該項(xiàng)目經(jīng)理，（2）一位資深程序員，和（3）該產(chǎn)品經(jīng)理，等三個(gè)關(guān)鍵人審核后才可以進(jìn)行更改。王總監(jiān)說(shuō)：需求變更的過(guò)程在邏輯上看似簡(jiǎn)單，但在實(shí)際操作時(shí)卻不斷地發(fā)生問(wèn)題。舉例來(lái)說(shuō)，內(nèi)部溝通主要是以郵件通知的方式進(jìn)行，需求變更的文檔寄來(lái)寄去，版本很多，而且郵件總是遺失。另有一次更嚴(yán)重，產(chǎn)品經(jīng)理因?yàn)樾菁?，沒(méi)能及時(shí)查郵件。在等了兩天后，因怕誤了工期，項(xiàng)目經(jīng)理便越權(quán)要求程序員把代碼寫了。不巧，產(chǎn)品經(jīng)理對(duì)這需求的更改有他強(qiáng)烈的意見(jiàn)。當(dāng)他看到在沒(méi)得到他的同意下就把代碼寫了，火冒三丈，直接在會(huì)議中就和項(xiàng)目經(jīng)理吵了起來(lái)。
兩個(gè)控制風(fēng)險(xiǎn)的原則
雖然風(fēng)險(xiǎn)總是發(fā)生，但就如同大多數(shù)的公司一樣，該公司也不愿意花費(fèi)太多的精力和時(shí)間在這風(fēng)險(xiǎn)管控上，所以在尋求一個(gè)低成本又高效的管控方法。王總監(jiān)和我們?cè)谘杏懞?，使用工具DevSuite基于下列兩個(gè)原則做了處理。（為避免篇幅太大，以下我們僅把最精彩的點(diǎn)列出來(lái)。）
（1） 提高項(xiàng)目的可視性
不論是哪一種風(fēng)險(xiǎn)，其最后沖擊的基本上就是項(xiàng)目本身，延期是最常見(jiàn)的結(jié)果。如果是對(duì)可能發(fā)生的風(fēng)險(xiǎn)都一一進(jìn)行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對(duì)項(xiàng)目延期最有效的解決辦法，因?yàn)樗艽蟪潭鹊靥岣吡隧?xiàng)目的可視