如何用研发效能拯救一个团队：“研发效能宣言”解读

本文作者：茹炳晟、张乐

研发效能在国内尚处于快速发展阶段，我们在与一些专家和实践者朋友们沟通的过程中，发现大家在思路上其实有很多的共同观点，通过一些专项的研讨，我们就提升研发效能的许多重要方面达成了一致。

于是我们希望把这些内容沉淀下来，它既能提纲挈领地阐述我们都认同的价值观，又能成为行业持续前进的催化剂。我们决定将其称为“研发效能宣言”，既是对“敏捷宣言”的致敬，也是对我们的信念和价值观的呼吁和声明，它说明了我们的立场以及我们认为对研发效能而言什么才是最重要的。

2021年10月，国内首届卓越工程生产力大会（Excellent Engineering Conference）在北京举办，会议期间，由大会组委会联合业界数十位研发效能和工程生产力顶级专家重磅发布了“研发效能宣言”，该宣言从业务、流程、技术、数据以及组织视角对研发提升给出了价值观的指导，本文会对这些核心价值观做一个系统性的解读。

业务视角

业务价值 高于 职能目标

一切不以达成业务价值为导向的研发效能提升都是耍流氓 。效能是为业务价值服务的，效率更多是为职能目标服务的。可以说效能是方向，效率是速度，如果方向错了，速度再快也没什么用，这就是为什么我们经常会听到“高效交付无法确保业务成功”背后的原因。

效能是做能让你更接近目标的事，而效率是以尽量经济的方式完成特定任务。 从这个角度来讲， ” 瞎忙 ” 也是某种形式的懒惰，说明你懒得思考，不加选择地行动。举个例子，你可以高效率地划着船原地打转，但高效能的人绝对不会做无用功，一定会明确知道自己要去向哪里。 “不要用战术上的勤奋来掩盖战略上的懒惰” 说的也是这个道理。

“思辨胜于执行”本质上也表达了类似的意思。先看“思辨”和“执行”两个词的释义。思辨即思考辨析，其结果是指导思想。执行，即贯彻施行指导思想。可见，思辨决定了执行的方向。

思辨对于研发团队生产力的提升，首要的就是要找到“真正”的需求。对于一个需求到底要不要做，花多点时间研究是值得的，因为一旦一个需求决策形成，其成本都是几十倍上百倍的增加。产品经理的一个决策背后是研发，测试，运维团队的一大堆工作量。

作为产品经理，需要在资源有限的条件下，决定优先满足哪些用户需求。产品每增加或者调整一个功能，其实都是在权衡取舍，哪一类用户优先，哪一类场景优先。所以从本质上讲， 产品经理并不是 盲目地 追求 “用户价值最大化”，而是 选择性地找到 “有利可图”的用户价值，这样研发团队的业务价值输出能力才会被放大。

另一个值得分享的例子是，当业务价值处于快速上升期的时候，此时需要的是更快地业务能力交付，此时用“堆人、堆时间”的方式来解决短期效率不足的问题，同时技术上可以选择先主动负债（不求完美只求能用），这个阶段这种“快糙猛”的研发模式其实是有效的。我相信一定有人会持反对意见，但这其实恰恰体现了“业务价值高于职能目标”这个价值观。

但是规模大了之后，就不能这么搞，一方面用户群体规模已经变得非常庞大了，高质量、业务稳定和业务连续性成为了主要矛盾，另一方面团队的内耗（随机复杂性）不断在变大，此时要开始寻求工程卓越，这时候追求研发效能提升本质上还是为了更好地实现业务价值。

可见， 业务发展的不同阶段，对业务价值的追求方式也是不一样的，效能提升的方式也是各不相同的。

另外，业务发展初期先采用“快糙猛”的研发模式快速占领市场，验证产品业务能力和商业模式，等业务试水成功后再另起炉灶，采用低技术负债的研发模式重构、甚至是重新开发一套系统也是一种不错的做法。

最后特别提一句，业务失败很多时候不是效能的问题，而是业务本身就不行，但很多时候确会让效能变革背锅。 仅仅关注 效能 并 不能成就业务，只能减少业务成功路上的阻力。

流程视角

全局流动 高于 局部优化

流动是精益思想的五大原则之一，是精益思想的关键部分，其目标是让价值不间断地流动起来。

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

研发效能提升的初期，局部优化是有用的，比如编译时间从 10 分钟下降到了 2 分钟，自动化测试执行时长从3 0 分钟下降到了 5 分钟等，看起来是有一些效果的。但是， 局部优化的效果会随着时间收益递减。在 进入深水区后，能够带来效率大幅度提升的往往 是 来 对于 自全局 流动 的优化。

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

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

所以我们需要上帝视角，能够站的更高，在全局上分析问题。

技术视角

工程卓越 高于 工具平台

工具平台应该简单易用，向下屏蔽复杂的实现，向上提供易于使用的能力，在不增加工程师学习成本的前提下，默默地优化研发过程的各个环节，提升整体工作效率。 工具平台在一定程度上体现了 ”成全别人（ 别人指的是 用工具的人）， 死磕 自己（ 自己指的是工 具开发者） “的设计哲学。

但是工具平台并不是效能提升的全部。 拥有工具和拥有能力是截然不同的两件事。 很多公司采购了研效工具就以为自己拥有了这样的能力。其实装备党只能让你看起来显得专业而已。这就好比你买了一辆跑车，并不能让你成为赛车手是一个道理。

