軟體項目風險管理

1 前言
　　一般來說，軟體工程師總是非常樂觀。當他們在計劃軟體項目時，經常認為每件事情都會像計劃那樣運行，或者，又會走向另外一個極端。軟體開發的創造性本質意味著我們不能完全預測會發生的事情，因此制定一個詳細計劃的關鍵點很難確定。當有預想不到的事情引起項目脫離正常軌道時，以上兩種觀點都會導致軟體項目的失敗。
　　目前，風險管理被認為是IT軟體項目中減少失敗的一種重要手段。當不能很確定地預測將來事情的時候，可以採用結構化風險管理來發現計劃中的缺陷，並且採取行動來減少潛在問題發生的可能性和影響。風險管理意味著危機還沒有發生之前就對它進行處理。這就提高了項目成功的機會和減少了不可避免風險所產生的後果。 
2 什麼是風險
　　所謂“風險”，歸納起來主要有兩種意見，主觀說認為，風險是損失的不確定性；客觀學認為，風險是給定情況下一定時期可能發生的各種結果間的差異。它的兩個基本特徵是不確定性和損失。IT行業中的軟體項目開發是一項可能損失的活動，不管開發過程如何進行都有可能超出預算或時間延遲。項目開發的方式很少能保證開發工作一定成功，都要冒一定的風險，也就需要進行項目風險分析。在進行項目風險分析時，重要的是要量化不確定的程度和每個風險相當的損失程度，為實現這一點就必須要考慮以下問題：
　　要考慮未來，什麼樣的風險會導致軟體項目失敗？
　　要考慮變化，在使用者需求、開發技術、目標、機制及其它與項目有關的因素的改變將會對按時交付和系統成功產生什麼影響？
　　必須解決選擇問題，應採用什麼方法和工具，應配備多少人力，在品質上強調到什麼程度才滿足要求？
　　要考慮風險類型，是屬於項目風險、技術風險、商業風險、管理風險還是預算風險等？
　　這些潛在的問題可能會對軟體項目的計劃、成本、技術、產品的品質及團隊計程車氣都有負面的影響。風險管理就是在這些潛在的問題對項目造成破壞之前識別、處理和排除。
3 風險管理
　　項目風險管理實際上就是貫穿在項目開發過程中的一系列管理步驟，其中包括風險識別、風險估計、風險管理策略、風險解決和風險監控。它能讓風險管理者主動“攻擊”風險，進行有效風險管理。
　　在專案管理中，建立風險管理策略和在項目的生命週期中不斷控制風險是非常重要的，風險管理包括四個相關階段：
　　風險識別 識別風險的方法常用的有風險識別問詢法（座談法、專家法）、財務報表法、流程圖法、現場觀察法、相關部門配合法和環境分析法等。
　　風險評估 對已識別的風險要進行估計和評價，風險估計的主要任務是確定風險發生的機率與後果，風險評價則是確定該風險的經濟意義及處理的費/效分析，常用的方法有：機率分布、外推法、多目標分析法等。
　　風險處理 一般而言，風險處理有三種方法，①風險控製法，即主動採取措施避免風險，消滅風險，中和風險或採用緊急方案降低風險。②風險自留，當風險量不大時可以餘留風險。③風險轉移。
　　風險監控 包括對風險發生的監督和對風險管理的監督，前者是對已識別的風險源進行監視和控制，後者是在項目實施過程中監督人們認真執行風險管理的組織和技術措施。
　　在IT軟體專案管理中，應該任命一名風險管理者，該管理者的主要職責是在制訂與評估規劃時，從風險管理的角度對專案規劃或計划進行審核並發表意見，不斷尋找可能出現的任何意外情況，試著指出各個風險的管理原則及常用的管理方法，以隨時處理出現的風險，風險管理者最好是由項目主管以外的人擔任。
4 風險識別
　　風險識別就是企圖採用系統化的方法，識別某特定項目已知的和可預測的風險。常用方法是建立“風險條目檢查表”，利用一組提問來協助項目風險管理者瞭解在項目和技術方面有些風險。在“風險條目檢查表”中，列出了所有可能的與每一個風險因素有關的提問，使得風險管理者集中來識別常見的、已知的和可預測的風險，如產品規模風險、依賴性風險、需求風險、管理風險及技術風險等。 “風險條目檢查表”可以以不同的方式組織，通過判定分析或假設分析，給出這些提問確定的回答，就可以協助管理或計劃人員估算風險的影響。軟體項目一般有如下五類風險：
4.1 產品規模風險
　　有經驗的專案經理都知道：項目的風險是直接與產品的規模成正比的。與軟體規模相關的常見風險因素有：
　　估算產品的規模的方法（LOC或程式碼，FP或功能點，程式或檔案的數目）。
　　產品規模估算的信任度
　　產品規模與以前產品規模平均值的偏差
　　產品的使用者數
　　複用的軟體有多少
　　產品的需求改變多少
4.2 需求風險
　　很多項目在確定需求時都面臨著一些不確定性和混亂。當在項目早期容忍了這些不確定性，並且在項目進展過程當中得不到解決，這些問題就會對項目的成功造成很大威脅。如果不控制與需求相關的風險因素，那麼就很有可能產生錯誤的產品或者拙劣地建造正確的產品。每一種情況都會導致使人不愉快。
　　與客戶相關的風險因素有： 
　　對產品缺少清晰的認識
　　對產品需求缺少認同
　　在做需求中客戶參與不夠
　　沒有優先需求
　　由於不確定的需要導致新的市場
　　不斷變化需求
　　缺少有效需求變化管理過程
　　對需求的變化缺少相關分析
4.3 相關性風險
　　許多風險都是因為項目的外部環境或因素的相關性產生的。經常我們不能很好地控制外部的相關性，因此緩解策略應該包括可能性計劃，以便從第二資源或協同工作資源中取得必要的組成部分，並且覺察潛在的問題。與外部環境相關的因素有：
　　客戶供應條目或資訊
　　內部或外部轉包商的關係
　　互動成員或互動團體依賴性
　　經驗豐富人員的可得性
　　項目的複用性
4.4 管理風險
　　儘管管理問題制約了很多項目的成功，但是不要因為風險管理計劃中沒有包括所有管理活動而感到驚奇。在大部分項目裡，專案經理經常是寫項目風險管理計劃的人，並且大部分人都不希望在公用場合暴露自己的弱點。然而，像這些問題可能會使項目的成功變得更加困難。如果不正視這些棘手的問題，它們就很有可能在項目進行的某個階段影響項目。當我們定義了項目追蹤過程並且明晰項目角色和責任，就能處理這些風險因素：
　　計劃和任務定義不夠充分
　　實際項目狀態
　　項目所有者和決策者分不清
　　不切實際的承諾
　　員工之間的衝突
4.5 技術風險
　　軟體技術的飛速發展和經曆豐富員工的缺乏，意味著項目團隊可能會因為技巧的原因影響項目的成功。在早期，識別風險從而採取合適的預防措施是解決風險領域問題的關鍵，比如：培訓、僱傭顧問以及為項目團隊招聘合適的人才等。主要有下面這些風險因素：
　　缺乏培訓
　　對方法、工具和技術理解的不夠
　　應用領域的經驗不夠
　　新的技術和開發方法
　　不能正確工作的方法
5 風險估計
　　風險估計，又稱風險預測，常採用兩種方法估價每種風險。一種是估計風險發生的可能性或機率，另一種是估計如果風險發生時所產生的後果。一般來講，風險管理者要與專案計劃人員、技術人員及其他管理員一起執行四種風險活動：
　　（1）建立一個標準（尺度），以反映風險發生的可能性。
　　（2）描述風險的後果。
　　（3）估計風險對項目和產品的影響。
　　（4）確定風險的精確度，以免產生誤解。
　　另外，要對每個風險的表現、範圍、時間做出盡量準確的判斷。對不同類型的風險採取不同的分析辦法。
1．確定型風險估計
（a）盈虧平衡分析
　　盈虧平衡分析（Break-Even Analysis）通常又稱為量本利分析或損益平衡分析。它是根據軟體項目在正常生產年份的產品產量或銷售量、成本費用、產品銷售單價和銷售稅金等資料，計算和分析產量、成本和盈利這三者之間的關係，從中找出它們的規律，並確定項目成本和收益相等時的盈虧平衡點的一種分析方法。在盈虧平衡點上，軟體項目既無盈利，也無虧損。通過盈虧平衡分析可以看出軟體項目對市場需求變化的適應能力。
（b）敏感性分析
　　敏感性分析（Sensitivity Analysis）的目的，是考察與軟體項目有關的一個或多個主要因素髮生變化時對該項目投資價值指標的影響程度。通過敏感性分析，使我們可以瞭解和掌握在軟體項目經濟分析中由於某些參數估算的錯誤或是使用的資料不太可靠而可能造成的對投資價值指標的影響程度，有助於我們確定在項目投資決策過程中需要重點調查研究和分析測算的因素。
（c）機率分析
　　它是運用機率論及數理統計方法，來預測和研究各種不確定因素對軟體項目投資價值指標影響的一種定量分析。通過機率分析可以對項目的風險情況做出比較準確的判斷。主要包括解析法和類比法（蒙特卡羅Monte Carlo技術）兩種。
2．不確定型風險估計
　　主要有小中取大原則、大中取小原則、遺憾原則、最大數學期望原則、最大可能原則。
3．隨機型風險估計
　　主要有最大可能原則、最大數學期望原則、最大效用數學期望原則、貝葉斯後驗機率法等。
5.1 建立風險清單
　　風險清單是關鍵的風險預測管理工具，清單上列出了在任何時候碰到的風險名稱、類別、機率及該風險所產生的影響。其中整體影響值可對四個風險因素（效能、支援、成本及進度）的影響類別求平均值（有時也採用加權平均值）。
一旦完成了風險表的內容，就可以根據機率及影響來進行綜合考慮，風險影響和出現機率從風險管理的角度來看，它們各自起著不同的作用（見圖1）。一個具有高影響但低機率的風險因素不應當佔用太多的風險管理時間 ，而具有中到高機率、高影響的風險和具有高機率及低影響的風險，就應該進行風險分析。
5.2 風險評估
　　在風險分析過程中，我們對風險進行評估時可以建立一個如下的四元數組：
　　[ri , li, xi，yi]
　　其中，ri是風險，li 為風險出現的機率，xi 則表示風險損失大小，yi 則表示期望風險。
　　一種對風險評估的常用技術是定義風險的參照水準，對絕大多數軟體項目來講，風險因素——成本、效能、支援和進度就是典型的風險參照系。也就是說對成本超支、效能下降、支援困難、進度延遲都有一個導致項目終止的水平值。如果風險的組合所產生的問題超出了一個或多個參照水平值時，就終止該項目的工作，在項目分析中，風險水平參考值是由一系列的點構成的，每一個單獨的點常稱為參照點或臨界點。如果某風險落在臨界點上，可以利用效能分析、成本分析、品質分析等來判斷該項目是否繼續工作。圖2 表示了這種情況。
　　但在實際工作中，參照點很少能構成一條光滑的曲線，大多數情況下，它是一個地區，而且是個易變的地區。因而在做風險評估時，盡量按以下步驟執行：
　　（1）定義項目的水平參照值
　　（2）找出每組[ri , li, xi，yi]與每個水平參照值間的關係
　　（3）估計一組臨界點以定義項目的終止地區
　　（4）估計風險組合將如何影響風險水平參照值
5.3 估計損失的大小
　　表1是風險分析表的一個例子，可以建立一個用風險、損失機率、損失大小和期望風險這樣的風險評估表。
　　在表1所示的風險估價的例子中，一個理論項目已經識別了從1到20周期間的潛在的幾個風險，風險發生的機率範圍在5%到50%之間。在現實的項目中，可能會識別出比此表要多得多的風險。
　　損失的大小常常比機率更容易受到控制。在以上的例子中，可以很精確地估計出完全支援自動從主機更新資料的時間是20個月。根據管理層將在何時討論專案提案書,可以知道項目不是在2月1日就是3月1日會被批准。如果假定會在2月1日批准，項目被獲批准的風險大小會比期望的長一些，也就是1個月時間。
　　如果損失的大小不容易直接估計出來，可以將損失分解為更小的部分，再對其進行評估，然後將各部分評估結果累加，形成一個合計評估值。例如，如果使用3種新編程工具，可以單獨評估每種工具未達到預期效果的損失，然後再把損失加到一起，這要比總體評估容易多了。
5.4 評估損失的機率
　　評估損失的機率要比評估損失大小更具有主觀性。這裡有許多實踐方法可以提高主觀評估的準確度。有以下方法：
　　由最熟悉系統的人評估每個風險的發生機率，然後保留一份風險評估審核檔案。
　　使用Delphi法或少數服從多數的方法。使用Delphi法，必須要求每個人對每個風險進行獨立地評估，然後討論（口頭或紙上）每個評估的合理性，特別是最高和最低的那個。一輪輪討論，直到達成共識。 ? 使用“形容詞標準”。首先讓每個人用表示可能性的形容詞短語選擇風險的層級，如非常可能、很可能、可能、或許、不太可能、不可能、和根本不可能。然後把可能性的評估轉換為數量化的評估（Boehm1989）。
5.5 整個項目超限和緩衝
　　實際上，表1中表示的期望風險的計算數值來源於一個被稱為“期望值”的統計術語。設計欠佳引起的風險如果真正發生將花費15周的時間。既然它不是100%地會發生，當然不能預計損失15周時間。但它也不是沒有可能發生，所以也不應指望不會發生損失。統計學認為，預計損失的數量是機率乘以損失大小，即15%乘以15周。因此，在這個例子中，預計的是損失2.25周。由於只是談論計劃風險，可以累加所有的風險暴露量來得到項目的全部可預料超標值。這個項目可預料的超標值是12.8到13.2周，這就是如果不做任何風險管理的話有可能超過計劃的周數。
　　超出預期值的大小為整個項目風險控制層級的確定提供了依據。如果例子中的項目是個25周的項目，超出預期值的12.8到13.2周就很明顯需要進行風險管理了。
6 風險管理策略
　　風險管理策略就是輔助項目組建立處理項目風險的策略。項目開發是一個高風險的活動，如果項目採取積極的風險管理策略，就可以避免或降低許多風險，反之，就有可能使項目處於癱瘓狀態。一般來講，一個較好的風險管理策略應滿足以下要求：
　　（1）在項目開發中規劃風險管理，盡量避免風險
　　（2）指定風險管理者，監控風險因素
　　（3）建立風險清單及風險管理計劃
　　（4）建立風險反饋渠道
7 風險駕馭和監控
　　風險的駕馭與監控主要靠管理者的經驗來實施，它是利用專案管理方法及其它某些技術，如原型法、軟體心理學、可靠性等來設法避免或轉移風險。風險的駕馭和監控活動可用圖3 來表示。
7.1 建立風險駕馭與監控計劃
　　從圖3中可以看出，風險的駕馭與監控活動要寫入RMMP（Risk Monitoring and Management Plan風險駕馭與監控計劃）。RMMP記述了風險分析的全部工作，並且作為整個專案計劃的一部分為專案管理人員所使用。
　　風險管理策略可以包含在軟體專案計劃中，也可以組織成一個獨立的風險降低、監控和管理計劃（RMMP計劃）。RMMP計劃將所有風險分析工作文檔化，並由專案管理者作為整個專案計劃中的一部分來使用。一旦建立了RMMP計劃，且項目開始啟動，則風險降低及駕馭及監控步驟也開始了。正如前面討論的，風險降低是一種問題避免活動。風險駕馭及監控則是一種項目跟蹤活動，它有三個主要目標： ? 判斷一個預測的風險是否事實、是否發生。
　　進行風險再估計，確保針對某個風險而制定的風險消除活動正在使用。
　　收集可用於將來進行風險分析的資訊。
　　風險駕馭及監控的策略如下：
　　與在職人員協商，確定人員流動原因。
　　在項目開始前，把緩解這些流動原因的工作列入風險駕馭計劃。
　　項目開始時，要作好人員流動的思想準備，並採取一些措施確保人員一旦離開時，項目仍能繼續。
　　制定文檔標準，並建立一種機制，保證文檔及時產生。
　　對所有工作進行細微詳審，使更多人能夠按計划進度完成自己的工作。
　　對每個關鍵性技術人員培養後備人員。
　　在考慮風險成本之後，決定是否採用上述策略。
7.2 軟體項目風險追蹤工具
　　追蹤風險的一個辦法是將風險輸入缺陷追蹤系統中，缺陷追蹤系統能將風險項目標示為已解決或尚未處理等狀態，也能指定解決問題的項目團隊成員，並安排處理順序。可將軟體風險項目依序排列出來，按照缺陷存在的時間與負責者等資料排列。這樣，缺陷追蹤系統就是追蹤風險的工作能更好執行並且不那麼單調。
8 結束語
　　軟體項目風險管理是一種特殊的規劃方式，當對軟體項目有較高的期望值時，一般都要進行風險分析。進行過大中型項目開發的人都親身體驗到許多事情可能出錯，最成功的項目就是採取積極的步驟對要發生或即將發生的風險進行管理。對任何一個軟體項目，可以有最佳的期望值，但更應該要有最壞的準備，“最壞的準備”在專案管理中就是進行項目的風險分析。