軟體專案管理中的風險管理像是把瑞士軍刀，高效全能。它是項目全面管理的一部分，風險管理應該與關鍵的項目實施過程緊密相連，貫穿項目始終。
風險管理風險管理工具只是輔助，關鍵是在項目中要有風險意識。我們習慣於處理問題(issue)，但卻疏於應對風險(risk)。關於風險和問題如何區別的討論，不單在國內，在國外也一直沒有定論，在英文兩者都是problem。一般認為問題(issue)是已經存在的，而風險(risk)則是一種可能性的度量。它包含著不確定性。
風險的兩個要素：1.發生的可能性 2.如果發生所帶來的事果的嚴重程度。風險管理有一套方法論和工具，識別、定性分析、定量分析、應對，以及監控。咱們推崇實用主義，能解決現實問題就行。
風險管理的痛點就是識別，包括區分問題和風險。在一個軟體項目有天然的樂觀者，也有天然的悲觀者。比如測試人員常對開發人員說的:怎麼能讓我們放心呢？項目中每個涉眾對不確定的看法不同、容忍度不同，所以風險識別是必須的管理活動。而管理的目的就是提高風險識別的有效性。
風險識別在實踐中常用開會和訪談的形式來識別風險，效果各不相同。主要有以下可能的問題: .
識別過程缺少引導。從哪些方面入手？從哪些方向展開？ .
人的因素。 獨立性、經驗及對待風險的態度不同等。
Dr. Kerzner在他的<<專案管理>>中做出總結。他提到依據風險來源來識別風險，大部分的風險分為主觀和客觀兩類：
1. 客觀性風險來源 (經驗) 典型的客觀性風險來源有: 。 檔案記錄的經驗教訓 。 項目評估資料 (QA人員統計和稽核的資料) 。 運營資料
2. 主觀性風險來源 (專家經驗) 舉例來說，常常出現在項目會議，如果開發人員給出一個樂觀的評估後，可能有人就會引用之前某個項目的教訓。 經驗類的風險沒有管理好，就會出現項目越做越小心，緩衝時間越拉越長的問題。
由此可見風險識別的方法有:
1. 借簽以前的風險管理資料
2. 專家判斷 (Delphi法和頭腦風暴)
3. 基於WBS或專案工作列表進行分解
4. 基於項目需求中較難實現的部分。
個人覺得實踐中由項目列表分解和頭腦風暴來識別風險是很有價值的方法，既可以培養團隊的風險意識，又可以廣泛收集風險項目。收集到足夠的風險項目，才能做出來準確的分析，才能給出優先順序，保證解決真正的風險。
風險的有效識別常常能為項目帶來新的突破口，因為風險總是與機會相對。之前就有被臨時安排到一個面臨高風險的項目的經曆，也全靠風險管理才化險為夷。首先要做的就是重新梳理出現存在的問題和風險(這是兩個不同的概念，但是管理時要一起考慮。已經發生的問題並不一定是高優先順序事務)，然後分析後識別出最高優先順序的風險(紅色項目)和次要風險(黃色項目), 再對應設定應對策略。將風險應對活動和現有的開發活動一起評估，定義出高優先事務和必要的人員調整方案。每天Review風險矩陣，按需要再調整風險層級和應對策略。在這樣高強度的管理之下，項目風險最終被順利排除。
前面也提到風險管理是一項全面管理活動，在管理過程一定要有全域思維，一個問題點可能是溝通問題、可能是成本問題、也可能是需求問題、也可能是人事問題，但最終都是專案經理的問題。
轉載請註明出處:
http://blog.csdn.net/horkychen
