‍

阅读本文你将收获：

1. ‍什么是研发效能？定义是什么？研发效能真的能提高吗
2. 研发效能提升过程中常见的八大误区
3. 研发效能实践框架的构成：研发效能实践+研发效能平台+研发效能度量

‍

作者简介

张乐，腾讯 DevOps 与研发效能资深专家，曾长期工作于拥有数万研发的互联网大厂（百度、京东等），专注于敏捷与 DevOps 实践体系、DevOps 平台产品设计、研发效能度量体系建设等方向，历任资深敏捷教练、DevOps 平台产品总监、集团级研发效能度量标准化联盟负责人等岗位。长期活跃于技术社区，目前是 DevOps 起源国际组织 DevOpsDays 中国区核心组织者，同时也是国内多个技术峰会的联席主席、DevOps/ 研发效能专题出品人、特邀演讲嘉宾。

茹炳晟，腾讯Tech Lead，腾讯研究院特约研究员，业界知名实战派研发效能和软件质量双领域专家。中国计算机学会CCF TF研发效能SIG主席，腾讯云、阿里云、华为云最具价值专家，年度 IT 图书最具影响力作者，畅销书《测试工程师全栈技术进阶与实践》、《软件研发效能提升之美》、《软件研发效能提升实践》和《高效自动化测试平台：设计与开发实战》作者，极客时间《软件测试 52 讲—从小工到专家的实战心法》作者。

本文来源：转载茹炳晟老师和张乐老师的研发效能系列文章，本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南》

‍

研发效能概述

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

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

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

• ‍研发效能的目标。更高效、更高质量、更可靠、可持续地交付更优的业务价值‍
• 研发效能的误区。展开介绍研发效能提升过程中经常遇到的八大误区‍
• 研发效能的实践框架。“研发效能的黄金三角”由三个部分组成，分别是研发效能实践、研发效能平台和研发效能度量，它们形成一个彼此增强、迭代优化的增强回路，有效利用好这个模型可以促进企业研发效能持续增强、不断提升，最终助力企业和业务的成功

‍

研发效能的目标

‍研发效能的定义

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

• ‍更高效：更高的效率代表更快、更及时地交付，这样就能更早地进入市场，然后更早地学习、更早地调整，更早地降低风险，更早地锁定进展和价值。这是敏捷和精益思想的核心；‍
• 更高质量：我们研发的产品是有质量红线、有底线要求的。快速交付给客户有质量问题的功能除了会引发投诉以外没有任何价值。质量是内建的，不是事后检验出来的；‍
• 更可靠：我们要的是敏捷，而不是脆弱(agile rather than fragile)，安全和合规方面要有保障。就像开车一样，只有车子更可靠、刹车更好，你才敢开得更快；‍
• 可持续：短期的取巧和”快糙猛”、小作坊式开发，只会给未来带来更多的技术债务和持久的效率低下，软件研发不是一锤子买卖，我们应该用”长线思维”来思考问题；‍
• 更优的业务价值：我们经常说”以终为始”，你提供给客户或业务的东西应该是有价值的，这是关于你为什么要做所有这些事情的根本出发点。

‍

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

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

• 强调功劳而不是苦劳：不再按加班时长进行排名，而是让大家的目标聚焦在对结果有帮助的事情上，即交付业务价值；着眼点从局部产出过渡到整体结果上；‍
• 强调更聪明地工作：就是我们常说的"好钢用在刀刃上"，通过一系列工作流程、协作方式、角色职责、系统架构、技术平台上的优化，通过工具建设和自动化程度的提升，让大家能够摆脱冗长无聊的各类会议、重复机械的手工操作，把时间花在真正有创造性的事情上；‍
• 强调个人能力成长：组织要给大家留出一些空闲时间来，用于个人的学习和提高，成长的机会也许比晋升和绩效更能吸引人。优秀的企业会注重侧重培养个人的技术能力、软件工程能力、业务领域能力。组织是由每个部门、每个团队、每个人组成的，只有每个人的效率提升了、能力增强了，工作更快乐了，整个企业的研发效能才会更好。

‍

研发效能真的能够提高吗

‍

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

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

‍

研发效能的误区

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

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

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

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

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

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

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

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

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

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

常见误区5：盲目跟风

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

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

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

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

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

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

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

‍

研发效能的实践框架

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

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

‍

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

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

‍

研发效能实践

‍

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

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

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

‍

研发效能平台

‍

目标：打造一站式、一体化的研发效能平台，支撑软件交付全生命周期。

价值主张：自动化+自助化、场景化+生态化

• 自动化：自动化很好理解，DevOps讲究”自动化一切”，这正是DevOps精髓”CALMS”中的A（Automation），研究表明高效能企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远高于中低研发效能企业；
• 自助化：自助化代表上下游角色可以通过平台紧密衔接，工具平台被某种角色创建出来之后，上下游其他角色应该都可以按需、自助地使用，降低了对于某种角色或者某个人的依赖，这样组织协作效率才能提升；
• 场景化：我们经常看到很多所谓的”一站式、一体化”是按功能领域进行划分并展现相关能力的，或者说是一个”拼凑”起来的平台。而真正让管理者和工程师使用趁手的、易用的平台一定是按研发场景进行组织的，比如以某一产品为主线贯穿DevOps流程，方便用户管理产品相关需求、创建特性分支，迭代开发和交付。同样，以应用为主线对于运维人员来讲就会更加友好；
• 生态化：在互联网大厂搭建研发效能平台普遍遇到的难点就是业务复杂、规模庞大，业务独特、场景众多，很难通过一个团队的努力就能满足整个公司的需求。但是各个业务部门如果什么都自己做、重复造轮子、甚至相互恶性竞争就更不好了。所以，作为平台建设者应该更加开放，分离平台底座和原子能力的建设，即通过生态合作伙伴关系，促进公司研发效能平台的良性发展。从公司角度来看，减少重复建设和避免内耗，也都是"反内卷"的表现。

