1.4 研发效能的核心价值观与常见误区

核心观点

● 研发效能需要践行其核心价值观：以业务价值为导向、优化全局流动、追求工程卓越、善用数据思维。

● 研发效能提升过程中的常见误区包括缺乏系统化的规划、盲目推行一致性、“伪”工程实践的“面子工程”、忽视上下文而照搬方案、忽视开发者的体验、不恰当地使用度量。

研发效能的成功落地与实施离不开原则性的指导，下面重点探讨研发效能的几个核心价值观，以及落地实践过程中的常见误区。

1.4.1 研发效能的核心价值观

1.以业务价值为导向

研发效能工作的开展必须以业务价值为导向。效能是为业务价值服务的，而效率更多的是为职能目标服务的。可以说效能是方向，效率是速度，如果方向错了，速度再快也没用，这就是我们经常听到的“高效交付无法确保业务成功”背后的原因。

效能是做能让你更接近目标的事，而效率是以尽量经济的方式完成特定任务。“思辨胜于执行”本质上也表达了类似的思想。思辨即思考辨析，其结果是指导思想。执行，即贯彻施行指导思想。可见，思辨决定了执行的方向。思辨对于研发团队生产力的提升，首要的就是寻找“正确”的需求。对于一个需求到底要不要做，多花点时间研究是值得的，因为一旦一个需求决策形成，其成本都是几十倍甚至上百倍的增加。产品经理一个决策的背后是研发、测试、运维团队的大量工作。

当业务处于快速上升期时，需要的是更快地进行业务交付，此时也许可以采用“堆人、堆时间”的方式来解决短期效率不足的问题，技术上可以选择先主动负债（不求完美只求能用），在这个阶段“快、糙、猛”的研发模式其实是有效的，这恰恰体现了“以业务价值为导向”的价值观。但在业务成熟、规模扩大之后，业务价值的导向就会发生变化。一方面用户群体规模已经变得非常庞大，高质量和业务稳定与业务连续性成为主要矛盾；另一方面随着团队内耗（随机复杂性）的不断增加，此时就要解决技术债和工程能力的问题。由此可见，在业务发展的不同阶段，对业务价值的追求方式是不一样的，提升研发效能的路径也不同。

2.优化全局流动

流动是精益思想的五大原则之一，是精益思想的关键部分，其目标是让价值不间断地流动起来。在软件研发场景中，全局流动的含义是聚焦IT系统的整体价值流，进行全局优化，从而确保价值从上游到下游的快速流动。局部优化一般是指针对研发过程的某一部分或某个环节，通过一些管理或技术手段进行调优，这虽然也带来了局部效率的提升，但是从整个研发过程来看，其效果可能只是很小的一部分。

在研发效能提升的初期，局部优化是有用的，如静态代码扫描的耗时从5分钟缩短到1分钟以内、测试环境部署时长从几十分钟减少到5分钟以内等，但是局部优化的效果会随着时间的流逝递减。在进入深水区后，能够带来效率大幅度提升的往往是对全局流动的优化。

在软件研发中，经常使用的度量指标是流动效率，即在软件交付过程中，工作处于活跃状态的时间（无阻塞地工作）与总交付时间（活跃工作时间+等待时间）的比值。有资料统计，很多企业的流动效率只有不到10%，也就意味着需求在交付过程中的大部分时间里处于停滞、阻塞、等待的状态，以至于看似热火朝天的研发工作，很可能只是虚假繁忙。大家只是因为交付流被迫中断才切换到其他工作，从而并行开展了很多不同的工作而已，但从业务和客户的视角来看，研发的交付效率其实很低。在很多情况下，优化全局流动带来的改进效果是非常巨大的，常常远远大于局部优化带来的效果。

有时候，过度的局部优化还会带来全局劣化。比如，过度优化某个职能部门的人力资源利用率，就是一种局部优化，其从传统的、以资源效率为中心的角度来看可能有一定价值，但这样高的资源利用率势必会造成研发交付过程中多个部门之间协作效率的降低，用户的需求总是要等待排期，无法被及时处理，这样全局的流动效率就会受到非常大的影响。因此，我们需要站得更高，从全局来分析问题。

3.追求工程卓越

在研发效能领域中，我们经常关注的一个很关键的要素是工具平台。工具平台应该简单、易用，向下屏蔽复杂的实现，向上提供易于使用的能力，在不增加工程师学习成本的前提下，默默地优化研发过程的各个环节，提升整个工作的效率。在一定程度上，工具平台体现了“成全别人（用工具的人），死磕自己（工具开发者）”的设计哲学，但是工具平台并不是效能提升的全部，拥有工具和拥有能力是截然不同的两件事。很多公司采购了研效工具，就以为已经拥有了这样的能力，其实购买装备只能让你看起来显得专业而已。

