研发效能度量的挑战
为了有效应对当前充满易变性、不确定性、复杂性与模糊性的互联网大环境，今年年初京东提出了数字化管理的战略方向，通过数字化的技术和管理模式提升组织绩效。在这个背景下，研发效能的提升就成为了很多产品技术部门今年的重要目标，有些部门专门成立了相应的工程效率团队，期望从组织、文化、技术、流程等方面的优化来促进研发效能的整体提升。
然而，究竟什么是好的研发效能？我们如何定义它？其实很少有人能够表达清楚。虽然本质上都是通过一定的工作来生产（研发）产品，但不同于生产制造行业，软件研发效能的度量其实是相对困难的，原因有以下三个：
1.研发过程中的可视性差
涉及到业务、产品、研发、运维等不同职能，多个团队多种角色协作时，任务处理的进度、队列、瓶颈可能很难清晰观察到，以至于项目管理软件中很多任务的进度百分比可能只有参考意义，实际并不准确。
2. 工作切分的随意性
有时管理者会制定一些KPI来度量团队绩效，但就像那句名言所说：你度量什么，就会得到什么。其实这句话只说了一半，另一半是：只是不一定是用你所期待的方式得到。所谓上有政策、下有对策，由于软件工作切分的随意性，也许把一个需求拆成多个小需求，一行代码拆成多行来写，某些KPI指标就被用非预期的方式完成了。
3. 敏捷研发过程中工作是并行的
随着公司敏捷研发模式的持续推进，我们很难再像传统项目管理模式一样清晰界定软件研发的各个阶段，很多情况下不同需求所对应的开发/测试工作都是并行的，产品也是不断迭代、持续演进的，这也对准确度量造成了一定困难。
现有的研发效能度量方式
随着公司日益发展壮大，各体系加起来已经有数万人的研发队伍，在过往的实践过程中，也逐步积累了一些研发效能度量的习惯和指标，但是这些指标从今天的角度来看，似乎存在一些限制和弊端。
1. 以打卡或工时数据进行度量
在缺少其他度量手段或有效度量指标的情况下，把工作时长作为度量指标似乎是顺其自然的。度量团队成员是否按时在项目中开展工作、工作量是否饱满，其实是从人力资源利用率的角度来看待问题的。而实际上，当局部人力资源过度地优化，会造成大量排队、等待以及频繁的工作任务切换，看上去很高的资源利用率不但无法转化为真实的生产力，反而会伤害端到端的生产效率。
2. 以局部产出（代码行或缺陷数）进行度量
代码行或缺陷数其实是对开发、测试岗位很常见的度量方式。而实际上，如果将代码行的产出作为考核KPI，除了会得到一堆臃肿、难以维护的代码之外没有任何好处；如果将研发过程中发现的缺陷数作为考核KPI，自然会形成开发与测试团队之间的『混乱之墙』，除了增加团队之间的隔阂也没有其他好处。
3. 以敏捷研发过程中的一些概念（如故事点数）进行度量
有些采用敏捷研发模式的团队，在使用每个迭代能完成的故事点数或迭代速率来进行度量和考核，而实际上这只是一种容量规划工具(推测需要多久完成工作)，绝对数值跟团队紧密相关，但无法进行横向比较，否则又会导致大家玩起数字游戏了。
研发效能度量的正确姿势
通过以上分析可以得知，我们对软件研发效能的度量，应当遵从以下两个基本原则：
1. 聚焦在全局指标而不是局部指标
我们要促进跨越职能和功能，在团队内、团队间彼此高效协作。
2. 聚焦在结果产出而不是某阶段工作输出
我们不应对那些看似繁忙但只产出了一大堆无效工作输出的团队或人员进行奖励，而是引导到那些对促进组织达成目标有实际帮助的工作上去。
根据以上原则，我们确定了从全局性出发，以结果产出为牵引的一系列研发效能度量指标。这些指标也反映出了研发效能改进的关键点，即以端到端的流动效率（而非资源效率）为核心。这里的流动效率是指需求（或用户价值）在整个系统中跨越不同职能和团队流动的速度，速度越快则需求交付的效率越高、交付时长越短。当然这并不是只关注流动效率、不关注资源效率（如工时、资源利用率等），而是在确保前者效率足够高的情况下再逐步提升后者，最终追求的是二者的协同优化。
我们把研发效能度量指标分为三个维度，分别是交付效率、交付质量和交付能力。这些指标的提升需要组织进行管理、技术、协作等多方面的系统性改进。
1. 交付效率
目标是促进端到端、及早的交付，用最短的时间顺畅地交付用户价值。具体可细分为以下指标：
● 需求交付周期：从需求提出，到完成开发、测试、上线，最终验收通过的时间周期。反映了整个团队（包含业务、产品、开发、测试、运维等职能）对客户问题或业务机会的交付速度，依赖整个组织各职能和部门的协调一致和紧密协作；
● 开发交付周期：从需求被研发团队确认，到完成开发、测试，达到可上线状态的时间周期。反映了研发技术团队的交付速度，依赖需求的拆分和管理，开发团队的分工协作；
● 交付吞吐量：统计周期内交付的需求个数 / 统计周期，即单位时间交付的需求个数。需要注意的是，需求颗粒度要保持一定规则，避免需求大小不统一导致的数据偏差；
2. 交付质量
目标是促进端到端高质量交付，避免不必要的错误和返工。具体可细分为以下指标：
● 线上缺陷密度：统计周期内线上或单个版本严重级别Bug数量 / 需求个数；
● 故障恢复时间：线上系统和应用如果发生故障，多长时间可以进行恢复；
● 上线成功率：上线部署成功，上线没有导致服务受损、降级或需要事后补救的比例；
3. 交付能力
目标是建设卓越工程能力，实现持续交付。具体可细分为以下指标：
● 发布频率：单位时间内的有效发布次数。团队对外响应的速度不会大于其发布频率，发布频率约束了团队对外响应和价值的流动速度；
● 发布前置时间：代码提交到功能上线的时长。反映了团队的工程技术能力，依赖交付过程中高度自动化以及架构支撑能力；
度量指标详细定义及计算逻辑如下表所示：
目前京东在研发基础设施的相关工具平台中（包括项目管理、敏捷协作、代码托管、持续集成、部署发布、异常监控等）已经沉淀了大量的研发过程数据信息，我们将会通过以上指标的整合/分析，呈现给团队和管理者更真实有效的研发效能数据，促进研发更有针对性的改进提升。
总结
本文从软件研发效能度量的难点出发，指出了一些现有度量方式的限制和弊端，进而提出软件研发效能度量的正确姿势，即遵循 全局指标 > 局部指标、结果产出 > 工作输出 的基本原则。最后，文章给出了交付效率、交付质量和交付能力三个维度的度量指标集合及计算逻辑。
为了提升公司各职能部门协调一致，持续、快速、高质量交付需求或用户价值的能力，我们需要从当前关注资源效率为主的管理思路，转变为以流动效率为核心、兼顾资源效率的管理模式。以上的研发效能结果性指标可以看做量化诊断问题和有针对性进行改进的抓手，这些都是研发效能提升的基础。当然，在结果性指标的牵引下，还需要一系列更为细节的过程性指标，覆盖研发活动各个阶段的微观度量，这些指标我们将会持续梳理并与大家探讨。
后续还将结合具体的研发管理实践（如敏捷研发和看板方法）与工程实践（代码评审、持续集成和持续交付、部署模式等），配合工具平台的固化和落地，进一步整合研发效能提升的方法、技术和实施路径，也欢迎大家与我们共同探讨并开展合作，共同促进研发效能的提升。
