1.1 研发效能的定义、目标及解决的问题

核心观点

● 研发效能既要关注有效性，也要关注效率；既要关注投入，也要关注产出。

● 研发效能就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。

● 研发效能需要解决规模化的问题，在软件规模和复杂性不断提升的同时努力保持高效。

1.研发效能的定义

前面已经提到，在近十年间，国内外互联网软件及科技公司享受了信息技术的红利，也推动了公司的飞速成长和在技术和商业模式上的创新。但纵观整个行业，尤其是在国内，我们发现在行业繁荣发展的背景下，很多企业的研发理念和研发模式还停留在“刀耕火种”的原始状态。

当无穷无尽的业务需求如排山倒海般地压向研发，在较短的研发时间和需要快速上线的高压之下，研发人员疲于应对业务压力，技术债高垒、士气低迷、工作效率低下，没有精力精进技术，封闭开发、加班拼抢、手工操作、质量低、大量返工、进度延期、线上问题频发、四处救火的恶性循环似乎已经成为一些研发组织的常态。但无论是追求卓越的企业技术管理者，还是追求成长的一线工程师，显然都不满足于此，总是希望能找到一些新的思路、方法和技术，来帮助他们摆脱困境。于是，在敏捷运动已经发展了二十多年，DevOps运动已经发展了十多年后的今天，研发效能逐渐成为大家关注的焦点。

研发效能在国内越来越火，在各种技术大会、技术分享或微信朋友圈中曝光的频率也越来越高，但是似乎大家对这个新的名词并没有建立统一认知，也并没有一家权威机构或专家给出一个比较清晰、明确的定义，甚至在国外也很难找到直接对标的英文词汇。

研发效能就是特指研发效率吗？是否有其他更丰富的内涵？研发效能的目标是什么？这些看似基本的问题在业界都引发了不少讨论。那么，在介绍研发效能怎么做、如何落地之前，我们先来看一下研发效能到底是什么。

我们做的所有研发工作都是从业务目标出发的，这是我们做一切事情的根本出发点。基于业务目标，我们会规划理想状态下要完成的功能和质量，并且会评估在理想状态下实现这些业务目标所消耗的工作量。理想的功能意味着实现业务目标的最优功能集（没有遗漏任何需求，也没有蔓延出本不需要的功能），理想的质量代表了各种质量属性的水平（包括功能和非功能），并期望以最优的方式满足业务目标的要求。

有理想就有现实，在具体的研发和实现过程中，我们会产出实际的功能和质量及实际工作量，因此，在理想和实际之间就会存在一定的差距。比如，理想是要开发20个功能，实际只实现了15个，而且其中3个还存在一些缺陷，导致功能受损，性能也没有达到预期的高并发要求。再如，预计2周时间就可以完成开发和测试并上线，但实际上技术复杂度超出了预估，最终多花了1周时间才勉强完成功能的实现。

理想的功能和质量与实际的功能和质量之间的差距，我们称之为有效性；理想的工作量和实际的工作量之间的差距，我们称之为效率。有效性关注的是产出的维度，效率关注的是投入的维度。因此，研发效能既要关注有效性（做正确的事情），也要关注效率（正确地做事情并追求速度）；既要关注投入，也要关注产出。

有效性关注的是方向正确，做的事情要有价值，要能够有利于达成业务目标。我们经常说这是一些0之前的那个“1”，没有这个“1”，无论后面有多少个0，即哪怕做得再多、做得再快都没有用。比如，对于软件研发来讲，做什么需求、需求是否定义清晰准确、需求的验收条件是否明确都属于有效性的范畴，需求的价值越高，研发越能事半功倍。

效率也是大家最为关注的话题之一，我们可以通过选择适当的研发模式、制定适当的研发流程、利用高效的研发工具来提升效率，使用系统化、工程化的方法，采用先进的技术架构来研发系统，解决问题。比如，在研发过程中，我们经常提到敏捷精益的协作模式、高内聚低耦合的系统设计、以应用为中心的云原生研发范式、以CI/CD为基础的高效研发流水线等，这些都可以帮助我们高效、高质量地构建所需的软件系统。

