近几年关于降本增效的话题越来越热，无论是各技术大会还是企业内部，关于降本增效的讨论和实践越来越多。比如研发效能、质量度量、精细化运营等，其本质都是在尽可能降低成本投入的前提下，提升生产效率，以求获得更高的投入产出比，企业获得更大的利润。那降本增效该如何在企业内落地呢？要达到降本增效的目标，又面临哪些挑战？这篇文章，我想聊聊我对于降本增效的理解和自己的一些实践案例。
降本增效面临的挑战
从软件工程角度来说，影响质量的三要素是范围、时间和成本。 
降本增效拆开来看，降本就是降低投入成本，增效就是提升效率，但成本和效率之间本身就是一个互相制约的关系。这里要明白的一点是，增效并不是一个绝对值，而是相对值，如何理解呢？
- 假设单位时间内投入成本不变，那提升单位时间内的产出，效率值更高；
- 假设单位时间内产出不变，那降低单位时间内的投入成本，效率值也高；
降本增效的目标是尽可能降低成本投入的前提下，提升生产效率，并保障最终交付质量在水准线之上。这里有个前提就是交付质量是不能降低的。以上图为例，我们可以得到如下几点降本增效要面临的挑战：
- 假设范围不变，提升效率意味着要增加成本投入；
- 假设成本不变，提升效率意味着要缩小需求范围；
- 假设时间不变，提升效率意味着要牺牲交付质量；
综合这三点挑战，我们可以得到一个结论：在保证交付质量不变的前提下，要达到降本增效的目标，需要在范围、时间、成本这三者之间找到一个平衡点，并根据具体情况动态调整优先级和资源配置。
测试团队如何降本增效
对测试同学来说，质量是团队的安全线，也是最高目标。在保障交付质量的前提下达到降本增效的目标，我个人认为可以分为短期和长期两个阶段来开展实践。
短期改进
如上面的内容所述，成本和效率是互相制约的。要达到降本增效的目标，短期要做的改进大概分为如下几个方面：
- 度量：要达到降本增效的目标，首先要有一个对比，即首先要知道当前的成本投入和效率是多少，识别其中的低效率和高成本环节，然后才能制定对应的改进方案。这也是为什么近几年所谓的质量度量、研发效能度量很火热的原因之一。当然，度量的结果只是作为一个评估当前状况的参考值，仅对后续的改进方法提供参考，但绝不是唯一指标。
- 工具：要想短期内提升效率，一个不是捷径的捷径就是改善工具。比如以前接口测试都是手动执行，提升效率则可以采用自动化的方式；以前准备测试数据都是手动写SQL去一条一条插入数据，提升效率则可以考虑流量录制或者通过存储过程的方式去预埋数据，这样效率也会提高。当然，工具的优化势必意味着需要投入一定的额外成本，短期内成本也会上升，但长期来说，工具改善后带来的效率提升是更高的。
- 轮子：造轮子这件事大家都懂的，毕竟事关KPI和向上管理。但团队大了，轮子多了，其实就是一种功能重叠和额外的资源浪费。造轮子需要投入资源，维护轮子需要资源，且很多轮子在功能上是重叠的。因此短期内要降低成本，砍掉重复的轮子就是一种很现实的方案。当然，砍哪些轮子，如何整合资源，需要评估分析。
长期投入
除了短期可以见效的一些方法，降本增效更多的是一个长期投入持续迭代优化的过程。以一个版本迭代为时间周期，低效且高成本的环节，最常见的有如下几种情况：
- 需求不明确、需求频繁变更、临时插入需求；
- 提测质量差、编译打包失败、服务发布报错；
- 服务经常挂、服务频繁发布、测试数据不可用；
- 大量的会议、沟通确认信息、跨部门资源协调；
在日常工作中，其实真正的编码和测试所耗费的时间并不多，更多的时间耗费在了确认需求、需求变更带来的返工、服务报错排查定位、准备测试数据、以及各种各样的沟通协调和会议中。因此在长期投入改进方面，可以从如下几个方面入手了达到降本增效：
- 测试左移：加强需求和设计阶段的评审和风险评估，准备应对风险的冗余方案；需求实例化；
- 质量门禁：推动软件研发交付各阶段的质量门禁，做好质量卡点，比如提测冒烟、单元测试等；
- 质量内建：通过流程规范宣讲以及以身作则的带头实践，要求各个角色实时对软件的质量负责，减少因为前期风险不可控而导致后期的修复成本增加，进而浪费大量资源；
- 环境治理：测试环境的稳定性是一个被大家忽略的环节，但这是我们所有测试活动开展的基础。可以通过规范变更流程、打通底层数据、变更权限收口、环境容器化、stable环境等手段来提升测试环境的稳定性，降低环境不可用带来的时间浪费和排查问题带来的成本。
