在理想的世界里，事情都是按照我们的计划执行的；在真实的世界里，事情经常会呈现出布朗运动的特性——不按常理出牌。今天我们谈下软件项目管理中的风险管理。
下面这张图，来自软件工程之美的一篇文章——《风险管理：不能盲目乐观，凡事都应该有B计划》
阅读摘抄
- 风险是指不确定的事件，一旦发生，将会造成消极的影响
- 在软件项目的管理，对项目风险的管理才是体现管理水平的地方
- 风险管理最大的问题不是如何做，而是项目成员缺少风险意识，有了风险意识，才能去识别出来项目中可能存在的风险，进而去管理风险。
- 项目中的任务，不能盲目乐观，都要思考下它最坏的结果是什么，如果最坏的结果不能接受，就说明要有个B计划，要考虑风险管理了。
- 风险的处理过程有四个步骤：风险识别、风险量化、应对计划、风险监控，这是一个循环迭代的过程，需要在软件项目中持续进行。
我的心得
正所谓“凡事预则立，不预则废”，软件项目要有计划，做很多事情都要有计划，我一般使用PDCA工作法进行计划。如果事情可以按照计划正常推进，那是最好了，不过，由于各种各样的因素，在事情的推进过程中，会有一些意想不到的事情发生：可能是正面的意外，那就是惊喜；也可能是负面的意外，那就是惊吓了。风险，就是指在事情的推进过程中遇到的负面的意外，有时候人们也称之为“黑天鹅”。
作为开发者，在日常开发中，每一次线上操作（代码变更、配置变更）都有风险；在软件项目中，风险就是指那些让项目无法按时、按质交付的事情。面对这些可能的风险，最好的办法是：建立风险意识、拥抱风险、积极面对、积极处理。
作为系统分析师，在做系统分析和架构设计的时候，除了要设计正常的主业务流程，也需要考虑异常业务流程——出现异常了怎么解决、已经做到一半的流程，怎么逆向回去？
作为架构师，不能让内存抗持久，不能让硬盘抗压力，要假设网线随时会断、硬盘可能会坏，这些都是软件系统中可能出现的风险点，要提前予以考虑。
一分为二看风险的应对，可以分为风险发生前、风险发生后：在风险发生前，要做详细的check-list、完善的监控和检查机制，尽量降低风险发生的概率；在风险发生后，要做有应急处理、要有补偿止血方案、要有总结和对应的改进措施，降低下一次风险发生的概率。宝玉老师提到的风险识别、风险量化和风险监控，都是风险发生之前做的事情；风险的应对步骤，是风险发生后的处理措施。在实际工作中，我们还会搞一些故障演练、对抗攻防，这些都是为风险发生后的处理做的演练；我们在工作中会进行严格的代码review、完善的线上变更机制和工具，这些都是为了尽量降低风险的发生概率。
广告时间
不多说了，很多文章我都读了不下三遍，另外，留言区也非常精彩，跟同学们学习到了很多，欢迎加入学习。
本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。
