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

本文作者：张乐，校对：茹炳晟，转载请保留该信息

2021 年对互联网行业而言，注定是不平凡的一年。

今年我们已经习惯了看到各种互联网大事件的发生，某某公司上市折戟了、某某公司遭遇反垄断调查了、某某公司的 APP 被下架了、某某行业遭遇政策性团灭了…而另一方面，我们也能从互联网巨头近期的各种动作中识别出一些风向的变化，从积极的角度来看，他们正朝着一种更科学、更可持续的方向在发展。比如，从”内卷”到”反内卷”的趋势变化。

“反内卷”的潮流已经悄然而至

互联网大厂一直自带上热搜的体质，而互联网圈流行已久的”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 日，美团旗下社区团购业务“美团优选”已于近日发布通知，取消“大小周”，本周起立即执行；

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

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

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

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

“研发效能”是核心竞争力

“反内卷”成为潮流之后，我们要回答的一个问题是：不加班意味着工作时长变少，但事情还是那么多，那该怎么办呢？

很多公司通常会采用 KPI 或 OKR 作为团队和员工绩效衡量指标，如果目标没有发生变化，那么工作量也不可能大幅减少。这意味着，原本要依赖加班才勉强完成的工作，现在需要在正常的工作时间段内完成。

在这种情况下，“研发效能”的提升，注定就是我们要走的必由之路了。

说到这里，也许你会问，那“研发效能”究竟是什么？

我认为，“研发效能”就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。具体来讲：

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

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

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

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

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

那有同学要问了，上面的描述好像都是对组织而言的，那研发效能的提升，对我们每个人有什么好处呢？

我认为对个人来讲的好处就是：

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

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

• 强调个人能力成长：组织要给大家留出一些空闲时间来，用于个人的学习和提高，成长的机会也许比晋升和绩效更能吸引人。优秀的企业会注重侧重培养个人的技术能力、软件工程能力、业务领域能力。

组织是由每个部门、每个团队、每个人组成的，只有每个人的效率提升了、能力增强了，工作更快乐了，整个企业的研发效能才会更好。

另外，在互联网大厂里，”研发效能”其实已经并不是一个新鲜的事儿了，大家其实都早有布局。各个大厂基本都有专门的部门或团队来负责这件事情：

• 在百度，有个部门叫”工程效率部”，也是我当时所在的部门。后来改名叫”工程效能部”，使命是“用领先的工程平台和服务，让产品研发更高效”。通过持续设计研发基础设施和研发工具产品，让百度所有工程师工作更高效、体验更快乐；

• 在阿里，之前的部门叫”研发效能事业部”，这个部门是阿里巴巴集群生态系统的重要支撑平台，为集团各大业务群的研发、测试，运维工作提供高效的系统平台，提升阿里巴巴的研发效率；

• 在腾讯，TEG、PCG、IEG、CSIG 等各个事业群也基本也都有类似负责研发效能的部门或团队，通过构建 DevOps 或研发效能工具链、研发效能度量、敏捷教练赋能等方式提升企业的研发效能；

• 在美团、滴滴、快手也都有类似的职能部门或团队，只是名字和隶属关系有所差异罢了；

• 国外的互联网大厂更是如此，很多成功的公司都有名为 EP( Engineering Productivity)的部门，让 3%~5%的开发者专注于提升开发生产力。根据相关报道，Google 有超过 1500 人、微软有超过 3000 人专注于这类事情。

研发效能要解决的问题，包括工程师个人生产力的问题，也包括产品和团队效能的问题，当然还要包括最终提升整个企业的组织绩效的问题。研发效能的提升是一个复杂的学科和系统性的工程，涉及到组织、流程、工具、文化等方方面面，那么接下来我们就一起看看大厂们是怎么做的。

研发效能的黄金三角

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

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

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

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

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

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

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

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

效能实践

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

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

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

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

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

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

效能平台

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

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

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

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

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

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

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

效能度量

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

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

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

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

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

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

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

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

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

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

好了，感谢你看到文章的末尾。

觉得怎么样？研发效能相关的话题是不是挺有意思的？这里还有很多值得展开和深度思考的内容，比如：

• 效能实践如何选择，敏捷、精益和工程技术实践的作用域，以及如何搭配？

• 效能实践很多，如何从大处着眼、小处着手，持续改进？

• 效能平台的产品需求价值流与工程活动价值流如何联动？

• 研发效能度量指标体系应该如何设计？

• 研发效能度量模型应该怎么建设，效能数据怎样分析？

以上每个问题都值得单独探讨，但毕竟本文篇幅有限，我们就留在后面再跟大家继续分享吧！

总结

“反内卷”的潮流已经悄然而至，研发效能的提升是科技企业的必由之路。

我们要想尽一切办法做到更高效、更高质量、更可靠、可持续地交付更优的业务价值。

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

祝愿，你能拥有更高的研发效能！