研发效能概述

?“反内卷”的潮流已经悄然而至，研发效能的提升是科技企业的必由之路。2021 年对互联网行业而言，注定是不平凡的一年。今年我们已经习惯了看到各种互联网大事件的发生，某某公司上市折戟了、某某公司遭遇反垄断调查了、某某公司的 APP 被下架了、某某行业遭遇政策性团灭了…而另一方面，我们也能从互联网巨头近期的各种动作中识别出一些风向的变化，从积极的角度来看，他们正朝着一种更科学、更可持续的方向在发展。

近期，大厂们似乎都在忙着”反内卷”，腾讯、快手、字节跳动、美团等公司纷纷推出了控制高强度加班、取消“大小周”（即可以周末双休）等类似的政策，希望通过一系列的机制防止组织的熵增、内卷化。无论是何种因素导致了互联网企业的这波运动，但未来更多企业跟进“反内卷”的潮流几乎已经成为必然。我们需要思考一下，这一波“反内卷”运动的底层逻辑究竟是什么？我认为肯定有互联网在监管日趋严格的背景下寻求工作合规化的诉求，当然还有更重要的，就是如何让互联网真正成为一个技术密集型产业，而不是劳动密集型产业。

?在这个趋势之下，我们已经不能靠一味地堆砌劳动时间获得工作成果，而切实提高工作效率才是良药，“研发效能”就成为了一家科技公司的核心竞争力。在本章中，我们会通过三个小节对研发效能进行一个整体的概述：

• ?研发效能的目标。更高效、更高质量、更可靠、可持续地交付更优的业务价值?

• 研发效能的误区。展开介绍研发效能提升过程中经常遇到的八大误区?

• 研发效能的实践框架。“研发效能的黄金三角”由三个部分组成，分别是研发效能实践、研发效能平台和研发效能度量，它们形成一个彼此增强、迭代优化的增强回路，有效利用好这个模型可以促进企业研发效能持续增强、不断提升，最终助力企业和业务的成功

?

研发效能的目标

?研发效能的定义

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

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

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

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

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

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

研发效能的目标在这个概念的引导下，我们引出持续开发，持续集成，持续测试，持续交付和持续运维的理念，它们是研发效能落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。

上面的描述是组织的视角出发的，那研发效能提升对我们每个人有什么好处呢？我们认为对个人的好处就是：?

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

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

• 强调个人能力成长：组织要给大家留出一些空闲时间来，用于个人的学习和提高，成长的机会也许比晋升和绩效更能吸引人。优秀的企业会注重侧重培养个人的技术能力、软件工程能力、业务领域能力。组织是由每个部门、每个团队、每个人组成的，只有每个人的效率提升了、能力增强了，工作更快乐了，整个企业的研发效能才会更好。

?

研发效能真的能够提高吗

?

既然如此重要，那接下来的问题是研发效能是否真的能提高？根据“熵增定律”，在一个孤立系统里，如果没有外力做功，其总混乱度（熵）会不断增大。我们的软件越做越大、越做越复杂，研发效能的绝对值随着以下因素的增长必然会变得越来越差。

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

• 软件规模的不断增长（集群规模，数据规模等）

• 研发团队人员规模不断扩大引发沟通协作难度增长所以，我们对于研发效能工作的最基本要求就是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，在软件规模和复杂性不断提升的同时努力保持高效，“努力奔跑或许只能让我们保持原地”。当然，研发效能的持续提升是我们追求的终极目标，我们需要不断的尝试和努力，我们一直在路上。

  
  

研发效能的误区

本小节系统性描述研发效能提升过程中常见的8大误区，希望借此抛砖引玉，引发大家对研发效能提升过程中可能遇到的问题的思考。

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

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

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

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

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

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

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

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

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

常见误区5：盲目跟风

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

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

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

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

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

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

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

?

研发效能的实践框架

这些年笔者一直在拥有数万研发人员规模的大型互联网公司中做DevOps和研发效能的相关工作，做过敏捷和持续交付实践的大规模推广，组建并带领团队从零开始建设过服务于全公司的、一体化、一站式的DevOps平台，发起过公司级研发效能度量委员会并制定度量指标体系，加之在技术社区持续活跃、在各类综合性/专业性技术大会中担任出品人等角色，对互联网大厂的研发效能提升思路和做法有一定的理解，我把这些经验总结起来，形成一个具有增强回路效果的研发效能提升体系，我称之为”研发效能的黄金三角”。

研发效能的黄金三角由三个部分组成，分别是研发效能实践、研发效能平台和研发效能能度量。

?

这三个部分彼此独立，但又相互关联。其关联关系如下：

• “研发效能实践”中的优秀实践可以固化、沉淀到“研发效能平台”；反过来，“研发效能平台”支撑了“研发效能实践”的落地；

• “研发效能平台“产生的大量研发数据形成了“研发效能度量”中的研发效能洞察；反过来，“研发效能度量”可以持续观测“研发效能平台”中产生的数据，进行下钻和深入分析；

• “研发效能度量”中的洞察和分析结果可用于针对性优化”研发效能实践”；反过来，“研发效能实践”可以给“研发效能度量”更多的输入，帮助完善度量指标集和分析方法；所以，研发效能实践，研发效能平台，研发效能度量就形成了一个彼此增强、迭代优化的回路，有效利用好这个增强回路就可以帮助企业研发效能持续增强、不断提升。我们的最终目标是：更高效、更高质量、更可靠、可持续地交付更优的业务价值。下面我们就来简单看一下这三个部分。我们会分别从目标，价值主张，实践分类和实施建议几个维度展开讨论。

目标：提炼和采纳与上下文匹配的DevOps及研发效能提升实践

价值主张：产品导向+工程卓越

• 产品导向：区别于项目导向的交付模式（在特定时间内，以相对确定的预算和人力，交付预先计划的内容），我们更倾向于以产品导向的交付模式组织相关研发效能实践。产品导向让我们面向长期的业务价值，组织长期稳定的敏捷团队，持续迭代和优化与时俱进的产品。我们承认需求的不确定性，要持续改进产品，而不是简单地遵从既定计划；我们要考虑长期产品和团队能力的建设，而不是把短期项目做完了事；我们要考虑持续为客户创造价值，而不是看项目有没有超过预算；我们要面向工作结果进行响应，而不是盯着一些局部的工作产出；

• 工程卓越：我们必须持续关注工程和技术的卓越性，而不仅仅是交付了多少需求或特性。比起多完成了几个小功能，也许工程和技术上的提升所带来的价值会更大。就像微软CEO萨蒂亚·纳德拉所说：每一天我都在开发新特性和提升我们的生产力之间进行权衡。我们要追求用工程化的方法持续把确定性、重复性、机械性的任务自动化，从而在提升效率的同时让工程师有更多时间花在有创造性的事情上。用工程化的思路解决问题、追求工程卓越就是一种"反内卷"的表现；实践分类：业务敏捷创新实践、敏捷精益协作实践、持续交付工程实践、云原生技术实践、组织和团队拓扑等；实施建议：业界一致认为，DevOps领域、研发效能领域都从来就没有”一刀切”的解决方案，所以不要迷信某个成熟度模型、某种规模化框架就一定能对你有帮助。正确的实践选择一定是要基于上下文的，找出价值流中最大的障碍，选取工具箱中适当的实践，从小范围开始、纵向进行实验，应用敏捷思维来提升组织研发效能，逐个解决瓶颈，循环往复。