軟件項目的風險管理詳解

我是一名計算機軟件開發人員。我精通多種編程語言。我熱愛這份工作，設計程序、編程、調bug、解決問題……這一切讓我覺得很興奮、很有成就感。我愿意學新東西，解決一個又一個技術難題——這讓我覺得自己是一個“有用的人”。

“我喜歡我的同伴們，他們是一群很棒的人，我們談得來，技術上的事兒我們總能一起找到辦法。”

“但是項目是另外一回事兒，有時候真的讓人很惱火，我們團隊只有3個人，卻干著6個人的活兒！”

“我們只有1臺調試機，幾個團隊都要用，每天因為爭用調試機打架。”

“忙死了，還要帶一幫新人干活，他們什么都不會，光添亂！他們要是早一點兒來我還有時間帶他們，現在？算了，我還是加班自己來吧。”

“早干嘛去了，這時候才說要改架構，我們開發都進行一半了！”

“這活兒真沒法兒干，客戶干嘛總是來指手畫腳啊，打亂我們的計劃了。”

“我在公司接受了3個月的培訓，現在正式加入這個項目了。項目很大，任務很重，據說對公司的前途至關重要，我很興奮。前輩們很有經驗，也很忙，我也想做點兒什么，但是他們好像不太歡迎我加入，有點兒沮喪”。

如果你是一名軟件開發者（或任何需要團隊合作的工作參與者），上面的話是不是感覺很熟悉？每個人都有干勁兒，大家目標也一致，但是總是有這樣那樣的問題使我們無法專注于自己的“本職”工作。

問題，問題，那么多的問題！雖然說解決難題能帶來成就感，但是相信我，當意料之外的問題組團出現的時候，它們帶來的只能是混亂！更糟糕的是，火氣、喪氣、疲憊感也一起來湊熱鬧。對于項目，尤其是大項目來講，這可不是個好現象。

好吧，讓我們靜下來，想一想，那些問題在成為問題之前，我們真的一點兒都沒預料過么？如果能預料的話，是否能夠提前做些什么來避免，或者減輕問題的破壞力？退一步講，最起碼讓人喘口氣，問題別一起出現！要達到上述目的，用一個術語化的說法，就是進行“風險管理”。

通俗的說，風險就是“問題發生的可能性”。所謂問題，就是之前我們提到的各種各樣的不希望發生的“鬧心事兒”。

風險管理的主要任務是：在問題發生之前，識別它、評估它、做對策，降低其發生的可能性和發生時的危害程度；然后，在對策的實施過程中，進行定期跟蹤、再評估、調整對策，以確保問題是可控的，直到安全解決。

風險管理

綜上所述，風險管理主要體現在下面幾方面：

● 風險識別：找到可能發生問題的地方

● 風險評估：是哪類問題、發生的可能性、發生后的影響度以及危險等級

● 風險對策：什么時間、做哪些工作、能降低風險發生的可能性還是發生后的影響

● 風險跟蹤：可能性的變化、影響度的變化、危險等級的變化、風險對策是否需要調整、是否引起新的風險等等

風險管理是軟件項目整個生命周期中的常規工作。在項目策劃、項目范圍變更、項目計劃變更、定期項目跟蹤時，都要進行風險管理。

風險識別

在軟件開發項目中，要識別風險，一個基本方法是“模擬法”——用現有的人員、技術、資源（設備、能夠得到的支持等），在項目開始的時點上，審視現有流程上的每一個步驟，思考并預測將會遇到什么問題。這項工作將使我們得到一份風險描述的列表。

對風險列表中的風險進行“合并同類項”處理，尤其是當一個項目涉及到多個團隊、較多人，不同的團隊和個人提出與他們相關的風險的時候，這種“合并同類項”的處理就顯得尤為重要。它可以保證資源的統一調配，最大限度復用，避免各自為政造成的浪費。

風險評估

對風險進行深入的評價，主要分析風險的種類、可能性和影響。

● 風險的種類

一般來講，所有的風險都可以歸結到軟件項目的幾個要素上去。現在，我們首先來提取這些要素。

什么是項目？通俗的講就是：在特定的時間內、特定的成本下、完成特定的工作，成果物要質量達標，令用戶滿意。所以說，項目有下面幾個關鍵的維度：

○ 進度：在什么時間完成

○ 成本：花費多少代價

○ 范圍：做什么，做到什么程度

○ 質量：成果物的質量屬性（例如千行代碼bug數、安全運行天數）

○ 客戶滿意度：令客戶滿意

所謂風險的種類，在軟件項目中，通常指上述維度的某一個。當然，從市場及企業經營的級別來看，會有另外一套關于種類的定義標準，這里不做深入討論。

● 可能性：這個風險演變成問題的可能性有多少

● 影響：這個風險演變成問題的話，其破壞力有多大

● 風險級別：根據風險演變成問題的可能性和影響度，形成各風險評級。風險級別越高，越應該得到管理者的重視

下表列舉了風險評級的方法(表1)：

首先，量化描述可能性及影響度，然后把風險放到矩陣中的相應位置上，最后根據風險所處的區域，判斷是S、A、B、C的哪一個級別。

S級：影響大、發生的可能性大。這樣的風險必須進行處理，一定要制定對策降低風險或者規避風險。

