專案（Explore）總結之專案風險管理

專案風險管理包括專案風險規劃、風險識別、分析、應對和監控的過程。目標在於增加積極事件的機率和影響，降低消極事件的機率和影響。

專案Explorer雖然沒有十分正式的專案風險管理，但也有專門針對專案中可能出現的問題（即風險）進行討論和應對的過程，使用的工具和技術主要是專家判斷、同行評審等。

風險管理規劃是決定如何進行風險管理的活動的過程。

Explorer沒有專門的風險規劃過程，更多的是停留在定性透過經驗規劃的層次，也就是透過既往的經驗和做法對該專案的風險進行規劃和判斷。雖然沒有明確，但有約定俗成的做法，比如在角色和職責上專案風險管理由PM負責，在風險的確定和跟蹤上透過週報的形式反映、風險的機率使用1-9共9個級別，級別越高風險越高、風險的影響分析使用文字定性表述，說明對專案範圍、質量、成本和進度等各個方面的影響。

風險識別是指確定哪些風險會影響專案，並將其記載成文。

在Explorer專案中，風險識別主要根據專案組成員在之前專案實施過程中總結和歸納的經驗教訓、公司內部標準的風險評估清單，透過召開評審會議，召集專案組骨幹成員、公司內部其他部門具有類似經驗的高階技術人員、質量控制部對風險進行識別。依據風險評估清單，與會的評審人員針對清單中每一風險評估因素發表意見，確定該風險評估因素是否存在風險，如有則明確風險名稱、風險可能的原因，如無則忽略該評估因素。其中，風險評估因素是指軟體專案各個環節中需要考慮的風險因子，專案環節包括專案目標、環境約束、客戶/使用者、開發流程、專案管理、專案團隊、需求、架構、程式碼實現、整合和測試、系統平臺、上線、運維等方面。

評審會議最終產出專案風險清單，彙總為從管理、技術和商務等多個因素進行分解可能存在的風險列表，包括風險名稱和產生原因。風險識別後下一步將對風險進行風險分析。

風險分析包括定性風險分析和定量風險分析。定性風險分析是為了採取下一步行動，對已識別的風險進行優先排序的方法。風險定量分析是對風險定性分析過程中作為對專案需求存在潛在重大影響而排序在先的風險進行分析。

Explorer專案主要透過專家評審的方式對風險識別形成的風險清單進行分析，確定風險清單中的風險優先順序、機率和影響。經過評審會議，專案最有可能發生的風險清單及其機率、影響如下：

一、          管理類風險清單：

1.      專案核心團隊（PM, TM, 業務分析師, Team Leader）沒有足夠的專業知識和經驗（包括業務領域、技術領域）；

a)      機率：8級；

b)      影響：專案進度延遲；成本增加；質量成本增加、返工較多；

2.      專案團隊不穩定，進出頻繁；

a)      機率：6級；

b)      影響：專案進度延遲；專案團隊建設成本增加、人員培訓費用增加；專案質量成本增加、返工較多；

3.      開發規範不能被嚴格執行，程式碼複審執行力不足；

a)      機率：7級；

b)      影響：質量成本增加、返工較多；

4.      客戶參與和配合的程度不夠，不能提供有效的需求；

a)      機率：4級；

b)      影響：範圍蔓延；專案進度延遲；專案成本增加；專案質量成本增加、返工較多；

二、          需求類風險清單

1.      專案需求不清，客戶沒有想法，不清楚自己需要什麼；

a)      機率：7級

b)      影響：範圍無法控制；專案進度延遲；專案成本增加；專案質量成本增加、返工較多；

三、          技術類風險清單：

1.      沒有現成的成熟技術框架，使用的技術在業界不成熟，只有少數成功的案例；

c)      機率：8級；

d)      影響：專案進度延遲；人員培訓費用增加，專案成本增加；專案質量成本增加、返工較多；

2.      技術架構未經驗證，尚不明確是否滿足效能要求；

e)      機率：8級；

f)      影響：專案進度延遲；專案成本增加；專案質量成本增加、返工較多；

 

由於沒有現成的技術框架可用，目前的技術能否滿足業務需要很難確定，能否完成專案誰心裡都沒有底。據此，定義技術類風險為目前優先順序最高的風險，在進入開發前需馬上組織人手著手解決。

風險應對規劃是為專案目標實現增加實現機會，減少失敗威脅而制定方案，決定應採取對策的過程。

根據風險識別和風險分析的成果，對各項風險制定相應的應對措施，主要採用同行評審會議的方式進行。

各項風險的應對規劃如下：

一、          管理類風險清單：

1.      專案核心團隊（PM, TM, 業務分析師, Team Leader）沒有足夠的專業知識和經驗（包括業務領域、技術領域）；

a)      責任人：PM、系統分析員；

b)      應對措施：接受，減輕（該風險無法規避和轉嫁）；

c)      應對計劃活動：業務培訓、技能培訓、經驗總結和分享；

2.      專案團隊不穩定，進出頻繁；

a)      責任人：PM；

b)      應對措施：接受，減輕（該風險無法規避和轉嫁）；

c)      應對計劃活動：建立完備的過程文件和工作記錄；關鍵崗位人員的備份以及培訓、培養；加強團隊建設，增強團隊凝聚力，減少人員流失；

3.      開發規範不能被嚴格執行，程式碼複審工作執行不到位；

a)      責任人：PM、各子系統負責人；

b)      應對措施：接受，減輕（該風險無法規避和轉嫁）；

c)      應對計劃活動：制定明確的開發規範和程式碼複審制度，寫入到專案管理制度中，與績效考核掛鉤；

4.      客戶參與和配合的程度不夠，不能提供有效的需求；

a)      責任人：系統分析員；

b)      應對措施：接受，減輕（該風險無法規避和轉嫁）；

c)      應對計劃活動：與客戶溝通協商，制定明確的時間計劃，客戶確認；商務協調，求得客戶高層的支援；

二、          需求類風險清單

1.      專案需求不清，客戶沒有想法，不清楚自己需要什麼；

a)      責任人：系統分析員；

b)      應對措施：接受，減輕（該風險無法規避和轉嫁）；

c)      應對計劃活動：安排經驗豐富的系統分析員到現場調研和分析，與客戶一起討論需求，在提出想法和業務建議以及收集反饋意見逐步明確需求；組織評審會議，集思廣益；

三、          技術類風險清單：

1.      沒有現成的成熟技術框架，使用的技術在業界不成熟，只有少數成功的案例；

a)      責任人：系統架構師；

b)      應對措施：接受，減輕；

c)      應對計劃活動：組建技術公關團隊，研發技術框架；

2.      技術架構未經驗證，尚不明確是否滿足效能要求；

a)      責任人：測試經理；

b)      應對措施：接受；

c)      應對計劃活動：組建測試團隊，對技術框架進行效能測試，及早發現問題和解決問題；

 

風險監控是識別、分析和規劃新生風險、追蹤已識別風險和“觀察清單”中的風險，重新分析現有風險、監測應急計劃的觸發條件、監測殘餘風險，審查風險應對策略的實施並評估其效力的過程。

在Explorer專案中，主要使用同行評審會議的方式對風險進行監控。會議內容包括核查風險清單中的風險是否仍然存在？其機率和影響是否有變化？是否已經演變為問題？是否出現了新的風險？對於之前確定的風險應對措施，透過實際觀察的專案資訊評估措施是否到位，是否有效果等。

 

-------------------------- 本文可任意轉載，但請註明作者和出處 ----------------------------