1、.推介導讀：此論文從需求調研、開發、實施以及項目收尾四個項目階段，列舉了11種典型的常見風險，并給出了這些風險的詳細和切實可行的風險規避措施。這些風險和措施實用、實在，值得做為公司項目管理財富庫進行收藏，值得各項目組借鑒。軟件項目風險管控1. 什么是軟件項目風險軟件項目風險是指在軟件開發過程中遇到的預算和進度等方面的問題以及這些問題對軟件項目的影響。軟件項目風險會影響項目計劃的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟件項目目標不能實現。如果對項目進行風險管理，就可以最大限度的減少風險的發生。2. 項目風險及應對措施軟件項目的生命周期可以分為四個階段，即需求調

2、研階段、開發階段、實施階段、收尾階段，軟件開發過程可分為：需求分析、設計、編碼、測試等幾個過程，在軟件項目的每個階段、每個過程都可能存在風險。下面結合項目談談各階段碰到的風險。2.1. 需求調研階段1 風險描述：調研涉眾沒有足夠的時間參與調研活動，嚴重影響調研進度與調研質量。應對措施：Ø 開始調研時，召集公司的高層領導、各部門主管及參與調研的關鍵涉眾召開調研啟動會，讓所有涉眾都重視本次調研活動，努力配合調研工作。在調研啟動會上明確調研涉眾的職責；Ø 在制定調研計劃時，應事前與相關涉眾做好溝通工作，努力減少調研計劃與日常工作安排的沖突；Ø 相關人員通過移交日常工作等

3、辦法，有效保證相關涉眾的調研時間；Ø 調研人員設計調研提綱時，要有針對性，盡量努力提高調研效率。2 風險描述：調研成果不能真實和完整地體現管理層意圖與企業經營管理需要。應對措施：Ø 通過客戶方的多方協調，讓管理層要重視調研人員的訪談，客觀而真實地回答訪談問題；Ø 管理層調研提綱在設計時，不僅要做到有針對性，而且要有全面性；Ø 調研人員在訪談管理層，要善于挖掘與總結管理層的管理意圖與經營思路；Ø 管理層的意圖應宣達到所有涉眾，努力做到在繁多的需求中，把握住管理思路的主線。3 風險描述：在某些需求議題上，不同部門、不同單位可能會有不同的理解與要求，

4、且可能會各自堅持自己的意見，無法達成共識。應對措施：Ø 通過管理層宣傳與教育，讓相關涉眾認識到業務流程標準化的重要性；Ø 由總部成立業務專家小組，在出現需求不一致，提出權威的解決方案；Ø 調研人員憑借自身的流程分析能力，盡量定義出能兼容不同需求的解決方案。Ø 對確實無法達成共識的需求，可以采用暫時擱置爭議辦法，以保證進度。4 風險描述：調研成果偏離調研涉眾的需求應對措施：Ø 調研時認真聆聽調研涉眾的需求，然后理解及復述調研的需求；Ø 調研完成后，在當天整理出涉眾備忘錄、調研涉眾的交付物清單，梳理并繪制流程圖；Ø 第二天安排足

5、夠的時間，與調研涉眾核對涉眾備忘錄、流程圖、交付物清單，并得到調研涉眾的書面確認；Ø 每家分公司的所有調研成果最終都要有分公司領導的書面簽字確認。2.2. 開發階段1 風險描述：錯誤理解需求分析，導致開發成果與用戶需求偏離。應對措施：Ø 準確規范的文字表達模式；Ø 系統分析師與開發人員保持密切溝通，必要時召開會議向全體開發小組成員介紹需求的詳細情況；Ø 功能開發完后，系統分析師檢查功能實現情況及效果；2 風險描述：項目周期短導致開發周期短，需要把SQL翻譯為ORACLE，而且要統一平臺整合船代與貨代系統，開發任務艱巨，可能導致開發無法如期開發完成的風險。

6、應對措施：Ø 增加項目組熟練開發人員；Ø 分析、設計、開發、測試迭代進行；Ø 在客戶方搭建測試環境，開發完成部分功能后，發布到客戶方測試環境，讓關鍵用戶一起驗證，及時糾正偏離的需求。2.3. 實施階段1 風險描述：基礎數據收集不完整、不及時，導致系統UAT效果不好。應對措施：Ø 盡早整理所有需要收集的基礎信息表，發給各公司系統負責人，并告知收集的期限，收集的期限必須要預留緩沖時間。Ø 收集到基礎信息表要必須在UAT開始前導入系統的UAT環境。Ø 基礎數據維護是一個漫長的過程，建議UAT的基礎數據按正確的數據進行維護，上線時直接導入正式

7、環境。2 風險描述：UAT效果不好，導致無法如期上線。應對措施：Ø 與公司領導、各業務部門主管了解公司的業務線，制定UAT計劃時必須涵蓋公司的所有業務線；Ø 與UAT用戶共同制定各業務線的錄入數據量，每天或者每周統計數據錄入情況，匯報相關項目干系人。統計清單中必須有計劃錄入數據量、實際錄入數據量、完成百分比情況；Ø 若錄入數據量比計劃數據量偏差比較大時，必須及時召開例會并讓公司領導一起參與會議。Ø UAT時，必須讓關鍵用戶清楚知道整個操作流程及功能點，必須要有功能清單。3 風險描述：UAT后上線還是有一大堆問題，上線效果非常差，沒達到用戶的預期。應對措施

8、：Ø UAT后建議安排系統并行，根據各業務線的情況制定并行計劃。例如：有的業務線數據量比較少可以采取完全并行的模式，有的業務線數據量比較大可以采取并行50%的方式；Ø 讓所有的最終用戶參與系統的并行；Ø 并行階段每天或者每周統計數據錄入情況，匯報相關項目干系人。統計清單中必須有計劃錄入數據量、實際錄入數據量、完成百分比情況；4 風險描述：UAT階段都沒什么問題，上線時因某個功能原因推遲上線。應對措施：Ø 項目啟動時，嚴格制定上線標準；Ø UAT階段要有詳細的功能清單、EDI清單、打印套版、接口清單，讓關鍵用戶知道試用的內容；Ø 在UA

9、T期間，必須要讓關鍵用戶對這些清單進行試用，并規定問題反饋的期限；Ø 上線一周前收集關鍵用戶對這些清單的簽字確認，至少預留一周的緩沖時間。2.4. 收尾階段1 風險描述：系統的驗收是整個項目過程中最難的里程碑點，系統不可能做到完全沒有問題，客戶可以找一些理由遲遲不驗收系統。應對措施：Ø 簽訂商務合同的時候，規定驗收的期限，例如：上線后多長時間完成驗收工作；Ø 驗收標準正常情況下是按需求規格說明書及合同規定的交付物進行驗收，但是項目周期緊，開始寫的需求規格說明書到了系統驗收階段往往偏離比較大。雙方項目經理及相關領導討論制定系統需求收集期限，并對需求進行劃分，劃分出合同范圍內驗收前解決的需求清單，合同范圍外驗收前解決的需求清單。針對這些需求進行集中處理。