A級：影響度在中等程度以上，發生的可能性比較大，或者影響度雖然小，但是發生可能性很高。這樣的風險也應該進行處理，制定相應的對策來降低或者規避風險。

B級：影響大，但是發生概率很低。這樣的風險不應該消耗太多的管理成本，不必專門制定對策，只需做定期跟蹤。

C級：影響小且發生概率低。這樣的風險可以暫時不納入管理體系。

需要注意的是，不同的領域、不同的項目，對風險的影響度和發生可能性的量化標準是不一樣的。對風險的容忍度，也就是SABC的判定標準也是不一樣的。例如：同樣是“發生幾率為萬分之一的‘死機’”這樣的風險。在某些日用消費品中，是完全可以接受的，可以列為C級風險，不予關注。但是在航天項目中，則是絕對不能容忍的，必須以S級來處理。

所以說，任何一個項目都需要為自己量身定做風險判斷基準。甚至需要在項目外、組織級進行定義。在組織級定義項目風險判斷基準的好處是：同一個組織內，為風險制定統一的量化標準，則不同項目的風險之間具有可比性，為管理和決策提供依據。

因為風險評估對后期的決策有很重要的影響，所以，為慎重起見，有些評估會經與相關人員一起進行幾輪的討論，才能最后確定下來。

風險對策

根據風險評估中得出的風險級別，優先處理S、A級別的風險，并為每一個風險制定專門的對策。

在制定風險對策的時候，我們會發現，風險是可以“轉移”的。不同的風險，根據對策的不同可能在屬性上有所轉移，可能對原有的風險造成影響，也可能會帶來新的風險。

下表是對一個風險的識別、評估和對策(表2):

上述對策會降低原有的風險，但是同時會增加一個新的風險，如下(表3)所示：

上述對策就是一個典型的用“成本”換“日程”的例子。如果對策獲得認可，就會對開發計劃等其他方面造成影響，所有受到影響的部分，在分析影響范圍的時候，也要再次回顧已經識別的風險是否會因為這個變化而變化。

在為風險制定對策的時候，需要掌握一個原則：控制風險水平、分散重大風險。

每一個風險都是一個不確定因素，是定時炸彈，盡量不要把太多的炸彈尤其是大炸彈集中在一個階段解決。分散處理的話，萬一問題爆發，控制起來也相對容易一些。

多數情況下風險的對策都不是唯一的，雖然對策本身可能也會帶來風險，但是要盡量均衡的考慮對策本身對項目的影響。盡量讓項目總的風險水平處于平穩，避免過大的波峰。

如圖1所示，文章開頭所述的一團糟的情況，可能就是對風險沒有事先的管理和干預，導致集中爆發或者風險過高，從而給項目整體帶來不良的影響。更糟糕的是，打一場沒有準備的仗，我們輸掉戰爭的同時也輸掉了士氣和信心。

如果有事先的管理和干預，項目的風險將會被控制在一個相對穩定的水平，管理起來會容易很多，如圖表2所示。即使最后問題還是發生了，但是最起碼之前大家對此有預期，知道會發生什么，對團隊情緒方面的影響也會小很多。(圖1、2)

風險跟蹤

我們為項目識別了風險，評估了風險的級別，為重要風險制定了對策，在這些工作之后，還需要對風險進行跟蹤。

一般在項目進行周報、月報的時候，要同時進行風險的跟蹤和報告。

對風險的跟蹤主要集中在以下幾個方面：

● 對策跟蹤：對策是否按照計劃實施了，實施過程中是否有新的風險出現（這里又是一個風險識別的過程）

● 可能性：隨著時間的推移或對策的實施，這個風險演變成問題的可能性有什么變化

● 影響：隨著時間的推移或對策的實施，這個風險演變成問題的話，問題的破壞力有多大

● 級別：隨著可能性和影響的變化，級別也會隨之變化

● 風險狀態：如果風險級別已經變得很低，不需要再繼續處理的話，則關閉這個風險，以后不再跟蹤

● 調整風險對策：判斷是否需要調整對策方案，如何調整——調整的過程又涉及到新的風險識別活動

在進行風險跟蹤的時候，需要注意的是：并非所有的變化都是我們的對策在起作用，有時候可能是市場變化，也可能是客戶要求的變化，或者是其他外部環境的變化，讓原本的可能性及影響度發生變化。

管理好風險，把項目做出節奏感

風險管理是項目管理的重要組成部分。

作為軟件開發的技術人員，通常我們是相信技術的力量的，我們享受解決問題所帶來的成就感。對于企業或者組織來講，團隊成員的這種成就感是最“物美價廉”的激勵，它能夠讓項目成功的同時，讓每個人都很快樂，讓隊伍快速成長。

做好風險管理，能夠讓所有的團隊成員清楚的看到，我們在什么時候會面臨什么樣的挑戰，為了以合理的代價達成目的，我們需要在哪些時候、做些什么。

這就好像有一個看不見的敵人，在我們的路上設置了一個又一個地雷，不懷好意的等著看我們被炸得雞飛狗跳、氣急敗壞。哪知我們早有準備，雖然緊張但卻興奮地一個一個干掉它！我們跳躍著、踩著既定的節奏，到達了目的地！我們甚至可以輕松的回過頭說，雖然有點兒麻煩，但只是小case。