BAT都在用的研发效能提升方法论，快来学学

核心目标

效能提升的核心目标：快速高质量的持续交付价值

效能度量

「1. 交付效率」

目标是促进端到端、及早的交付，用最短的时间顺畅地交付用户价值。具体可细分为以下指标：

● 需求交付周期：从需求提出，到完成开发、测试、上线，最终验收通过的时间周期。反映了整个团队（包含业务、产品、开发、测试、运维等职能）对客户问题或业务机会的交付速度，依赖整个组织各职能和部门的协调一致和紧密协作；

● 开发交付周期：从需求被研发团队确认，到完成开发、测试，达到可上线状态的时间周期。反映了研发技术团队的交付速度，依赖需求的拆分和管理，开发团队的分工协作；

● 交付吞吐量：统计周期内交付的需求个数 / 统计周期，即单位时间交付的需求个数。需要注意的是，需求颗粒度要保持一定规则，避免需求大小不统一导致的数据偏差；

「2. 交付质量」

目标是促进端到端高质量交付，避免不必要的错误和返工。具体可细分为以下指标：

● 线上缺陷密度：统计周期内线上或单个版本严重级别Bug数量 / 需求个数；

● 故障恢复时间：线上系统和应用如果发生故障，多长时间可以进行恢复；

● 上线成功率：上线部署成功，上线没有导致服务受损、降级或需要事后补救的比例；

「3. 交付能力」

目标是建设卓越工程能力，实现持续交付。具体可细分为以下指标：

● 发布频率：单位时间内的有效发布次数。团队对外响应的速度不会大于其发布频率，发布频率约束了团队对外响应和价值的流动速度；

● 发布前置时间：代码提交到功能上线的时长。反映了团队的工程技术能力，依赖交付过程中高度自动化以及架构支撑能力；

详细度量指标和方式：

效能实施

任何效能的提升都离不开三个因素：人员、流程、工具。

人员：只有协调好各方的目标和利益，他们才有动力去解决问题。

流程：规范和统一整个研发流程，包括从需求到开发到上线到反馈的整个流程。

工具：引入工具，尽可能多的实现自动化。

沟通：解决信息不流通的问题，任务、协议等更新能够及时反应。

工作思想

用MVP(Minimum Viable Product)的思想来提升研发效能，即用最快、最简明的方式实现一个可用的产品版本。

MVP追求的是“麻雀虽小五脏俱全“，也就是实现的功能点可以很小，可以比较简陋，但是对客户有价值是必需的。保证我们的做的研效工具一定是能解决实际痛点的，虽然一开始的方法可以比较简陋。如果实现的功能暂时对用户暂时没有价值，要等到后面的功能出来才有用，这就不是MVP。

效能困局

「方轮子困局」：迫于赶业务而无法停下来做系统改进提升，尽管提升的技术手段已经存在企业内部。

「竖井困局」：各个环节和部门看上去繁忙而高效，但是总体的效率和响应能力却很低。

「谷仓困局」：内部各自为政，缺乏信任和合作，总觉得别人做的不好，重复造轮子

效能范围

研发效能的提升涉及到研发过程的方方面面，流程的规范、工具自动化等每一步的提升都能提升整体的研发效能。

效能难题

做效能提升经常遇到的问题是，做出来的工具没人用，流程规范很难推广，怎么解决这些问题：

1. 「解决用户的痛点」：做的东西一定要是充分了解过用户的需求和痛点才做的，要能够解决用户的痛点，而不是自己假想出来的需求，想当然的去做的。
2. 「自己使用」：可能很多开发做出来的东西自己都没有使用过，就让别人去用。自己都没用过的东西，别人又怎么会使用呢？首先要自己用起来才知道真的好不好用。
3. 「实践总结」：好的工具也需要一些使用指南才能发挥出最大的价值，所以经常总结一些用户的最佳实践和使用方法论可以吸引更多的用户，也有助于别人更好的使用。