我们不能仅仅关注工具，还要追求工程卓越。工程卓越倡导用工程化的方法解决问题，并追求持续优化，达到卓越。工程卓越是内在的能力，需要时间积累；工具平台是外在的表现，可以花钱购买。工具是工程卓越的载体，脱离了工程卓越，工具是没有灵魂的存在。同样的工具会因为用的人不同，发挥的作用存在较大的差异。用一块物理白板外加一些便利贴，同样可以实现真正意义上的敏捷开发，全套的敏捷工具也可以被用作“披着敏捷外衣的瀑布模型”。另外，在工具上“抄作业”是没用的，适合才是最重要的。比如，A公司用某个工具取得了巨大的成功，B公司很有可能会用不起来。

总结来看，两者的关系是工程卓越中的优秀实践可以固化、沉淀到工具中；反过来，工具也支撑了工程卓越的落地，但后者无法取代前者。

4.善用数据思维

在数字化时代，很多销售、财务、新媒体运营等行业已经不依赖于个人经验来做决策了，而是更多地依赖数据。但是数字化程度原本就很高的软件研发行业，有时依然高度依赖人的经验，这点值得我们反思。

经验沉淀固然重要，但过去的成功有可能无法被复制。经验沉淀有些类似于静态思维，看的是过去；而数据思维则更偏向于动态思维，看的是未来。从这个层面上说，经验沉淀更像是“萃取过去”，而数据思维更像是“赋能未来”。数据思维可以先给过去沉淀的经验加上一个时间轴，然后观察事情在时间轴上的动态变化及背后深层次的逻辑，这样更有利于做出当下正确的决策。丘吉尔有一句名言：“你能看到多远的过去，就能看到多远的未来”。

拥有数据思维的人，总能站在更高的位置动态地思考问题，看到更大的格局，从更高的视角解决问题。通过数据思维可以从“事后复盘”进化为“风险管控”。善用数据思维，可以通过数据驱动研发效能的有效改进，这种驱动的意义不是控制而是赋能。通过数据的反馈，指导我们如何调整研发过程中的流程和行为，让数据指引我们朝着设定的目标前进。

1.4.2 研发效能提升的误区

下面介绍研发效能提升过程中常见的六大误区，希望引发大家更多的思考。

1.缺乏系统化的规划

在很多企业中，并不缺少研发效能的单点能力，各个研发领域也都有很多不错的垂直能力和工具。但是把各个单点能力横向集成与拉通，能够从全流程的角度进行设计和推进，并将其落地为一站式工具平台的还是凤毛麟角。目前，国内很多公司其实都还在建设（甚至是重复建设）单点能力的研效工具，这个思路在解决局部问题的初期尚可行，但是单点改进的效果会随着时间收益递减，后面还是需要从更高视角对研发效能进行整体规划和方案设计。

2.盲目推行一致性

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

3.“伪”工程实践的“面子工程”

从整体情况来看，国内公司与硅谷公司相比，在工程实践方面普遍存在很大差距。但是当你逐项比较双方开展的具体工程实践时，可能会惊讶地发现单从采用各种实践的数量上来说，国内公司一点不亚于硅谷公司。那么，为什么差距会如此明显呢？我们认为，其中最关键的因素在于，国内的很多工程实践都是为了做而做，而不是从本质上认可其实际价值。这里比较典型的例子就是代码评审和单元测试。虽然很多企业都在推进代码评审和单元测试的落地，但是在实际过程中往往都走偏了。代码评审变成了一个僵化的流程，而实际的评审质量和效果无人问津，评审人的评审也不算工作量，迫于时间压力往往草草通过了事。单元测试也沦为一种口号，都说要贯彻，但是在计划排期时，没有给单元测试留任何时间和人力资源，这样实施的效果可想而知。因此，真正的差距不是工程实践做了多少，而是实施的深度。不要用“伪”工程实践和“面子工程”来滥竽充数。

4.忽视上下文而照搬方案

一些规模较小的企业或研发团队，看到国内各研发大厂在研效领域不约而同地重兵投入，纷纷也开始跟随建设，照搬方案。这些企业往往试图通过引进大厂工具和人才来作为研效的突破口，但实际的效果可能不能令人满意。研发大厂的研效工具体系固然有其先进性，但是是否能够适配其他公司的研发规模和流程是有待商榷的，同样的药给大象吃可以治病，而给小白鼠吃可能会丧命。很多时候，研效工具应该被视为起点，而不是终点。引入大厂专家其实也是类似的逻辑，笔者常常会被问及这样的问题：“你之前主导的研发效能提升项目都获得了成功，如果请你过来，多久能搞定”？这其实是一个无解的问题。在一定程度上，投入大，周期就会短，但是实施周期不会因为投入无限大而无限变短。专家可以帮你避开很多曾经踩过的“坑”，尽量少走弯路，犯过的错误不再重犯，但是适合自己的路还是要靠自己走，“拔苗助长”只会损害长期利益。因此，研发效能工作最终能否有成果，还要根据企业环境和上下文量身定制解决方案。

5.忽视开发者的体验

研发效能工作的开展应该以不影响开发者当前的效率为前提，不应该给开发者增加额外的负担，否则很容易遭到反弹甚至全盘失败。忽视开发者的体验，忽视作为知识工作者的工程师在研发过程中的主观能动性，是无法真正提升效能的。

6.不恰当地使用效能度量

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