综上所述，如果要给研发效能一个定义，我们认为可以这样来表述：研发效能就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。如图1.1.1所示，这里的“更高效”指的是效率，“更高质量、更可靠、更优的业务价值”指的是有效性，当然我们还要关注“可持续”，期望研发效能可以让我们保持持续的有效性和高效性。

2.研发效能的目标

根据上面对研发效能的定义，其目标主要包括以下几点。

● 更高效：更高的效率代表更快、更及时地交付，这样就能更早地进入市场，更早地学习和调整，更早地降低风险，更早地锁定进展和价值。这也是敏捷和精益思想的核心。

● 更高质量：我们研发的产品都有一定的质量要求，快速交付给客户有质量问题的产品除了引发投诉没有任何价值。质量是内建的，不是事后检验出来的。

● 更可靠：我们要的是敏捷，而不是脆弱，安全和合规方面要有保障。就像开车一样，只有车子可靠、刹车性能好，你才敢开得快。

● 可持续：短期的取巧、“快、糙、猛式”和小作坊式的开发，只会带来更多的技术债务和持久的效率低下，软件研发不是“一锤子”买卖，我们应该用“长线思维”来思考问题。

● 更优的业务价值：我们经常说“以终为始”，提供给客户或业务的内容应该是有价值的，这是你为什么要做所有这些事情的根本出发点。

上面的描述是从组织视角出发的，那么，研发效能的提升对我们每个人有什么好处呢？我们认为有以下几点。

● 强调功劳而不是苦劳：不再按加班时长进行排名，而是让大家的目标聚焦在对结果有帮助的事情上，即交付业务价值，着眼点从局部产出过渡到整体结果上。

● 强调更聪明地工作：就是我们常说的“好钢用在刀刃上”，通过一系列对工作流程、协作方式、角色职责、系统架构、技术平台的优化，对工具建设和自动化程度的提升，让大家摆脱冗长、无聊的各类会议和重复、机械的手工操作，把时间花在真正有创造性的事情上。

● 强调个人能力成长：组织要给大家留出一些空闲时间，用于个人的学习和提高，成长的机会也许比晋升和绩效更能吸引人。优秀的企业会注重培养个人的技术能力、软件工程能力和业务领域能力。

组织是由个人组成的，只有个人的效率提升了，能力增强了，整个企业的研发效能才会更好。

3.研发效能需要解决规模化的问题

在很多小团队、小部门或小公司组建的初始阶段，由于系统从零开始建设，沟通路径简单明确，没有技术债务，研发效能普遍是比较高的。但随着时间的流逝、版本的持续更迭、功能的持续完善，小系统变成了大系统，小团队变成了大部门，很多企业在某一天突然发现，研发效能已经变得很差了。其具体表现在，研发人员的规模已经扩张了好多倍，但交付的业务需求量却并没有多出多少，而且内部复杂的沟通路径使得流程效率和最终交付的效率都降低了，客户也越来越不满意。

根据“熵增定律”，在一个孤立系统中，如果没有外力做功，其总混乱度（熵）会不断增加。那么，随着软件越做越大、越做越复杂，研发效能的绝对值一般会随着以下因素的变化变得越来越小，研发效能的鸿沟会越来越大，如图1.1.2所示。

（1）软件架构本身的复杂度提升（微服务、服务网格等）。

（2）软件规模的不断增加（集群规模、数据规模等）。

（2）研发团队人员规模不断扩大引发沟通协作难度增加。

因此，我们对研发效能工作最基本的要求就是尽可能减缓研发效能随熵增恶化的程度，在软件规模和复杂性不断提升的同时努力保持有效性和高效性，“努力奔跑或许只能让我们保持在原地”。

当然，效能的持续提升是我们追求的终极目标，需要不断地尝试和努力，我们一直在路上。