作者：蘭燕子
1月27日參加了專案管理聯盟組織的『北京專案管理愛好者聚會』，我被易風邀請做了乙個主題演講，其實不是什麼演講，只是結合理論談了自己的一些想法和工作中遇到過的經驗教訓，更主要的目的是給大家出乙個討論和交流的主題，希望能起個拋磚引玉的作用。
我講的主題是：軟體開發專案的風險管理，因為我認為風險管理在軟體專案中很重要，又不容易做好，所以希望通過和大家討論能夠有一些思路和啟發。
現在把我準備的內容整理帖出來，希望在這裡繼續討論，大家在如下幾方面多展開討論：
1． 在軟體專案管理中如何做好風險防範
2． 軟體專案中的典型風險事件是哪些
眾所周知，軟體開發過程可分為：需求分析、設計、編碼、測試、安裝及維護等幾個過程（在rup方法中：業務建模、需求、分析設計、實施、測試、部署），實際上乙個完整的軟體專案前後還有其它過程，在這裡列出的只是和軟體開發相關的核心過程。
軟體專案的生命週期可以分為四個階段（不同行業的專案生命週期不同），即初始階段、設計階段、實施階段、收尾階段。軟體開發過程在軟體專案的這四個階段中的分布情況如下（括弧裡面表示rup方法中的過程）：
初始階段：大部分需求分析，少部分設計（大部分業務建模和需求，少部分分析設計）
設計階段：大部分設計，少部分編碼（大部分分析設計，部分實施及測試，開始考慮部署）
實施階段：大部分編碼和測試，少部分設計（大部分實施及測試，部分部署）
收尾階段：安裝及維護（大部分部署）
而專案管理則貫穿在整個生命週期的每個階段。
根據pmbok，專案管理可以從範圍管理、時間管理、費用管理、質量管理、人力資源管理、溝通管理、風險管理、採購管理和整體管理等9個方面考慮，對於軟體專案管理來講軟體配置管理（屬於整體管理）、軟體質量管理、軟體風險管理及開發人員管理（屬於人力資源管理）等四個方面的管理尤為重要，軟體開發的每個階段、每個過程都要重視這幾方面的管理。
下面就以軟體專案的風險管理為主題展開討論。
軟體專案管理的四個階段中，在初始階段專案成功的可能性最小，風險發生的概率也就最高，但是這時候一旦預計的風險發生了，損失是最小的，比如：在這個階段如果某種原因突然資金**斷了（這在需求階段是很有可能的），以至於不能繼續進行專案，不得不終止專案，那麼這時候的損失只是需求分析階段的投入。隨著專案的進展專案成功的可能性變大，風險發生的概率逐漸變小，風險對專案的損失逐漸變大，快到收尾階段的時候風險對專案的損失最大，隨著收尾階段的進行風險又逐漸變小。
1. 風險管理是對專案風險進行識別、分析和應對的過程。我們先看看專案風險可以怎麼分類，然後再對風險管理的這三個過程逐一進行討論。
1．風險的分類
按內容分
範圍風險：與範圍變更有關的風險
質量風險：沒有按照要求的技術效能和質量水平完成任務
進度風險：沒有在預算的時間範圍內完成任務
成本風險：沒有在預算的成本範圍內完成任務
技術風險：技術變化
法律風險：許可權、專利、合同失效、訴訟、不可抗力
外部可**風險：市場風險（原材料可利用性、需求）、日常運作（維修需求）、環境影響、社會影響、貨幣變動、通貨膨脹、稅收
外部可**風險：規章（不可**的**干預）、自然災害
內部非技術風險：戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）
按可確定性分
已知風險（knowns）：員工離職
已知-未知風險（known-unknowns）：可預知風險
未知-未知風險（unknown-unknowns）：不可預知風險
2．風險識別
風險的識別就是確定何種風險事件可能影響專案。在專案開始、每個專案階段中間、主要範圍變更批准之前都要進行風險識別，實際上它在整個專案生命週期內都是乙個連續的過程。
2. 要識別風險，首先我們應該了解在軟體開發的各個階段都有可能發生哪些風險（風險事件或風險**）。
初始階段
在這個階段進行大部分需求分析、少部分設計（大部分業務建模和需求、少部分分析設計）。
可能的風險事件：
● 專案目標不清
● 專案範圍不明確（範圍太大太小都不可以）
● 使用者參與少或和使用者溝通少
● 對業務了解不夠
● 對需求了解不夠
● 沒有進行可行性研究
設計階段
在這個階段進行大部分設計、少部分編碼（大部分分析設計，部分實施及測試，開始考慮部署）
可能的風險事件
● 專案隊伍缺乏經驗，如缺乏有經驗的系統分析員
● 沒有變更控制計畫，以至於變更沒有依據，該變更的不變，不該變的也變，這樣得來的設計勢必會失敗或者偏離使用者需求
● 倉促計畫，可能帶來進度方面的風險
● 漏項，由於設計人員的疏忽某個功能沒有考慮進去
實施階段
在這個階段進行大部分編碼和測試，也涉及少部分設計（大部分實施及測試，部分部署），如：設計變更或補充設計。
可能的風險事件
● 開發環境沒有具備好
● 設計錯誤帶來的實施困難
● 程式設計師開發能力差，或程式設計師對開發工具不熟
● 專案範圍改變（突然要增加或修改一些功能，需要重新考慮設計）
● 專案進度改變（要求提前完成任務等）
● 人員離開，在乙個專案內軟體開發工作有一定的連續性，需要移交和交接，有時人員離開對專案的影響會很大
● 開發團隊內部溝通不夠，導致程式設計師對系統設計的理解上有偏差
● 沒有有效的備份方案
● 沒有切實可行的測試計畫
● 測試人員經驗不足
收尾階段
在這個階段進行安裝及維護（大部分部署）。
可能的風險事件
● 質量差
● 客戶不滿意
● 裝置沒有按時到貨
● 資金不能**
以上只是例具了常見的風險事件，對不同專案可能發生的風險事件不同，應該對具體專案識別出真正有可能發生在該項目的風險事件。而且還要對這些風險事件進行描述，如：可能性、可能後果範圍、預計發生時間、發生頻率等。
風險識別的有效方法有很多，如：建立風險專案檢查表、因果分析圖、採訪各種專案干係人等。
軟體專案的風險可以從以下幾方面檢查：
產品規模風險
業務影響風險檢
與客戶相關的風險
過程風險
技術風險
開發環境風險
與人員的模式和經驗有關的風險
以上我們討論了在軟體專案各個階段中可能發生的風險事件和識別方法。下面我們看看如何對這些風險事件進行分析。
3．風險分析
風險分析就是對以上識別出來的風險事件做風險影響分析。
和風險相關的有四個因素：
風險事件，破壞或影響專案的事件
風險概率（%），事件發生的可能性
風險得失量（金額），說明可能造成的損失
風險影響（金額），等於風險概率 × 風險得失量
通過對風險及風險的相互作用的估算來評價專案可能結果的範圍，從成本、進度及效能三個方面對風險進行評價，確定哪些風險事件或**可以避免，哪些可以忽略不考慮（包括可以承受），哪些要採取應對措施。
4．風險應對
1、應對方法
專案中的風險永遠不能全部消除，pmbok提到三種應對方法：
避免通過分析找出來發生風險事件的原因，消除這些原因來避免一些特定的風險事件發生。
比如：如何避免客戶不滿意？
客戶不滿意有兩種情況，一種情況是沒有判斷客戶滿意度的依據，即沒有雙方互相認可的客戶驗收標準，還有一種是開發方沒有達到驗收標準，即沒有滿足使用者需求。不管是哪一種，開發方都有不可推卸的責任，只要做好以下環節完全可以避免：
● 業務建模階段要讓客戶參與
● 需求階段要多和客戶溝通，了解客戶真正的需求
● 目標系統的模型或demo系統要向客戶演示，並得到反饋意見，如果反饋的意見和demo系統出入比較大時，一定要將修改後的demo系統在次向客戶演示，直到雙方都達成共識為止
● 要有雙方認可的驗收方案和驗收標準
● 做好變更控制和配置管理
減輕通過降低風險事件發生的概率或得失量來減輕對專案的影響。也可以採用風險轉移的方法來減輕風險對專案帶來的影響。專案預算中考慮應急儲備金是另一種降低風險影響的方法。
比如：經過風險識別發現，專案組的程式設計師對所需開發技術不熟。可以採用熟悉的技術來減輕專案在成本或進度方面的影響。也可以事先進行培訓來減輕對專案的影響。
接受接收風險造成的後果。
比如：為了避免自然災害造成的後果，在乙個大的軟體專案中考慮了異地備份中心。
2、開發應對計畫
針對需要採取應對措施的風險事件，開發應對計畫，一旦發生風險事件，就實施應對計畫。
比如：有乙個軟體整合專案中包括了裝置，而且計畫在部署階段之前裝置必須到位，而這些裝置從廠家直接進貨。經過分析發現有可能不能按時進貨，那就應該考慮備選方案，比如能不能周轉等。
又比如：
在乙個軟體開發專案中，某開發人員有可能離職，離職後會對專案造成一定的影響，則應該對這個風險事件開發應對計畫，過程可以參照如下：
● 進行調研，確定流動原因
● 在專案開始前，把緩解這些流動原因的工作列入風險管理計畫
● 專案開始時，做好計畫一旦人員離開時便可執行，以確保人員離開後專案仍能繼續進行
● 制定文件標準，並建立一種機制，保證文件及時產生
● 對所有工作進行細微詳審，使更多人能夠按計畫進度完成自己的工作
● 對每個關鍵性技術人員培養後備人員
在考慮風險成本之後，決定是否採用上述策略。
軟體開發專案管理
軟體開發專案管理，補習對軟體開發專案的工作範圍 可能遇到的風險 需求的資源 要實現的任務 經歷的里程碑 話費的工作量，以及進度的安排等等做到心中有數。而軟體專案管理可以提供這些資訊。軟體具有可見性差 定量化難等特殊性。但通常可以 根據以往開發類似軟體的經驗來進行成本估算。將軟體專案劃分為若干個子系統...
專案軟體開發計畫
公司名 專案名 軟體開發計畫 版本 1.0 注 以下提供的模板用於 rational unified process。其中包括用方括號括起來並以藍色斜體 樣式 infoblue 顯示的文字，它們用於向作者提供指導，在發布此文件之前應該將其刪除。按此樣式輸入的段落將被自動設定為普通樣式 樣式 body...
軟體開發專案驗收標準
驗收標準 1.引言 1.1 編寫目的 為了使專案驗收更具公平性 可操作性和標準化，特制定此驗收標準。1.2使用者 專案名稱 中小型物流企業erp平台開發與建設專案專案製作提出單位 專案開發單位 主管部門 開發人員 驗收人員 1.3參考資料 1 軟體需求說明書 2 系統概要設計說明書 3 總體設計說明...