研发效能的提高

谈到研发效能，我们有着自己的独到见解。我们看到的现象是：只要努力搞，没有折腾不垮的团队。 虽然有很多大厂研发效能做的还不错，成为了大家膜拜的对象，但是我们也看到很多“内卷”现象的发生。经历了很多故事，我们更能谈谈自己的理解和感悟。

研发效能是目前互联网企业和传统软件企业都高度关注的领域，互联网大厂希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发；腰部厂商则希望通过“研发效能”实现弯道超车，充分发挥后来者居上的优势；更多中小企业看到国内互联网大厂不约而同地在这个领域重点投入，纷纷也是摩拳擦掌准备在效能领域发力。

一夜之间，似乎只有推进了研发效能，才能提升研发团队的效率，才能让自己在和友商的比拼中不至于输在起跑线上。

那么现在企业的研发效能实践到底为企业带来了多大的优势，又帮企业解决了哪些问题呢？那些推行研发效能的企业现在的状态怎么样？研效问题到底解决了吗？

别急，这些问题其实大多都还没有解决，而且有些问题可能还变得更糟糕了。毕竟研发效能的实施没有捷径，需要摸着石头过河，肯定不会能像电影里面演得那样注定会有皆大欢喜的结局。经历了风雨，不一定能看见彩虹，更有可能会得重感冒。研发效能问题今天解决不了，不要着急，因为明天同样也解决不了。 所以就让我们“放心大胆”地看看研发效能到底是如何搞垮一个团队的。

要看懂研发效能如何搞垮一个团队，我们首先需要对研发效能有一个全局的认识，需要先从正向的角度来理解研发效能。

1. 什么是研发效能 ？

和敏捷的概念类似，到底什么是研发效能很难精确定义。其实很多复杂概念也不是定义出来的，而是逐步演化出来的，是先有现象再找到合适的表述。其实，效率和效能也从来都不是软件工程的专有名词，纵观人类发展史，就是生产力和生产效率不断提升的发展篇章，到了数字化时代，软件研发效能的重要性被凸显了出来。如果要用一句话来总结研发效能的话，我们会用“更高效、更高质量、更可靠、可持续地交付更优的业务价值”来总结。

图 1：研发效能的“第一性原理”

解释一下其中几个关键概念：

• 更高效：价值的流动过程必须高效顺畅，阻力越小越好。

• 更高质量：如果质量不行，流动越快，死的也会越快。

• 更可靠：安全性和合规性要保障好。

• 可持续：输出不能时断时续，小步快跑才是正道，不要憋大招。

• 更优的业务价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。比如：“女生减肥不是本质问题，女生爱美才是”。可以体会一下。

2. 为什么大厂都开始搞研发效能

阿里的云效、腾讯云的 CODING、百度的工程效能白皮书都是国内研发效能领域的标杆，可是你有没有想过，为什么最近几年各大行业龙头企业都纷纷开始在研发效能领域发力，而且步调如此一致，我们认为背后的原因有以下这么三点：

2.1 很多企业存在大量重复造轮子

就像“中台“概念一样，现在很多大企业的产品线非常广，其中存在大量重复的轮子，如果我们关注业务上的重复轮子，那么就是业务中台；如果我们关注数据建设上的重复轮子，那么就是数据中台；如果我们关注研发效能建设上的重复轮子，那就是研效平台，其实研效平台在某种程度上也可以称之为”研发效能中台“，其目标是实现企业级跨产品跨项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0 到 1“，没人有精力去关注更有价值的”1 到 n“。现代化的研效平台会统一来打造组织级别通用研发能力的最佳实践平台。

2.2 toC 产品已经趋向饱和

从商业视角来看，现在 toC 产品已经趋向饱和，过去大量闲置时间等待被 APP 填满的红利时代已经一去不复返了，以前业务发展极快，那么用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是最佳选择，那个时代关心的是软件产品输出，研发的效率都可以用钱填上。而现在 toC 已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。

2.3 部分企业存在“谷仓困局”

从组织架构层面看，很多企业都存在“谷仓困局”，研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。

3. 研发效能真的能够提高吗

既然如此重要，那接下来的问题是研发效能是否真的能提高？很不幸，我们的观点比较悲观。我们认为研发效能的绝对值随着以下因素的增长必然会变得越来越差，就像我（声明一下，这里没有张乐老师）的头发一样，随着时间的推移必然会越来越少一样。

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

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

