這是《落葉》文集里第 *327 *片落葉，希望你能喜歡，不為別的，只為這份堅持。
第十二章 只看概念和理論，我還是不知道怎么管理風險？
老大把我喊到會議室，我一進門，就看到大白板上滿滿當當的寫了好多字。
風險管理是指如何在項目或者企業這樣一個肯定有風險的環境里把風險可能造成的不良影響減至最低的管理過程。風險管理的內容包括風險管理計劃、風險識別、定性風險分析、定量風險分析、風險應對計劃和風險監督與控制。
在執行過程中，項目風險管理可以簡化為風險識別、風險度量、制定應對措施和風險監控四個過程。
老大讓我自己看了一會白板，又接著說：“在任何環境下做項目，風險都是無處不在的，也是最防不勝防的。項目風險其實就是一種不確定的事件或條件，假如發生，就會對項目造成積極或消極的影響，如范圍、進度、成本和質量，所以我們在做測試計劃時，最重要的一項工作就是識別風險和制定風險應對方案。”
我說，“對于什么是風險和風險管理，以及為什么要管理風險，我都差不多明白了，可風險管理要怎么去做呢？”
老大說：“風險管理就是在識別出項目可能有的風險之后，事先就可以做的或者是可以計劃的一系列應對手段，最終目標是降低風險發生的概率或者是當風險發生時，如何能快速地、有效地去應對和解決風險所帶來的后果，主要有幾個步驟。”
邊說邊在白板上寫了下來：
- 描述清楚風險是什么，會產生什么樣的嚴重后果，包括發生概率有多大；
- 為什么會產生這個風險，它可能發生在某個階段或時間點；
- 針對每個原因再制定應對方案；
- 每個風險應對方案要有明確的責任人和時間計劃節點；
寫完之后，老大對我說：“你來說說，你做過的項目里，都有哪些風險？”
我回答道：“常見的風險有不少呢，比如提測時間比計劃時間晚了，開發提測版本的質量不好，測試過程中需求發生變動等等，這些都算是風險吧？”
老大笑著說，“你說的這些其實都是風險產生的原因，很多人都會把它們當做風險本身，問題雖然不大，但就會導致計劃書里的風險管理清單可能會很長，給人一種，這個項目怎么有這么多風險？還能正常完成嗎？”
“那你給我看個實例唄，不然總是在說概念，太抽象了，不好理解。”
“好吧，這里有一份項目風險管理計劃，你看看吧，有什么問題，隨時再來找我。”
【風險】：
測試執行時間被壓縮，產品還未經過充分測試就發布上線，導致上線后用戶投訴增多（70%）
【原因】：
- 產品需求出來的晚，而且也不完善清晰，多次反復評審的時間擠占了研發時間；
- 開發自測不充分，導致提測的版本質量不高，影響正常測試計劃進度；
- Bug 修復速度慢，阻礙了完整的新功能測試和最后的回歸測試；
- 中后期需求頻繁變更，或者是新增需求，導致測試資源被分散；
【應對方案】：
- 優化測試用例的設計，減少冗余的和無效的測試用例，同時提高自動化腳本的覆蓋率，節省出相應的人力用于新功能的驗證測試；
- 制定測試包的可接收標準，編寫 ATC （Acceptant Test Case），沒達到可提測標準的一律退回，采取這種倒逼的方式，讓開發提高自測質量；
- 和開發負責人明確 Bug Fix 的要求，每天幾點之前要日清當天的 New Bug，同時，測試任務包盡可能拆解的小一些，獨立一些，在某些模塊出現阻礙性 bug 時，可以略過先去測試別的模塊；
- 在做測試任務量評估時，預留10%~15%的 Buffer，用于應對需求變更和臨時新增需求；
《告訴你如何從執行測試到管理測試》帶你邁出第（12）步！，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
