我們在軟件開發過程中會遇到不同的變更，代碼的更新，新功能的寫入，架構的調整，系統的擴容。每天有大量的需求，代碼，Bug需要處理，其實我們做的每個對系統產生影響的動作背後都存在風險。那麼我們如何評估和管理這些風險呢，任何一位項目的管理者或者領導者都需要了解下面提到的方法論。

對風險進行定義

大家知道在做任何一次變更的時候都存在風險，比如一次新功能模塊的發佈會影響到幾個老的功能模塊，那麼作為管理者如何評估這個上線的新功能的風險呢。這裡介紹幾種方法。

第一，直覺，這個說起來有點好笑，其實就是憑藉經驗豐富的程序員，架構師（老司機）的感覺去評估這次變更存在的風險。這種方式長期存在各個互聯網/軟件企業之中的，基本都是靠老人來帶着大家踩坑。這種方式雖然多見，但是缺點很明顯，就是依賴個人能力，而且具有隨機性，一旦個人判斷失誤就真的坑了。

第二，交通燈法。還是剛才新功能的例子，我們可以把新功能影響到的老功能模塊列出來，針對每個功能模塊受到的影響進行「紅，黃，綠」燈評價。綠燈=低風險，黃燈=中風險，紅燈=高風險。然後通過團隊以及專家評審的方式來判斷這次新功能的上線的風險有多大。這個的好處是，減少了人為感知的風險，讓風險具體化了，而且引入了團隊評審的方式，讓結果更加客觀。

第三，故障模式及影響分析法（Failure mode and effects analysis, FMEA）。這種方式會把一個功能模塊切分成幾個組成部分，然後針對每個組成部分的三個維度進行打分。這三個維度分別是：故障發生的可能性，故障發生的嚴重性，故障檢測能力水平。可以針對這三個維度進行打分，分數從1-9分不等，分數越高說明風險越高。通常我們會按照高中低三個級別來劃分分值，例如：高風險：9分，中風險：3分，低風險：1分。小夥伴們可以根據自己的團體來具體設置分值不同。舉個例子來說，我們有一個登錄服務，有可能出現「給用戶設置錯誤權限」的風險。因為這個權限設置都是系統管理員來設置的，那麼故障發生的可能性是比較低的，我們給其打分為1分（低風險）。一旦這個權限設置錯誤會導致，用戶看到不屬於自己的信息，這個故障發生的嚴重性是很高的，我們給其打分了9分（高風險）。這個故障我們可以通過後台腳本的方式去針對每個用戶的權限進行核對，所以故障檢測能力的水平屬於中等，就給3分（中風險）。如此這樣我們可以把三個維度的分數相乘就是1*9*3=27。如果這個登錄功能還包含其他的組件，就以此類推評估每個組件的風險分數然後相加就是這個功能的風險分數了。如果我們希望降低發生故障的風險，就根據這個三個維度採取對應的防範措施。例如：後台定時監測用戶權限，如果發現第一時間讓用戶和權限做隔離，並且通知客戶部門給客戶做解釋，把風險降到最低點。如果這麼做了我們就將故障發生的嚴重性的風險分值將下來了，從原來的9分降到3分，那麼總分就是1*3*3=9分。是不是把風險控制到可控的範圍內了呢。這裡可以根據每個團隊設計一個風險的表格把風險都記錄下來。

對風險進行管理

如果能夠對風險進行定義了，那麼風險管理需要主要兩類風險，第一類急性風險，第二類整體風險。

急性風險管理，往往針對一個或者多個功能點的變更，整個實施時間不會太長。這裡需要針對該變更進行拆解，然後用上面介紹的FMEA進行風險評估，並且對每個組件的風險水平進行設置容忍值。最後形成一個急性風險管理的表格，讓實際風險發生的分值必須在風險水平的範圍以內。

整體風險管理，這裡需要變更的範圍比較大，而且持續時間較長，所以未知因素和風險就更加不可控制。這裡建議在急性風險管理組件風險水平的基礎上加上持續時間的風險評估。會針對每個變更持續時間設置風險水平能夠容忍的分數。

但是，在日常的工作中總會有特例，例如有些功能急需變更，有高風險同時也有高收益。這個時候，技術總監，架構師，CTO，業務主管手中也有一些風險水平的分值，這些分值用來調整表格中風險水平的容忍最大值。說白了就是如果關鍵人物參與風險評測，推動緊急變更上線。

總結：今天我們了解了風險評估的三種方法，並且推薦給大家使用FMEA方法，針對變更拆分，評估，打分，降低單項風險。針對緊急風險管理和整理風險管理提出了一些分析方法。