在理想的世界里，事情都是按照我們的計划執行的；在真實的世界里，事情經常會呈現出布朗運動的特性——不按常理出牌。今天我們談下軟件項目管理中的風險管理。
下面這張圖，來自軟件工程之美的一篇文章——《風險管理：不能盲目樂觀，凡事都應該有B計划》
閱讀摘抄
- 風險是指不確定的事件，一旦發生，將會造成消極的影響
- 在軟件項目的管理，對項目風險的管理才是體現管理水平的地方
- 風險管理最大的問題不是如何做，而是項目成員缺少風險意識，有了風險意識，才能去識別出來項目中可能存在的風險，進而去管理風險。
- 項目中的任務，不能盲目樂觀，都要思考下它最壞的結果是什么，如果最壞的結果不能接受，就說明要有個B計划，要考慮風險管理了。
- 風險的處理過程有四個步驟：風險識別、風險量化、應對計划、風險監控，這是一個循環迭代的過程，需要在軟件項目中持續進行。
我的心得
正所謂“凡事預則立，不預則廢”，軟件項目要有計划，做很多事情都要有計划，我一般使用PDCA工作法進行計划。如果事情可以按照計划正常推進，那是最好了，不過，由於各種各樣的因素，在事情的推進過程中，會有一些意想不到的事情發生：可能是正面的意外，那就是驚喜；也可能是負面的意外，那就是驚嚇了。風險，就是指在事情的推進過程中遇到的負面的意外，有時候人們也稱之為“黑天鵝”。
作為開發者，在日常開發中，每一次線上操作（代碼變更、配置變更）都有風險；在軟件項目中，風險就是指那些讓項目無法按時、按質交付的事情。面對這些可能的風險，最好的辦法是：建立風險意識、擁抱風險、積極面對、積極處理。
作為系統分析師，在做系統分析和架構設計的時候，除了要設計正常的主業務流程，也需要考慮異常業務流程——出現異常了怎么解決、已經做到一半的流程，怎么逆向回去？
作為架構師，不能讓內存抗持久，不能讓硬盤抗壓力，要假設網線隨時會斷、硬盤可能會壞，這些都是軟件系統中可能出現的風險點，要提前予以考慮。
一分為二看風險的應對，可以分為風險發生前、風險發生后：在風險發生前，要做詳細的check-list、完善的監控和檢查機制，盡量降低風險發生的概率；在風險發生后，要做有應急處理、要有補償止血方案、要有總結和對應的改進措施，降低下一次風險發生的概率。寶玉老師提到的風險識別、風險量化和風險監控，都是風險發生之前做的事情；風險的應對步驟，是風險發生后的處理措施。在實際工作中，我們還會搞一些故障演練、對抗攻防，這些都是為風險發生后的處理做的演練；我們在工作中會進行嚴格的代碼review、完善的線上變更機制和工具，這些都是為了盡量降低風險的發生概率。
廣告時間
不多說了，很多文章我都讀了不下三遍，另外，留言區也非常精彩，跟同學們學習到了很多，歡迎加入學習。
本號專注於后端技術、JVM問題排查和優化、Java面試題、個人成長和自我管理等主題，為讀者提供一線開發者的工作和成長經驗，期待你能在這里有所收獲。
