前几天转发了一篇关于变更和质量风险的文章，公众号后台有位同学留言问了这样一个问题：最大的难点是影响范围不好评估，这也是目前业界的共同痛点，有没有一种产出比较高的影响范围评估方法来控制变更带来的风险。
从我的角度来说，风险是随时都可能发生的。对于可控的风险，我们要尽可能把控这种风险带来的影响，比如变更；对于不可控的预料之外的风险，除了不断提升应对风险的能力，提高应急响应能力，其他的只能祈祷运气。
这篇文章，聊聊质量保障工作的一个潜在内核：控制风险。
风险都是来自哪里？
从软件工程的角度来说，一个软件产品的生命周期，大致要经过需求-设计-编码-测试-运维-交付六个阶段，其中每个阶段都隐藏着潜在的风险。比如：
- 需求：需求描述不清晰，逻辑存在漏洞，需求预期目标制定不合理；
- 设计：设计和需求有出入，技术方案实现难度较大(延期)，技术方案存在性能/安全风险；
- 编码：编码不符合研发规范，没有code review，代码合并夹杂私货，接口约定和数据没有做冗余设计；
- 测试：漏测、测试用例覆盖率不足、回归测试未覆盖主流程、To C业务未做兼容测试、上线后没有线上巡检；
- 运维：代码合并打包失败、参数配置错误、线上发布缺少完善的监控告警和应急措施；
- 交付：上线后没有业务校验、缺少线上监控、应急手段匮乏、缺少应急预案和持续复盘优化机制；
如何理解控制风险？
软件工程的本质，是聚焦软件质量，控制软件研发交付过程中的风险，这就是质量保障工作的内核。理想状态下，如果一切都按照设计和预期来百分百完美执行，那风险只存在于理论中。但执行是参与其中的人来做的，由于每个人的工作能力、状态、理解能力、团队协作能力各不相同，就产生了偏差，有偏差自然就有了风险。
所谓控制风险，其实就是通过一系列手段来对执行人不可预估的偏差进行控制，缩小不可控的范围以及带来的影响，进而保障软件的质量。
为什么管理比执行的薪资高？并不是因为他学历高或者工作年限更长，而是他的领导力更好。所谓的领导力其实可以理解为管事的能力，或者管理执行事项的人的能力。在这之外，所谓的技术和经验只是锦上添花。技术来自于实践，经验来自于不断把事情做好的积累。
控制风险的常见方法
今年年初给某国企质量部门做内部培训时，我分享的主题是全链路质量保障体系建设，其实就是针对软件生命周期的全流程来开展质量保障工作，其中的内核就是控制风险。
软件生命周期中每个阶段都有风险，那就通过质量门禁在每个环节设定准入准出标准，降低风险流转到下一环节带来的影响。参与项目的每个人技术能力、工作习惯、理解能力各不相同，那就推动质量内建在团队中落地，通过流程规范和卡点确保工作在执行过程中的满足标准。测试环境不稳定，设计和编码阶段存在风险，那就通过测试左移来推动单元测试、code review、分支管理更好的执行。打包部署线上发布存在不足，那就通过测试右移完善监控体系，制定线上巡检和防资损机制，主导复盘和持续迭代优化。
听过部分测试同学的反馈，认为什么质量内建、测试左移右移都没啥用，需求都测不过来，没工夫搞这些。但其实很多时候正是因为没有做质量内建或者说推动时候稍微遇到一些困难就止步不前，才导致了这种恶性循环。
知道和做到是两码事，中间隔着无数的行动。
如何落地质量门禁？
质量内建落地的四要素
聊聊我对质量度量的看法
质量内建实践的八大特质
从TMMI角度谈谈质量度量
测试左移右移，到底是什么？
