研发效能一文看懂研发效能提升 | 京东云技术团队

京东云开发者 · 2023年09月01日 · 3022 次阅读

1 什么是研发效能？

对于一个企业来说，最大化企业效能是其必求目标，包括：利润、用户规模、客服满意度、运营效率等。对于自有产品研发的互联网公司来说，研发效能是服务企业效能的重要因素。

一个软件研发的完整流程如下图所示：

从需求提出到交付整个流程中交付期望产品的效率和能力，即研发效能。

2 为何要提升研发效能？

下面从宏观和微观两个例子说明研发效能在我们日常需求交付中的影响：

（1）站在各自视角，效率高效；站在全局业务视角，反应迟缓。

上面这张图反映了单个需求的交付过程。绿色线表示需求正在被处理，红色线表示需求在等待中。工作量不大的需求，交付周期却很长，这是因为大部分时间需求都处于等待状态，可能是由于跨部分也可能是因为前、中、后台对工作优先级处理不同，就会导致需求链路局部最优，总体效率不高，相信很多人会感同身受，这已成为产品交付的普遍困境。

（2）API 对接处理

在 API 接口测试过程中，输入参数的临界值没有妥善处理的问题十分常见，比如某个输入参数是 String 类型，但是代码实现中没有考虑 String 变量为 null 的情况。这类问题通常都会在后期调试或者联调阶段才会被发现，此时再去修复的成本就比较高，修复之后还要考虑回归测试的成本。所以我们可以引入一种机制，去主动扫描获取 API 入参类型，根据参数类型生成容易出错的取值，用这些取值自动调用 API，如果发生 500 错误或者抛出异常就是发现了问题，这样问题可以更早暴露出来，也对之后的开发工作提升了一定效率。

通过这两个例子可以发现不论是产品交付还是实际的开发工作，效能改进的目标就是：持续快速交付价值的能力。可以理解为传统的开发方式对团队能够持续为用户产生有效价值的效率发起了挑战，需要通过研发效能着眼于长期效果，改变我们的焦点从局部最优，转向关注用户价值，保证全局和系统的优化。

3 如何度量研发效能？

管理学之父德鲁克说：“如果你不能度量它，就无法改进它”。

评价一个组织或者团队持续快速交付价值的能力，需要一些度量指标帮助我们更加深刻认识研发效能，设定改进方向，衡量改进效果。

效能度量回答的根本问题就是：一个组织 “持续快速交付价值的能力” 怎么样？

任何生产力的提升都离不开三个因素：人、流程和工具，缺一不可。通过下面 5 个具体指标，或许会对这三个因素有更加深入的理解。

第一：持续发布能力。

发布频率：单位时间内的有效发布次数。

发布前置时间：从代码提交到功能上线所花费的时间，体现了团队发布的基本能力。

第二：需求响应周期。

交付周期时间：从确认用户提出的需求开始，到需求上线经历的平均时长。

开发周期时间：从开发团队理解需求开始，到需求可以上线所经历的平均时长。

第三：交付吞吐率。

单位时间交付用户需求数量：单个团队在单位时间内交付需求的数量。

第四：交付过程质量。

缺陷创建和修复时间分布：缺陷能够持续和及时的被发现，并在发现后尽快修复。

缺陷库存：开发过程控制缺陷库存量，让那个产品始终处于接近可发布状态，这是持续交付的基础。

第五：交付质量。

无论是单位时间问题数目还是线上问题解决时长都是在强调系统可用性。

这 5 组指标，来自于阿里资深技术专家团队提出，从流动效率、资源效率和质量三个方面讲述了一个完整的故事，回答了组织持续交付价值的能力如何这个核心问题。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。

4 如何提升研发效能？

首先来看一个问题：为什么现在各大互联网公司都开始关注 “研发效能”？

软件正在吞噬世界。过去 20 年互联网从无到有，未来，任何一家企业的业务都会构建在互联网的基础上。软件交付能力成为企业的核心竞争力，研发效能成为企业的共同挑战。

一方面，随着竞争的加剧，业务对研发效能的期望越来越高；另一方面，随着互联网向产业纵深的发展，产品和协作的复杂度越来越高，研发效能有下降的趋势，这是期望和理想的差距，也是研发效能提升必须要解决的问题。

在推行研发效能的早期阶段，通常可以采用自上而下的策略，从一个工程实践中的实际痛点小事入手，以解决问题为提升研效的目标，这个阶段我们追求的是 “短平快”，问题逐个击破。这些问题包括但不限于：

本地编译时长消耗大
本地测试困难，测试环境准备复杂且耗时
自动化测试用例维护成本高
测试数据准备困难
研发后期代码提交集中，缺陷数激增
性能缺陷在研发后期发现，修复成本高
……

进入中后期阶段，回到软件研发领域，从全局切入进而优化工作。在引入敏捷解决方法之前，先来看一个度量图表：

上图中，横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。

左半部分，即小瀑布开发模式。在迭代前期，团队集中设计开发，引入缺陷，但为及时验证解决。缺陷一直隐藏在系统中，直到后期测试和集成阶段，缺陷集中爆发，带来大量的返工、延期和交付质量问题。

右半部分，即持续交付模式。在整个迭代过程中，团队以小粒度需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库得到控制，系统始终处于接近可发布状态。

实际上，持续交付模式与敏捷开发原则十分相近，敏捷=价值观 + 原则 + 一系列符合价值观和原则的方法。敏捷团队迭代周期为两周，通过透明、协作、有纪律性的持续改进，是的如那件一直处于可工作状态，每个迭代都能将软件部署到类似生产环境中，并向用户演示。通过敏捷方法，可有效避免 “小瀑布” 问题，按照需求粒度优先级排序，将需求拆分为能够独立测试的需求，在整个流程中发现问题可以及时解决并进行复盘总结。

从个人角度来看，必须从实际出发，从原则出发，从个人转变为关注价值流动：待开->设计->开发->开发自测->代码评审->测试->完成。不断地学习新的开发技能，从而提升自己的开发效率。

从团队角度来看，团队文化是团队成员共同认可的价值观和行为准则，良好且有效的文化是保障团队高效产出的关键部分，文化价值观的贯彻执行是保证一个敏捷团队高效工作的制胜宝典。当然，任何措施若涉及个人利益，必然会有坏味道产生，只能看这个措施是否能引导团队往正确的方向走，是否利大于弊。

感谢阅读。