• 研发团队人员规模不断扩大引发沟通协作难度增长

所以，我们能做的不是提升研发效能的绝对值，而是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，努力保持现状就是成功。

3. 为了提高研发效能，高度内卷 

互联网大厂一直自带上热搜的体质，而互联网圈流行已久的”996”向来是内卷的代名词。

大家肯定还记得，去年网络上对于”996”有着深度的讨论，”996”话题似乎与互联网大厂有着某种深度绑定，某些话题确实也是从大厂内部发源的。比如：

• 阿里的马云老师说，能 996 是一种巨大的福气，很多公司、很多人想 996 都没有机会；

• 京东的东哥说，混日子的不是我兄弟；

• 百度强调“狼性”文化；

• 字节跳动、快手事实上都在采用”大小周”的工作制度；

• 拼多多成立 5 周年庆祝活动上，董事长鼓励全员开启“硬核奋斗模式”；

• 华为有”奋斗者协议”，员工工位下面常备行军床，方便加班累了休息用；

• 世界上最大的代码托管平台 GitHub 上有一个叫 996.ICU 的项目，发起者称“工作 996，生病 ICU”；

随着内卷的不断加剧，很多人学会了“表演型”加班。当加班文化盛行，身处其中的每个员工都容易被裹挟其中，即便没有工作安排，也宁愿下班后留在公司继续“磨洋工”。而过度加班会降低工作效率，让员工患上严重的“拖延症”。

另外，也有声音指出，把提高员工效率寄托在延长工作时间上，本就是管理上的“懒政”行为。阿里某 P8 同学留言说，“当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把‘工时’当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”

当然，”996”的话题由于其巨大的争议性，难免也会受到一些网友断章取义地过度吐槽，比如把”加班”和”奋斗”混为一谈，然后发出各种更不理性的言论。到后来马云老师也补充道：“任何公司不应该，也不能强制员工 996；阿里巴巴从来也都提倡，认真生活、快乐工作！但是年轻人自己要明白，幸福是奋斗出来的！不为 996 辩护，但向奋斗者致敬！”

时光荏苒，到了 2021 年的年中，风向突然发生了转变：

• 腾讯光子工作室 6 月中旬试行“强制不加班双休”的政策，周三健康日九点半上班，下午六点下班，其他工作日也必须在晚上九点前离开公司；

• 6 月 24 日，快手正式宣布，从 7 月 1 日开始取消大小周制度。员工按需加班，公司按照相关规定向员工支付加班工资；

• 7 月 9 日，字节跳动发布公告，宣布将于 2021 年 8 月 1 日起取消隔周周日工作的安排。字节跳动表示，8 月开始有需求的团队和个人，可以通过系统提交加班申请；

• 7 月 13 日，“京东宣布全员涨薪两个月”登上微博热搜第一，直接刷屏了。有网友评论称，字越少，事越大，京东这是“直男式涨薪”——不卖萌，不卖惨，简单直接，说涨就涨；

• 7 月 14 日，美团旗下社区团购业务“美团优选”已于近日发布通知，取消“大小周”，本周起立即执行；

• 近期华为心声社区也披露了任正非的一次内部讲话，要求通过一系列机制防止熵增、沉淀、内卷化。

一夜之间，大厂们似乎都在”反内卷”，“大小周”和类似的工作传统终于要成为过去式了。无论是何种因素导致了互联网企业的这波运动，但未来更多企业跟进“反内卷”的潮流几乎已经成为必然。

那么我们需要思考一下，这一波互联网企业“反内卷”的底层逻辑究竟是什么？我认为肯定有互联网在监管日趋严格的背景下寻求工作合规化的诉求，当然还有更重要的，就是如何让互联网真正成为一个技术密集型产业，而不是劳动密集型产业。

在这个趋势之下，已经不能靠一味地堆砌劳动时间获得工作成果，而切实提高工作效率才是良药，”研发效能”就成为了一家科技公司的核心竞争力。

4. 研发效能的黄金三角洲 

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

研发效能的黄金三角由三个部分组成，分别是效能实践、效能平台和效能度量。这三个部分彼此独立，但又相互关联。其关联关系是：

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

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

• “效能度量”中的洞察和分析结果可用于针对性优化”效能实践”；反过来，”效能实践”可以给”效能度量”更多的输入，帮助完善度量指标集和分析方法；

