研发效能的完整定义应该是：团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三个方面。简单来说，就是能否长期、高效地开发出有价值的产品。

研发效能的定义

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

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

●更高质量：我们研发的产品是有质量红线、有底线要求的。快速交付给客户有质量问题的功能除了会引发投诉以外没有任何价值。质量是内建的，不是事后检验出来的；

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

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

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

常见的跟研发效能相关的问题：

1）整个研发团队看起来人也不少，大家干活也很辛苦，加班也不少了，但产品发布还是常常延期，上线后产品问题频发；

2）用户需求从需求分析、产品设计、开发、测试最终流到部署，但最终发布的产品与用户需求偏差却很大。

3）产品版本迭代、发布上线时出现大量提交、合并，导致最后时刻出现很多问题，团队成员集体熬夜加班，却将大把的时间花在了等待环境、等待验证上。

4）开发提测质量不好，大量压力聚集到测试这一步，导致代码返工率很高。引入单元测试、代码审查，效果却都不明显。

5）开发人员疲于应付业务，没有精力或者兴趣去精进技术，对 Git、命令行等强大工具的使用仅限于皮毛，士气低迷、工作效率低下。

6）小leader层面天天喊人员不够用，但具体每个人负责的工作模块维度以及投入度不能说出个一二三，大家都在忙什么，大家的时间都投入到哪儿了？

研发效能的误区

1.2.1 常见误区1：迷信单点局部能力，忽略全局优化和拉通的重要性

研发效能的单点能力其实都不缺，各个领域都有很多不错的垂直能力工具，但是把各个单点能力横向集成与拉通，能够从一站式全流程的维度设计和规划的研发效能成熟平台还是凤毛麟角。现在国内很多在研效领域有投入的公司很多其实还在建设，甚至是重复建设单点能力的研效工具，这个思路在初期可行，但是单点改进的效果会随着时间收益递减，企业往往缺少从更高视角对研发效能进行整体规划的能力。很多时候局部优化并不能带来全局优化，有时候还会是全局恶化。

1.2.2 常见误区2：具有普适性的通用研发效能工具其实没有专属工具来的好用

既然打造了研发工具，那就需要到业务部门进行推广，让这些研效工具能够被业务部门使用起来。其实，很多比较大的业务团队在CI/CD、测试与运维领域都有自己的人力投入，也开发和维护了不少能够切实满足当下业务的研发工具体系。此时要把新打造的研效工具来替换业务部门原来的工具，肯定会遇到很强的阻力。除非新的工具能够比老工具好10倍，用户才可能有意愿替换，但实际情况是新打造的工具为了考虑普适性很有可能还没有原来的工具好，再加上工具替换的学习成本，所以除非是管理层强压，否则推广成功的概率微乎其微。即使是管理层强压，实际的执行也会大打折扣，接入但不实际使用的情况不在少数。

‍

1.2.3 常见误区3：用“伪”工程实践和“面子工程”来滥竽充数

如果你去比较国内外研发效能工程实践的差距，你会发现国内公司和硅谷公司的差距还是相当明显的。但是当你逐项（比如单元测试，静态代码扫描，编译加速等）比较双方开展的具体工程实践时，你会惊讶地发现从实践条目的数量来说，国内公司的一点都不亚于硅谷公司，在某些领域甚至有过之而不及。那为什么这个差距还会如此明显呢？我们认为这其中最关键的点在于，国内的很多工程实践是为了做而做，为的是“政治上的正确”，而不是从本质上认可这一工程实践的实际价值。这里比较典型的例子就是代码评审和单元测试。虽然很多国内互联网大厂都在推进代码评审和单元测试的落地，但是在实际过程中往往都走偏了。

代码评审变成了一个流程，而实际的评审质量和效果无人问津，评审人的评审也不算工作量，也不担任何责任，这样的代码评审能有什么效果，结果可想而知。单元测试也沦为一种口号，都说要贯彻单测，但是在计划排期的时候压根没有给单测留任何的时间和人力资源，可想而知这样的单测是否能成功开展。所以，国内公司缺的不是工程实践的多少，而是工程实践执行的深度。不要用“伪”工程实践和“面子工程”来滥竽充数。

‍

1.2.4 常见误区4：忽略研发效能工具体系的长尾效应

再回到研效工具建设的话题上，很多时候管理团队希望能够打造一套一站式普遍适用的研发效能平台，希望公司内大部分业务都能顺利接入，这和想法的确非常好，但是不可否认的，研效平台和工具往往具有非标准的长尾效应，我们很难打造一套统一的研效解决方案来应对所有的业务研发需求，各种业务研发流程的特殊性是不容忽视的。退一万步说，即使我们通过高度可配置化的流程引擎实现了统一研效解决方案，那么这样的系统会因为过于灵活，使用路径过多而易用性变得很差。这两者的矛盾是很难调和的。

‍

1.2.5 常见误区5：盲目跟风

再来看看一些中小型研发团队，他们看到国内大厂在研效领域不约而同的重兵投入，所以也会跟风。他们往往试图通过引进大厂工具和大厂人才来作为研效的突破口，但实际的效果可能差强人意。大厂的研效工具体系固然有其先进性，但是是否能够适配你的研发规模和流程是有待商榷的，同样的药给大象吃可以治病，而给你吃可能直接丧命。很多时候研效工具应该被视为起点，而不是终点，就像你买了一辆跑车，你依旧不能成为赛车手。

‍

1.2.6 常见误区6：迷信外部专家

引入大厂专家其实也是类似的逻辑，我常常会被问及这样的问题：“你之前主导的研效提升项目都获得了成功，如果请你过来，多久能搞定”？这其实是一个无解的问题。一定程度上，投入大，周期就会短，但是，实施周期不会因为投入无限大而无限变短。我可以帮你避开很多曾经踩过的坑，尽量少走弯路，犯过的错误不再次犯，但是，适合自己的路子还是要靠自己走出来，拔苗助长只会损害长期利益。

‍

1.2.7 常见误区7：忽略开发者的体验

研发效能的引入应该以不影响开发者当前的效率为前提，不应该给开发者增加额外的负担，否则很容易失败。忽略开发者的体验，忽略人在研发过程中的主观能动性，必然会带来低效的结果。

‍

1.2.8 常见误区8：研效度量的罪与罚

最后再来看看度量。研发效能的度量一直以来都是很敏感的话题。科学管理时代我们奉行“没有度量就没有改进”，但是数字时代这一命题是否依然成立需要我们的反思。现实事物复杂而多面，度量正是为描述和对比这些具象事实而采取的抽象和量化措施，从某种意义上来说，度量的结果一定是片面的，反映部分事实。但没有银弹，也没有完美的研发效能度量。数据本身不会骗人，但数据的呈现和解读却有很大的空间值得探索。那些不懂数据的人是糟糕的，而最最糟糕的人是那些只看数字的人。当把度量变成一个指标游戏的时候，永远不要低估人们在追求指标方面“创造性”，总之我们不应该纯粹面向指标去开展工作，而应该看到指标背后更大的目标，或者是制定这些指标背后的真正动机。

‍

1.2.3 常见误区3：用“伪”工程实践和“面子工程”来滥竽充数