在软件开发过程中，我们会遇到不同的变化，代码更新，新功能编写，架构调整，系统扩展。每天都有大量的需求、代码和bug需要处理。事实上，我们所做的每一个影响系统的行为背后都有风险。那么我们如何评估和管理这些风险呢？任何项目经理或领导者都需要知道下面提到的方法。
定义风险。
每个人都知道做任何改变都有风险。例如，一个新功能模块的发布会影响几个旧的功能模块，那么管理者如何在线评估这个新功能的风险呢？下面是一些方法。
第一，直觉，说起来有点搞笑，其实是基于有经验的程序员和架构师(老司机)的感受来评估这个变化的风险。这种方法在各种互联网/软件公司已经存在很久了，基本都是靠老人带大家去坑。这种方法虽然常见，但缺点也很明显，就是要看个人能力，而且随意性大，一旦个人判断失误，就真的掉坑了。
第二，红绿灯法。或者只是一个新功能的例子。我们可以列出受新功能影响的旧功能模块，并评估每个功能模块的“红、黄、绿”灯。绿灯=低风险，黄灯=中风险，红灯=高风险。然后通过团队和专家评审，判断这个新功能上线的风险。这种方法的优点是降低了感知风险，使风险具体化，并引入团队评审的方式，使结果更加客观。
第三，失败模式和影响分析(FMEA)。这样，一个功能模块会被分成几个组件，然后对每个组件进行三维评分。这三个维度分别是:故障的可能性、故障的严重程度和故障检测能力的高低。这三个维度都可以打分，分值从1到9不等。分数越高，风险越高。我们通常按照三个等级来划分分数:高风险:9分，中风险:3分，低风险:1分。小伙伴可以根据自己的群体设定不同的分数。例如，如果我们有一个登录服务，可能会有“为用户设置错误权限”的风险。因为这个权限设置是系统管理员设置的，所以失败的可能性比较低，我们给它打1分(低风险)。一旦这个权限设置错误会导致用户看到不属于自己的信息，这个故障的严重程度非常高，我们评级为9分(高风险)。我们可以通过后台脚本对这个故障检查每个用户的权限，所以故障检测能力的等级是中等，所以给3分(中等风险)。这样我们就可以把三个维度的分数相乘得到1*9*3=27。如果该登录功能包含其他组件，则类推评估每个组件的风险分值，然后相加即为该功能的风险分值。如果要降低失败的风险，就要根据这三个维度采取相应的预防措施。比如后台定期监控用户的权限，如果第一时间发现用户和权限被隔离，通知客户部向客户解释，将风险降到最低。如果我们这样做，我们将把故障严重程度的风险分值从原来的9分降低到3分，因此总分值为1*3*3=9分。风险得到控制了吗？在这里，你可以为每个团队设计一个风险表格，记录所有风险。
管理风险
如果可以定义风险，那么风险管理需要两种主要类型的风险，第一种类型的急性风险和第二种类型的总体风险。
急性风险管理，往往针对一个或多个功能点的变更，整个实施不会花太长时间。这里需要对变更进行分解，然后用上面介绍的FMEA进行风险评估，为每个组件的风险等级设置容差值。最后形成急性风险管理表，使实际风险的分值必须在风险等级的范围内。
全面风险管理，
这里要改变的范围比较大，持续时间比较长，未知因素和风险就更加不可控。在此，建议将急性风险管理组成部分的风险水平与持续时间的风险评估相加。将为每个变更持续时间设置
风险级别
的容许分数。
但是日常工作中总会有特殊情况，比如一些急需改变的功能，高风险高回报。此时，技术总监、架构师、CTO和业务总监也有一些
风险等级分数，用来调整表中的最大允许风险等级。说白了，关键人物参与风险评估的话，在线推送紧急变更。
总结:今天，我们学习了三种风险评估方法，并推荐FMEA方法对变化进行拆分、评估和评分，以降低个体风险。提出了应急风险管理和分类风险管理的分析方法。
本文来自年轻人玩的就是心跳投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/632005.html
微信扫一扫 