工程卓越是内在的能力，是需要时间积累的，工具平台是外在的表现，是可以花钱买的(能花钱解决的其实都不是问题)。工具是工程卓越的载体，脱离了工程卓越，工具是没有灵魂的存在。

同样的工具，因为用的人不同，能够发挥的作用差异巨大。用一块物理白板外加一些便利贴，同样可以实现真正意义上的敏捷开发，全套的敏捷工具也可以被用作“披着敏捷外衣的瀑布模型“。

另外，工具侧的“抄作业“是没有用的，适合才是最重要的，A公司用这个工具取得了巨大的成功，B公司很有可能会用不起来。同样的药给大象吃可以治病，给你吃可能直接致命。

还有一个有趣的现象，行业内单点效能工具做的好的有不少，但是特别优秀的一站式的体系化平台却很稀有，大多数企业实际趁手的工具链体系往往是以自研或二次开发为主的，很少能通过采购直接到达效果，正是因为这些自研工具中更容易融入定制化的工程卓越的最佳实践。

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

数据视角

数据思维 高于 经验沉淀

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

经验沉淀固然重要，但是其成功很难工业化 、 批量化复制。 我记得有一次我看到一位员工在面对复杂性能调优场景的时候，非常熟练地使用各种工具查看数据，并且在多个工具间切换分析下钻，定位到了性能瓶颈，最终修复了该问题。我当时第一反应就是 “这样的成功不可复制”。

我们需要做的是把个人的、局部的成功经验提炼出来形成数据思维能力，然后在团队内部快速扩散、批量复制，实现研发效能的“聚沙成塔”。让专家经验通过数据思维沉淀下来，实现标准化，进而实现工业化才是正道。

经验沉淀有点类似于静态思维，看的是过去，而数据思维则更偏向于动态思维，看的是未来。从这个层面上说，经验沉淀更像是 “萃取过去”，而数据思维更像是“赋能未来” 。

数据思维可以把过去沉淀的经验加上一根时间轴，然后观察事情在时间轴上的动态变化以及背后深层次的逻辑，更有利于做出当下正确的决策。丘吉尔有一句名言：“你能看到多远的过去，就能看到多远的未来。”所以，过去项目的推进方式，实际上决定了我们看待未来的方式。

拥有数据思维的人，总能站在更高的位置动态思考问题，看到更大的格局，从更高的视角解决问题。通过数据思维可以实现从“事后复盘”进化为“风险管控”。

数据思维将为社会科学带来一场革命，就像显微镜和望远镜彻底变革了自然科学那样。

特别提一下： 数据思维并不是说要完全依赖数据，这个也是相当危险的 。经验在很多时候依然能发挥很大的作用。就像 Jeff Bezos说的：“当传闻和数据不一致时，传闻通常是正确的”。丰田的大野耐一也曾经说过：”那些不懂数字的人是糟糕的，而最最糟糕的是那些只盯着数字看的人”。盯着数据，就等于是站在病房盯着监护仪上的数字，而病人最后却因为吃三明治噎死了。

总结起来就是， 数据思维固然重要，但是全信数不如无数 。

组织视角

工程师文化 高于 绩效管理

绩效管理只是一个为了达成目标的工具，而工程师文化是一个体系，有着更广泛的内涵。

管理学大师彼得 ·德鲁克曾经说过，“ 文化能把战略当早餐吃掉 ”。在统一员工的价值观和行为准则、激发创新和变革等方面，企业文化有时候比企业战略还重要。如果没有企业文化的有效支撑， 无论是多么高瞻远瞩的战略，多么完备的方法论和流程规范，多么费尽心思设计出来的创新想法，最终可能都只是一纸空文。

在软件研发领域，很多优秀的公司都非常推崇工程师文化。比如 Google的创始人Larry Page多次在公司内部明确的讲 到，在G oogl e ,工程师是处在金字塔顶上的人，在公司的地位是最高的。 工程师文化提倡用理性思维来创造性地解决问题。要给工程师最大的空间，提倡深入研究技术、钻研问题、持续不断地改进产品。另外，还要尊重客观事实、淡化权威，一切的想法、判断及思路都要以数据来支撑，对同一个问题的不同看法， 不因职位的高低来出结果，而是通过数据的不断验证来证明对错 。工程师需要有敏捷思维，小步快跑，并且在过程中不断的试错，不断的进行摸索和创新。

我们经常看到一些企业的研发效能的优化方向是面向管理者服务的，比如制定出各种流程规范、强化项目和研发过程管理，出具各式各样的度量报表、使用各种绩效管理手段等。这些当然也很有价值，但是有时却忽略了为研发过程中最庞大的群体 --工程师— 提供服务。 研发效能的提升要 拥抱开发者体验 ，提供给工程师更明确的目标对齐、更人性化的工作环境、更优秀的研发工具、更精简的协作流程，但千万不要过度控制，而是尊重和发挥个体的智慧，把工程师全方位服务好，才会获得更强大的创造力和创新力 。

延展阅读

本文关于研发效能价值观的探讨只是抛砖引玉，如果你对这个话题感兴趣，可以关注以下扩展阅读。《软件研发效能提升之美》是业界第一本研发效能领域的专著，现已正式出版。《软件研发效能提升实践》是一本研发效能领域的集大成者，由业界20位一线专家联合撰写，也是首次公开对研发效能宣言进行正式解读，并提供了大量实际落地案例的专著，预计于2022年3月正式出版。

作者：茹炳晟