軟件項目風險管控

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

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

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

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

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

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

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

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

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