所以，效能实践<->效能平台<->效能度量就形成了一个彼此增强、迭代优化的回路，有效利用好这个增强回路就可以帮助企业研发效能持续增强、不断提升。

重申一下，我们的最终目标是：更高效、更高质量、更可靠、可持续地交付更优的业务价值。

下面我们就来简单看一下这三个部分。

4.1. 效能实践

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

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

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

• 工程卓越：我们必须持续关注工程和技术的卓越性，而不仅仅是交付了多少需求或特性。比起多完成了几个小功能，也许工程和技术上的提升所带来的价值会更大。就像微软 CEO 萨蒂亚·纳德拉所说：每一天我都在开发新特性和提升我们的生产力之间进行权衡。我们要追求用工程化的方法持续把确定性、重复性、机械性的任务自动化，从而在提升效率的同时让工程师有更多时间花在有创造性的事情上。用工程化的思路解决问题、追求工程卓越就是一种"反内卷"的表现；

实践分类：业务敏捷创新实践、敏捷精益协作实践、持续交付工程实践、云原生技术实践、组织和团队拓扑等；

实施建议：业界一致认为，DevOps 领域、研发效能领域都从来就没有”一刀切”的解决方案，所以不要迷信某个成熟度模型、某种规模化框架就一定能对你有帮助。正确的实践选择一定是要基于上下文的，找出价值流中最大的障碍，选取工具箱中适当的实践，从小范围开始、纵向进行实验，应用敏捷思维来提升组织效能，逐个解决瓶颈，循环往复。

4.2 效能平台

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

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

• 自动化：自动化很好理解，DevOps 讲究”自动化一切”，这正是 DevOps 精髓”CALMS”中的 A（Automation），研究表明高效能企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远高于中低效能企业；

• 自助化：自助化代表上下游角色可以通过平台紧密衔接，工具平台被某种角色创建出来之后，上下游其他角色应该都可以按需、自助地使用，降低了对于某种角色或者某个人的依赖，这样组织协作效率才能提升；

• 场景化：我们经常看到很多所谓的”一站式、一体化”是按功能领域进行划分并展现相关能力的，或者说是一个”拼凑”起来的平台。而真正让管理者和工程师使用趁手的、易用的平台一定是按研发场景进行组织的，比如以某一产品为主线贯穿 DevOps 流程，方便用户管理产品相关需求、创建特性分支，迭代开发和交付。同样，以应用为主线对于运维人员来讲就会更加友好；

• 生态化：在互联网大厂搭建效能平台普遍遇到的难点就是业务复杂、规模庞大，业务独特、场景众多，很难通过一个团队的努力就能满足整个公司的需求。但是各个业务部门如果什么都自己做、重复造轮子、甚至相互恶性竞争就更不好了。所以，作为平台建设者应该更加开放，分离平台底座和原子能力的建设，即通过生态合作伙伴关系，促进公司效能平台的良性发展。从公司角度来看，减少重复建设和避免内耗，也都是"反内卷"的表现。

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

4.3 效能度量

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

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

• 数据驱动：我们经常遇到的现象是，一个组织或者团队在消耗了大量的”变革”时间成本和人力资源后，却无法回答一些看似本质的问题，比如：”你们的研发效能到底怎么样？比别的公司、别的团队更好还是更差？瓶颈点和问题是什么？采纳了敏捷或 DevOps 实践之后有没有效果？下一步应该采取什么行动？” 。我认为研发效能度量的目标就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不要总是凭直觉感性地说”我觉得…”。用真实、有效的数据说话，勇于挑战现有流程和规则，直指研发痛点和根因，也是一种"反内卷"的表现；

• 实验思维：研发效能提升没有”一招鲜，吃遍天”的万能招式，而是要基于上下文进行有针对性的实验和探索。比如，想提升线上质量、降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖、完善 Code Review 机制、做好自动化测试案例的补充。但是，这真的有效么？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做的不到位。比如只是为了指标好看，编写缺少断言的单元测试、找熟人走过场分分钟通过的代码评审、覆盖一些非热点代码来硬凑测试覆盖率目标等等。所以，我们需要实验思维，找到那些真正有用的改进活动及其与结果之间的因果关系，有的放矢才会更有效率和有效果；

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

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

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

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

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

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

！

如何用研发效能搞垮一个团队-InfoQ

在互联网大厂，我们是怎么“反内卷”的-InfoQ