‍实施建议：研发效能平台的建设切莫一上来就追求”大而全”，所谓的”一站式、一体化”只是手段而不是目的，最终以能满足研发场景的诉求为主。尤其是在平台建设初期，不妨以支持”toB”客户的思维来进行平台运营，深度绑定和跟进种子团队，深刻理解业务痛点和需求，这样做出来的平台马上就有人用，然后收集反馈，像滚雪球一样越做越完善。另外，还要注重需求价值流、工程价值流之间的联动，而不要分裂成毫无关联的两个系统。

‍

研发效能度量

目标：在正确的方向上开展研发效能度量和数据洞察，指导和驱动研发效能改进和提升

价值主张：数据驱动+实验思维‍

• ‍数据驱动：我们经常遇到的现象是，一个组织或者团队在消耗了大量的”变革”时间成本和人力资源后，却无法回答一些看似本质的问题，比如：”你们的研发效能到底怎么样？比别的公司、别的团队更好还是更差？瓶颈点和问题是什么？采纳了敏捷或DevOps实践之后有没有效果？下一步应该采取什么行动？”。我认为研发效能度量的目标就是让研发效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善研发效能，而不要总是凭直觉感性地说”我觉得…”。用真实、有效的数据说话，勇于挑战现有流程和规则，直指研发痛点和根因，也是一种"反内卷"的表现；
• ‍实验思维：研发效能提升没有”一招鲜，吃遍天”的万能招式，而是要基于上下文进行有针对性的实验和探索。比如，想提升线上质量、降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖、完善CodeReview机制、做好自动化测试案例的补充。但是，这真的有效么？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做的不到位。比如只是为了指标好看，编写缺少断言的单元测试、找熟人走过场分分钟通过的代码评审、覆盖一些非热点代码来硬凑测试覆盖率目标等等。所以，我们需要实验思维，找到那些真正有用的改进活动及其与结果之间的因果关系，有的放矢才会更有效率和有效果。

‍实施建议：研发效能度量本身也是一个比较复杂的体系，包含数据采集、度量指标、度量模型、度量产品、数据运营等多个方面，我把它们整理出来，称为“研发效能度量的五项精进”。

‍1. 构建自动采集研发效能数据的能力

通过系统分层处理好数据接入、存储计算和数据分析。比如，小型团队通过MQ、API等方式把数据采集起来之后，使用MySql（存放明细数据和汇总数据）、Redis（存放缓存数据）、ES（数据聚合和检索分析）三件套基本就够用了；而大规模企业由于数据量庞大、汇聚和分析逻辑复杂，建议使用整套大数据分析解决方案，比如流行的流批一体的大数据分析架构。

2. 设计研发效能度量指标体系

选取结果指标用于评估能力，过程指标用于指导分析改进。比如：需求交付周期、需求吞吐量就是结果指标，可用于对交付效率进行整体评估；交付各阶段耗时、需求变更率、需求评审通过率、缺陷解决时长就是过程指标，可用于指导分析改进。通过先导性指标进行事前干预，通过滞后性指标进行事后复盘。比如：流动负载（在制品数量）是一个先导型指标，根据利特尔法则，在制品过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预；而线上缺陷密度就是一个滞后性指标，线上缺陷已经发生了，我们能做的就只有复盘、对缺陷根因进行分析，争取在下个统计周期内能让质量提升、指标好转。

3. 建立研发效能度量分析模型

这里的模型是指对研发效能问题、规律进行抽象后的一种形式化的表达方式。比如流时间（需求交付周期）、流速率（需求吞吐量）、流负载、流效率、流分布这五类指标结合在一起，就是一个典型的分析产品/团队交付效率的模型，通过这个模型可以讲述一个完整的故事，回答一个关于交付效率的本质问题。模型还有很多种，比如组织研发效能模型（如战略资源投入分布和合理性）、产品/团队研发效能模型、工程师研发效能模型等，我们还要合理采用趋势分析、相关性分析、诊断分析等方法，分析研发效能问题、指导研发效能改进；

4. 设计和实现研发效能度量产品

将数据转化为信息，然后将信息转化为知识，让用户可以自助消费数据，主动进行分析和洞察；简单的度量产品以展示度量指标为主，比如按照部门、产品线等维度进行指标卡片和指标图表的展现；做的好一点的度量产品可以加入各种分析能力，可以进行下钻上卷，可以进行趋势分析、对比分析等；而做的比较完善的度量产品应该自带各种分析模型和逻辑，面向用户屏蔽理论和数据关系的复杂性，直接输出研发效能报告，并提供问题根因分析和改进建议，让对研发效能分析不是很熟悉的人也能自助地使用。

5. 实现有效的研发效能数据运营体系

放在最后的其实才是最重要的，我们有了度量指标、有了度量模型、有了度量产品，但一定要注意的是：要避免不正当使用度量而产生的负面效果，避免将度量指标KPI化而导致"造数据"的短视行为。根据古德哈特定律，度量不是武器，而是学习和持续改进的工具。正所谓"上有政策，下有对策"，"度量什么就会得到什么"，为了避免度量带来的各种副作用，我们首要的度量对象应该是工作本身，而不是工作者。另外，研发效能改进的运作模式也很重要，只是把数据报表放在那里研发效能不会自己变好，需要有团队或专人负责推动改进事宜。

‍