选自《软件研发效能权威指南》：
下面介绍研发效能提升过程中常见的六大误区，希望引发大家更多的思考。
1.缺乏系统化的规划
在很多企业中，并不缺少研发效能的单点能力，各个研发领域也都有很多不错的垂直能
力和工具。但是把各个单点能力横向集成与拉通，能够从全流程的角度进行设计和推进，并
将其落地为一站式工具平台的还是凤毛麟角。目前，国内很多公司其实都还在建设（甚至是
重复建设）单点能力的研效工具，这个思路在解决局部问题的初期尚可行，但是单点改进的
效果会随着时间收益递减，后面还是需要从更高视角对研发效能进行整体规划和方案设计。
2.盲目推行一致性
以研发效能工具为例，具有普适性的通用研发效能工具，其实有时候没有专属工具好
用。既然打造了新的研发工具，那就需要到业务部门进行推广，让这些工具使用起来。在现
实中，很多比较大的业务团队在CI/CD、测试与运维领域都有自己的人力投入，也开发和维护
了不少能够切实满足当下业务的研发工具体系。此时，要用新打造的研效工具替换业务部门
原来的工具，肯定会遇到很强的阻力。除非新工具能够比旧工具强很多倍，用户才可能有意
愿替换，但实际情况是新打造的工具因为要考虑普适性，很有可能还没有原来的工具好用，
再加上工具迁移的学习成本，除非是管理层强压，否则推广成功的概率微乎其微。而即便是
强压，实际的执行也会大打折扣，接入但实际不使用的情况不在少数。
3.“伪”工程实践的“面子工程”
从整体情况来看，国内公司与硅谷公司相比，在工程实践方面普遍存在很大差距。但是
当你逐项比较双方开展的具体工程实践时，可能会惊讶地发现单从采用各种实践的数量上来
说，国内公司一点不亚于硅谷公司。那么，为什么差距会如此明显呢？我们认为，其中最关
键的因素在于，国内的很多工程实践都是为了做而做，而不是从本质上认可其实际价值。这
里比较典型的例子就是代码评审和单元测试。虽然很多企业都在推进代码评审和单元测试的
落地，但是在实际过程中往往都走偏了。代码评审变成了一个僵化的流程，而实际的评审质
量和效果无人问津，评审人的评审也不算工作量，迫于时间压力往往草草通过了事。单元测
试也沦为一种口号，都说要贯彻，但是在计划排期时，没有给单元测试留任何时间和人力资
源，这样实施的效果可想而知。因此，真正的差距不是工程实践做了多少，而是实施的深
度。不要用“伪”工程实践和“面子工程”来滥竽充数。
4.忽视上下文而照搬方案
一些规模较小的企业或研发团队，看到国内各研发大厂在研效领域不约而同地重兵投
入，纷纷也开始跟随建设，照搬方案。这些企业往往试图通过引进大厂工具和人才来作为研
效的突破口，但实际的效果可能不能令人满意。研发大厂的研效工具体系固然有其先进性，
但是是否能够适配其他公司的研发规模和流程是有待商榷的，同样的药给大象吃可以治病，
而给小白鼠吃可能会丧命。很多时候，研效工具应该被视为起点，而不是终点。引入大厂专
家其实也是类似的逻辑，笔者常常会被问及这样的问题：“你之前主导的研发效能提升项目都
获得了成功，如果请你过来，多久能搞定”？这其实是一个无解的问题。在一定程度上，投入
大，周期就会短，但是实施周期不会因为投入无限大而无限变短。专家可以帮你避开很多曾
经踩过的“坑”，尽量少走弯路，犯过的错误不再重犯，但是适合自己的路还是要靠自己
走，“拔苗助长”只会损害长期利益。因此，研发效能工作最终能否有成果，还要根据企业环
境和上下文量身定制解决方案。
5.忽视开发者的体验
研发效能工作的开展应该以不影响开发者当前的效率为前提，不应该给开发者增加额外
的负担，否则很容易遭到反弹甚至全盘失败。忽视开发者的体验，忽视作为知识工作者的工
程师在研发过程中的主观能动性，是无法真正提升效能的。
6.不恰当地使用效能度量
研发效能度量一直都是敏感的话题。在科学管理时代，我们奉行“没有度量就没有改
进”“没有度量就无法管理”，但在数字化时代其却要复杂很多。现实事物复杂而多面，度量正
是为描述和对比这些具象事实而采取的抽象和量化措施。从某种意义上来说，度量的结果可
能是片面的，只反映部分事实，没有银弹，也没有完美的效能度量。数据本身不会骗人，但
数据的呈现和解读却有很大的空间。当把度量变成一个数字游戏时，永远不要低估人们在追
求指标好看方面的“创造性”。我们不应该纯粹面向指标去开展工作，而应该看到指标背后更
大的目标，或者是制定这些指标背后的真正动机。