文章出自：听云博客
风险（Risk）在日常生活中已被人们熟知，特别是在金融相关的行业里出现的频繁非常高，比如说最常见的“名言警句”：股市有风险，投资需谨慎，等等。但是在软件项目的生产过程中却很少有人提及，而软件开发本身是一项充满风险的工作，因为我们的全部工作都笼罩着不确定性。回想一下以前糟糕的项目和那些担惊受怕、如履薄冰的日子，就好像身边有一堆随时都有可能爆炸的炸弹或者是一头熊。
荒野猎人（The Revenant）剧照
以上这些心理活动都来自于对不确定性的畏惧，担心在未来发生的某一件事会带来不好的结果，这就是我们对风险最基本的感受。
风险是相对某有机体的，指某可能发生的事件，如果发生，能阻碍有机体的发展，甚至走向衰亡，风险是指事件发生与否的不确定性。 --维基百科
风险是客观存在的，是不可能完全消除风险。风险是偶然的，对于个别事件来讲，对于大的群体而言，在某一时间风险的发生又有其规律性，那么风险是可以通过概率推测。
风险管理
想要摆脱那些让人忐忑不安的日子，祈祷历史不再重演，就必须控制它，把危险发生的概率降到低或减少其带来的不良影响，这个管理过程就叫风险管理。
风险管理会鼓励你明确地考虑不确定性。风险的识别会让你看到潜伏在预定交付日期四周的不确定因素，风险的预测会帮你量化不确定因素，锁定核心目标，风险的处理能化解问题带给你的压力。
风险的识别
或许我们都不擅长识别风险，但我们踩过足够多的坑，犯过足够多的错误。这些已经发生的问题，就是今天的风险。这个公式能够帮你开始实施风险管理。例如每年的招聘季，就会因为几名关键员工的离去使项目陷入困境，或者每次遇到流量增加，系统就会出现性能瓶颈，把研发和运维的同学搞得焦头烂额，最终只能通过频繁重启来应对，等待研发同学的下一次迭代。那么“人员流失”和“性能瓶颈”就应该进入新项目的风险清单。
事后分析本身不算什么新鲜事，新鲜的是将事后的分析过程的输出作为风险管理过程的输入。应该组织一场头脑风暴，将大家以前碰到的问题、犯过的错误、发的牢骚收集起来，制作一份风险清单，差不多就能获取足够的数据。
事后分析
当然，事后分析只是风险信息的来源之一，除了利用这些数据，还需要一个风险发现过程。常用的方法是通过三个倒推的步骤来识别风险，如下图表示的就是风险识别的详细过程。
风险识别详细过程
当灾难实际发生，这三个步骤将以相反的顺序出现：根源演变成可能导致灾难的情景，最终变成我们不愿意看到的后果。例如下面的场景，吞吐率的变化会影响到应用的响应时间，也会影响到Web应用过程的墙中时间比。假如用户请求增多，有可能导致某些Web应用过程响应时间变长，甚至导致服务器资源耗尽。那么及时识别和处理用中的性能隐患，并制定相关的缓解措施和应急措施，就会降低技术风险具现的几率。
数据来自于听云Server Demo
先简单列举几个软件开发过程中会遇到的风险分类：
•商业风险，与管理或市场的约束相关的风险。例如：本产品对公司的收入影响；公司高层对本产品的重视程度；交付产品与其他产品的兼容性；产品缺陷所造成的成本消耗等。
•技术风险，与采用项目组成员不熟悉的技术而产生的相关风险。例如：本公司以前没有用过的技术；客户要求建立新的特殊算法或输入、输出技术；技术债务堆积；用户群体高速增长带来的系统压力等。
•资源风险，与参与工作的软件工程师的总体技术水平项目经验以及人数相关的风险。例如：没有足够的人员可用；开发人员不能自始至终参与整个项目或迭代；开发人员没有接受过必要的培训；人员流动频繁等。
•非系统风险，包括政策、领导决策、既得利益、管理、进度、成本等非项目内的风险。例如：管理人员经验不足，对项目控制力度不够或控制过度；不能在预期的时间范围内完成任务；项目投入超出预算范围等。
风险的分析
有了这份风险清单之后该做什么，就是要对清单里每项风险进行评估和衡量，进而确定各项风险发生的概率和强度。风险分析应当从三个风险参数入手，根据具体情况主要确定风险发生的概率、风险的严重程度、风险发生的时段。
风险发生的概率是指风险发生的可能性，可将其量化为1-3个等级。
风险影响程度是指风险发生时，从进度和技术目标两方面可能产生的综合影响。其量化评价可划分三个等级（可根据具体情况自行定义）。
发生时段是指项目的完成时间跨度、风险的发生时间，解决风险的准备时间（可根据具体情况自行定义）。
最终通过风险参数计算风险优先级别，风险优先级别计算公式为：
风险优先级别=风险发生概率（量化值）* 风险严重程度（量化值）*发生时段（量化值）
风险的处理
对于一项风险我们有四件事情可以做：
•可以远离它
•可以包容它
•可以缓解它
•也可以躲避它
如果你不参与面临风险的项目或者项目中面临的风险，你就远离风险。同时，远离风险也就意味着放弃挑战风险所能获得的利益。
所谓包容风险，是指愿意承受风险带来的损失。在实际工作中，仅仅包容某一项风险并没有太大的意义，必须同时包容完整的一组风险。
缓解风险，是指在风险变成问题之前采取一系列方法，以降低最终包容风险所需的成本。
如果前面提到的三件事都没有做，而风险也恰巧没有带来损失，你就成功地躲避了风险。前三种都需要一定的成本，而躲避了风险，它确不会有任何成本。比如说，你担心关键员工会离开公司，但他们没有；你担心粗糙的用户界面会吓坏用户，但他们什么也没有说。你担心这些，但什么都没有做。尽管结果很Happy，但实际上没有进行任何的风险管理。
最终我们还是要为每一项风险制定相应的缓解计划和应急计划。对于风险优先级别小于12的可以不制定计划，对于风险优先级别大于12的需要制定缓解计划和应急计划，并指定该计划的启动条件和启动准则。
•缓解计划，在适当的时间启动，可以降低风险发生概率、减少风险发生带来的影响或推迟风险发生时间的措施。常用的缓解措施有：增加人员、增加技术预研、培训、自我学习、代码审查等、同行评审。
•应急计划，风险发生时采取的行动，以处理风险发生带来的影响。常用的应急措施有：修改计划、降低需求、版本回滚等。
总结
以上是对软件项目中风险管理的一些简单介绍，尽管风险不能完全消除，但如果给予风险高度的重视和投入，身边的那头熊会变成下面这一只。
Ted and LEO 图片来自于网络
参考
•《与熊共舞》
•CMMI L3
附录
风险监控表
