新的一年，相信很多产品技术团队都把研发效率的提升列为重要目标，有的团队甚至为此成立了专门的项目组。然而，很少有人能表达清楚什么是好的研发效率。标准不明确，谈何改进？阿里研发效率部资深技术专家何冕老师将多年的思考和见解分享给大家，希望对大家有所启发。本文将对研发效率进行明确界定，并提供五大衡量指标，明确研发效率提升的目标，衡量提升的效果。本文也是提高研发效率和产品交付方式系列文章的第一篇，为后面介绍的产品交付方式是否有效树立了标准。效率孤岛是研发绩效提升的一大难题。产品交付需要前后台功能（如产品、开发、测试等）和平行部门（如前端、后端、算法等）之间的协作。传统方法更侧重于跨职能和部门的独立改进。然而，过度的局部优化往往会导致效率孤岛并损害整体效率。什么是效率孤岛？上图描述了传统开发方式下产品交付普遍面临的困境——各个职能部门的本地优化带来了一系列问题，例如：工作优先级安排基于本地信息，导致不同部门和职能各自等待另外，使得需求流动不畅。例如，前中后台的优先级不一致，进度无法对接，导致已经开始的需求无法及时交付。批量工作交接带来更多的等待。为了优化单个环节的效率，各功能倾向于分批接受和交接工作，如分批集成、分批转移测试等。进一步造成流程中需求的积压和等待。跨部门的问题往往得不到及时有效的处理。公共环境维护是影响用户需求顺利传递的典型问题。有效的跨部门需求厘清、接口对齐、流程中的故障排查等都是阻碍需求顺利推进的公共问题。以上只是一些问题，它们是共同作用的。结果是：从自己的角度看，每个部门都觉得自己很忙，很“有效率”；但是，从大局和业务来看，系统对外响应非常慢。这就是所谓的效率筒仓。效率孤岛：局部优化造成的，表现为：各个环节、各个部门都在忙碌、“高效”，但整体效率和响应速度却很低。是研发效率提升的共同症结所在。上图中的虚线反映了各个需求在效率孤岛中的交付过程。绿线表示正在处理请求，红线表示请求待处理。工作量不大，但前置时间很长。因为大部分时间需求都处于等待状态。每个部门都很忙，但外面却充满了抱怨。相信很多人都会有同感。“持续快速交付价值的能力”是效率提升的核心目标。提高研发效率，必须走出效率孤岛。为此，组织必须将改进的重点从关注单个资源链接转移到关注整个系统。上图体现了效率提升的关键——从以本地资源效率为核心到以价值流效率为核心提升的转变。资源效率是指各个环节的资源利用率和产出情况，如：资源繁忙程度、使用情况、代码产出、测试执行速度等。流动效率是指用户价值在系统中的流动速度，如：用户需求从提出到交付的时间，越短越好；或者进程中等待时间的比例，越小越好。用户价值的流动是连接整个系统、促进整体优化的唯一选择。为了提高价值的流动效率，组织必须关注用户价值在系统中端到端的流动过程，从整个系统的角度进行改进，而不仅仅是局部环节。基于此，绩效提升的目标是：持续快速交付价值的能力。这也是R&D有效性的基本定义。持续快速交付价值的能力是研发有效性的核心定义。为此，我们必须将提升重点从局部资源效率转移到价值流动效率上，以确保整体和系统优化。研发有效性的衡量——五组指标回答了研发有效性的基本问题以上定性定义了研发有效性。管理学之父德鲁克说：“如果你不能衡量它，你就不能改进它。”指标帮助我们更深入地了解研发效果，设定改进方向，衡量改进效果。产品开发过程中会产生很多数据，但数据不是衡量标准。一个很好的指标是：它讲述了完整的故事来回答一个基本问题。绩效衡量要回答的根本问题是：组织“持续快速交付价值的能力”如何？应该提供什么样的完整故事来回答这个问题？基于在天猫新零售、闲鱼、优酷、阿里健康、研发中心、阿里云等部门的不断实践和探索，我们开发并验证了系统的研发绩效指标体系。如上图所示，它由5组指标组成，分别是：第一：持续发布能力。具体包括两个细分指标，即：发布频率。团队对外响应的速度不会大于其交付频率，而发布频率制约着团队的对外响应和价值流动速度。它的衡量标准是单位时间内有效释放的次数。Releaseleadtime（也称为changeleadtime），即从代码提交到功能上线的时间，反映了团队发布的基本能力。如果时间成本高，不宜增加发布频率。第二：需求响应周期。具体包括两个细分指标，即：交货周期。是指从用户提出的需求被确认到需求发起的平均耗时。反映团队（包括业务、开发、运营等）响应客户问题或商机的速度；开发周期时间。指的是从开发团队了解需求到需求可以上线的平均时间。它反映了技术团队的响应能力。区分交付周期和开发周期的目的是解耦和明确问题，以便有针对性地改进。其中，交货周期是最终目标和检验标准。第三：交付吞吐量。指单位时间内交付的需求量。关于这一点，一个普遍的问题是，这个数字是否准确反映了交付效率？这是个问题。所以我们更强调单个团队需求吞吐率的前后对比，这足以从统计意义上反映趋势和问题。第四：交付过程的质量。它包含两个细分指标，即：开发过程中缺陷的产生和修复时间分布。我们希望始终如一地及时发现错误，并在发现后立即修复；错误库存。我们希望在整个开发过程中控制缺陷库存量，使产品始终处于接近发布的状态，为持续交付奠定基础。交付过程质量的核心是内在质量，即全过程、全时间的质量。而不是依赖特定的阶段，比如测试阶段；或特定时间段，例如项目结束。内在质量是持续交付的基础。下面对其具体的测量方法进行详细的举例说明。第五：外部交付质量。它包含两个细分的指标，即：1）单位时间内的故障（在线问题）数量；2）解决故障的平均时间。这两者共同决定了系统的可用性。如上图所示，这五组指标从流程效率、资源效率和质量三个方面完整地讲述了一个故事，回答了组织持续交付价值能力的核心问题。其中，持续发布能力和需求响应周期两组指标，反映价值的流动效率；吞吐率反映资源效率；交付过程质量和外部交付质量两套指标共同反映质量水平。衡量指标示例：缺陷趋势图针对这些指标，云霄提供了丰富的度量图表，后续云霄产品团队会梳理场景，提升易用性。我会及时跟进，用专门的文章介绍完整的云效率衡量方案。这里我先介绍一个例子——关于过程质量的测量图表。“缺陷趋势图”是全新设计的CloudEfficiency指标图，反映了交付过程中缺陷发现和去除的时间分布，以及缺陷的存量趋势。如上图所示，图表的横坐标为日期，横坐标上方的红色竖条代表当天发现的缺陷数量；横坐标下方的绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图的左右部分比较了两种交付模型。左半部分，团队属于Cascade的开发模式。“迭代”初期，团队专注于设计、编码、引入缺陷，没有实时集成和验证。缺陷一直隐藏在系统中，直到项目后期，团队开始集成测试时，缺陷才密集爆发。在级联模型中，过程质量差，导致大量返工、延误和交付质量问题。在这种模式下，产品的交货时间取决于何时可以完全消除缺陷。当然，无法实现持续交付，也无法快速响应外部需求和变化。而且这种模式往往导致后期的赶工，埋下了交付质量的隐患。在右半部分，团队开始向持续交付模型发展。在整个迭代过程中，团队在小粒度的需求中进行开发，不断地集成和测试，实时发现和解决问题。缺陷库存处于受控状态，系统始终处于接近可发布的状态。这种模式更接近持续发布状态，团队对外响应能力增强。缺陷趋势图从一个侧面反映了团队的开发和交付模式。它指导团队始终如一地及早发现缺陷并及时消除它们。控制缺陷库存，使系统始终处于接近发布的状态，保证持续交付能力和对外响应能力。缺陷趋势图是云效率研发绩效衡量图表之一。后面我会专门用一篇文章来系统解读这些图表的使用方法。绩效改进的目标设定：团队2-1-1愿景的一部分以上，我们介绍了研发绩效指标。基于这样的衡量体系，应该设定什么样的目标？在多个团队的实施过程中，我们逐渐沉淀了一个参考目标体系，可以用三个数字来概括——“2-1-1”。“2-1-1”最初来自天猫新零售，后来被闲鱼、研发中心、阿里云等团队完善采用。什么是“2-1-1”？“2”指的是2周的交付周期，85%以上的需求可以在2周内交付；第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内完成开发；第二个“1”指的是1小时releaseleadtime——代码提交后1小时内可以完成发布。[1]实现“2-1-1”的愿景并不容易。1小时的发布提前期需要持续交付流水线、产品架构体系的完善、自动测试、自动部署等能力。1周的开发周期涉及到更多的能力和实践，例如：需求拆分和管理、开发团队分工协作、持续集成和持续测试实践；最困难的是2周的交付周期，首先，它建立在另外两个指标之上，还涉及整个组织的职能和部门之间的协调和密切协作；“2-1-1”的目标都是流量效率，你可能会问，资源效率和质量呢？我们专注于流程效率，因为它是提高组织绩效、触发深度和系统改进的杠杆。如上分析，为实现“2-1-1”目标，团队需要在技术、管理、协作等方面进行全面的实践升级，而这些实践的实施必然带来资源效率和质量的提升,并反映到相应的指标上。当然，“2-1-1”来源于特定的球队，并非所有球队都必须使用相同的数值。例如，对于涉及硬件开发的团队来说，两周的交付周期通常太具有挑战性。组织应根据自己的情况设定适当的目标，重要的是它指明了改进的方向。总结本文定义研发效能，指组织持续快速交付价值的能力，可从流程效率、资源效率和质量三个方面衡量。其中，流程效率是提升研发效率的核心着力点，带来系统性、整体性的提升。如上图所示，研发绩效最终服务于组织绩效，必须体现在利润、增长、客户满意度等组织绩效中。同时，研发绩效的提升只有落实到具体的技术和管理实践中才能发生。定义和测量是提高研发效率的基础。相信大家更关心的是提升研发的具体做法和方法。
