1.3 研发效能的实施策略

核心观点

● 研发效能的落地实施，注重灵活、务实地解决研发痛点和实际问题，要避免开展“大跃进式”、虚假繁荣的运动。

● 研发效能的提升需要业务研发团队、工具平台团队、效能专家或教练团队、组织级研效管理团队共同参与。

● 研发效能提升过程中不同角色该做什么和不能做什么很关键，这些原则在不同场景下都是相通的。

● 研发效能要服务于业务，而不能让业务反过来迁就研发效能。

近一两年来，从国内一线互联网大厂开始，越来越多的企业开始重视研发效能的提升，有的公司还为此成立了专门的研效部门，在借鉴硅谷一些实践的同时，也在探索适合自己的发展道路。但想要获得研发效能的提升并非易事，下面重点盘点一下研发效能落地过程中一些典型的成功或失败的案例，并从中提炼出一些常见的困境和问题、值得借鉴的做法和解决方案，希望对读者能有些启发。

1.3.1 研发效能实施过程中的常见困境

你是否也遇到过以下的问题：

● 意识到研发效能要提升，却不知如何下手？

● 业务实在太忙，根本没空做研发效能，怎么办？

● 要做出场面，就得自上而下强推一致性和标准规范？

● 折腾了好几个月，但发现效率指标反而下降了，怎么办？

● 领导要求快速见效，能不能动用绩效考核、行政手段来推进？

● 工具不完善，标准规范只能“人肉”来扛，效率更低了怎么办？

● 费了好大力气做出工具，却引来一片吐槽，用不起来怎么办？

● 研发效能到底能不能度量？度量之后开始有人刷分造数据，怎么办？

某中等规模企业要做研发效能提升，相关负责人希望能找到一个抓手并快速见效，于是想到硅谷标杆公司Google、Meta都非常推崇单元测试，业界还流行一种测试金字塔模型，据说单元测试应该占70%以上的比例。而当前企业的现状是单测基础很薄弱，大家也没有写单元测试代码的习惯，于是决定从强推单元测试开始。

先找了一个部门开始试点，这个部门的业务范围很庞大，既有稳健增长的业务，也在布局一些探索中的新业务，还维护公司的一些核心框架和基础库。

那么，怎么推进呢？先定义研发标准，即新提交的代码都要被单元测试覆盖。

怎么衡量效果呢？就定义一个指标，即单元测试增量覆盖率。

如果研发团队不配合怎么办？就硬性要求，进行考核。如果单元测试指标不达标，考核就减分，绩效就会受影响。

由于企业领导很关注研发效率的事情，业务研发团队虽然觉得这个要求太高，但也没办法，只能先试试。于是这场“研效提升”运动裹挟着各种不同的认知，就轰轰烈烈地开展了。

过了一段时间，企业内出现了很多“不和谐”的声音。

首先是很多一线工程师吐槽研发效率大幅降低，再不改变就只能离职了。有人反馈说：“原来3天就能完成的需求，现在至少需要5～6天才能完成。比如，针对单元测试增量覆盖率指标的硬性要求，如果想对一个遗留文件里的3行代码进行修改，而这个文件有一个500行的函数，就需要把这个函数拆解/重构并Mock后写单测，开发人员的工作量太大了，又没有为这些多出来的工作预留时间，只能靠高强度的加班来做，质量其实根本无法保证，这个压力不能只让一线工程师来扛！”

后来，有些一线研发管理者也反馈说：“研发标准‘一刀切’，根本没有考虑实际情况。比如，对于核心逻辑、核心框架、基础库等多方依赖引用且需求相对固定的情况，确实要尽可能覆盖高质量的单元测试，但一般的业务逻辑（尤其是处于探索状态的新产品和新业务）应该以业务的交付效率为重，因为快速上线验证产品的思路更重要。有些业务很可能上线后不符合产品预期，后续也不会迭代，对于这部分代码，没必要将时间浪费在追求高指标上。而且在考核的压力之下，发现好多人的单元测试都是用工具自动生成的，纯粹是为了凑数，根本就是无效的，反而牺牲了很多做有效工作的时间。建议给一线管理者一定的灵活性，能自主决定推进的方式和强度，而不是被某些指标牵着鼻子走。”

业务部门其实也并不买账：“好多需求等着排期，而研发人员说要搞研发效能，没时间做，这无法接受。而且最关键的是之前做的研发效能提升并没有看到实际的收益。”

正所谓“冰火两重天”，最怕一边热火朝天地推进各种研发效能提升措施，另一边各种来自一线的吐槽声不绝于耳，最终看起来是做一些费力不讨好、价值也解释不清楚的事情。

我相信，大家对追求研发效能提升这一目标都是认同的，也都是带着一腔热情想把事情做好。既然大方向没错，那么遇到这些问题很可能就是执行策略和方法的问题了。

下面介绍如何避免“大跃进式”、虚假繁荣的研发效能提升运动，通过灵活、务实地解决问题让研发效能提升有效落地。

1.3.2 明确你在研发效能提升中所扮演的角色

研发效能的提升是一个复杂的系统性工程。在具备一定规模的企业中，参与到研发效能提升中的组织或团队大概有以下几类。

● 业务研发团队：负责业务端到端的研发过程，对交付的结果全权负责。这个团队的首要目标是实现业务需求，但过程可能会碰到效率、质量、安全等方面的问题和挑战，需要在研发效能专业方向上得到一些支持和帮助。

● 工具平台团队：由于研发的日常工作都是基于工具平台承载的，因此工具的效率就会对业务研发团队的交付效率产生正面或负面的影响。工具平台团队一方面要提供高质、高效的服务能力，另一方面也要想办法降低用户（业务研发团队）的认知负荷，提升工程师的使用体验。

● 效能专家或教练团队：由研发效能领域的专家组成，比如效能专家、敏捷教练、工程教练等，主要目标是赋能业务团队，补齐业务团队研发效能的能力短板，对其进行服务化的能力支撑。通过传播和推广新理念、新实践、新技术、新工具，帮助业务研发团队达成更优的交付效率和质量。

● 组织级研效管理团队：比如，技术委员会或制定研发效能标准的团队。职责通常包括确定研发效能提升的高阶目标，确定每个阶段的整体推进策略，组建研发效能的部门或团队（实体/虚拟），发布相关的标准、规范或制度等。

在规模较小的企业中，可能并不存在这样完整编制的团队，但一定会有负有相关责任的角色，哪怕是一个人承担了多种角色，因为想要获得效能提升，这些事情总要有人做。

1.3.3 清楚应该做什么和不能做什么

1.业务研发团队

业务研发团队可以根据当前业务和产品所处阶段，确定研发效能提升的重点和目标，并通过正确、适当地使用度量，对效能提升的效果进行洞察。

（1）理解业务和产品所处的阶段，即明确业务和产品是在初创期、成长期、成熟期，还是衰退期；是要快速探索以最快的速度占领先机，还是要稳定增长，尽量规避质量上的瑕疵。明确阶段定位对找准效能提升的方向非常关键。

（2）根据阶段现状确定研发效能提升的重点。问题，要先于解决方案。效能的提升是从痛点出发的，如果现阶段就是要更快地交付，则在技术上可以选择先主动负债，架构解耦、自动化测试的全面覆盖都可以后面再补。如果现阶段就是要更加稳定，而高并发的在线支付业务、线上缺陷会带来巨额资金损失的风险，则需求交付效率其实“正常发挥”就好，并没有那么急迫。因此，针对不同的上下文，研发效能提升的重点也各不相同，我们可以根据重点设置不同的目标。

（3）明确研发效能提升的目标。业务研发团队当然应该优先实现业务目标，但是对于想长期可持续发展的组织来讲，既要关注当前业务目标的快速交付，也要兼顾中长期的研发效能提升。正所谓“磨刀不误砍柴工”，就像微软的CEO萨提亚·纳德拉所倡导的：“提升研发生产力的工作与交付新的业务需求同等重要”。

以前做业务追求先赢和交付速度，负债运行都没问题，但这是有代价的。我们看到，一些企业文件级的代码重复率达到80%以上，这是高技术债的明确信号，也是对资源的巨大浪费。一切都是为了快，很多代码没有注释和文档，实现逻辑混乱，根本没人做过代码评审，只关注线上是否能跑通，这样的“祖传”代码没人敢碰，一旦发生故障也没人能维护。

研发效能提升其实是业务研发团队自己的事情，所做的效能改进工作，最终也是为可持续地实现业务目标服务的。因此，要根据实际的研发痛点，针对性地设置研发效能改进或提升的目标。如果自己都看不到问题或提不出需求，工具平台或专家、教练团队也是爱莫能助。

（4）将度量指标作为参考，辅助决策。研发效能度量很重要，需要进行策划和推进，但方式和方法要得当。如果把度量作为考核的“武器”，风险会比较大，最好是回归到辅助参考和决策，以及洞察问题的本质上去。

很多企业都会度量需求前置时间（Lead Time），如果真实情况就是十多天，与部门期望的有些差距，那就需要先做复盘，然后定期分析引发超时的原因，再针对性地优化与提升。千万不要因为考核，单纯地去追求指标好看，用一些“短视”的手段去“粉饰”太平，从而掩盖真正的问题，丧失改进的机会。

2.工具平台团队

工具平台团队应该提供简单、易用的效能平台，支撑业务研发团队的日常研发活动，向下屏蔽复杂的系统实现，向上提供简约、整合好的平台能力，在不增加工程师认知负荷的前提下，优化研发每一步的工作场景，提升其工作效率。

（1）拥抱开发者体验。我们经常看到，一些企业的研发效能平台都是优先面向管理者服务的。比如，提供一些项目和敏捷管理能力，用于管理项目立项和需求流转过程；提供一个管理驾驶舱，用于查看研发过程中项目、需求、代码、缺陷、工时的各种数据；提供各式各样的报表、报告等。当然，这些很有价值，但却忽略了为研发过程中最庞大的用户群体——工程师服务。

比如，最基本的从大库中拉取代码要够迅速；编译构建速度要够快；部署发布要够简单，最好能“一键式”操作；无论工具平台逻辑多复杂，提供给工程师的都是最简化、已聚合好的工作台。

图1.3.1展示了百度代码管理工具iCode的代码评审页面。可以看到，在代码提交时，工具会自动触发一系列代码扫描、检查和测试的校验，并有质量门禁的守护。比如，先是代码风格（编码规范）检查、代码静态扫描、代码可维护性检查、安全检查、持续集成（触发一条流水线进行动态测试验证）等，最后才是人工评审。

工程师每天用得最多的是写代码的IDE（Integrated Development Environment，集成开发环境），然后就是这个页面。这里屏蔽了底层复杂的逻辑和系统调度实现，呈现给工程师的是非常清晰、简单、易用、整合之后的信息，能真正帮助工程师不再操心细节，摆脱烦琐的操作，从而提升效率。

优秀的研发效能平台要拥抱开发者体验，并且对使用者基本是透明、无感的，从代码提交到上线过程要高度自动化。工程师提交代码后，工具平台就能触发一系列动作，工程师不必过于关心如何实现，只要稍作等候就能收到平台的处理结果和反馈通知。

（2）优化微反馈回路。微反馈回路是指研发人员每天要做几百次，甚至上千次的小事情。比如，在修复错误的同时运行单元测试、在本地或开发环境中进行的代码变更、刷新配置或数据并重新运行测试、在生产环境中发布变更并进行业务监控等。这些操作非常高频，但由于每个点看起来很小且过于普通，因此经常被研效平台设计者忽略，如图1.3.2所示。

如果每个人每次在这些操作上浪费几分钟，因为重复的次数非常多，每天被浪费的时间可能就要以小时来记了。更严重的是，这些小的停顿会让研发失去注意力并丢失上下文。有研究表明，如果工程师的工作被打断并脱离心流状态，则可能需要长达23分钟才能恢复到之前的高生产力水平。

如果反馈回路较短，则研发人员将倾向于更频繁地执行反馈回路，这样持续集成和持续交付才能做起来。更早、更频繁地进行验证可以减少后期的返工，简单、易于解释结果的反馈回路，减少了来回通信和认知开销。

笔者所在的部门一直负责一站式DevOps平台的建设，近期的重点就是优化研发过程中的微反馈回路，虽然这看起来没那么亮眼，但却是一项比较务实的研发效能提升工作。

如图1.3.3所示，我们会先统计使用最频繁的流水线插件（如代码拉取、编译构建、推送镜像、单元测试、代码扫描、安全扫描、自动化部署、自动化测试、灰度发布等），然后监控这些插件的执行时长和稳定性；先统计高频使用的服务接口（如创建需求、创建任务、创建分支、创建合并请求等），然后监控这些接口的时效性和有效性。

我们还会关注稍微全局一些的指标，如研发前置时间（从代码最后一次提交或合并到远端仓库上的主分支，到对应制品首次部署到生产环境的时间），因为这个指标反映了从代码完成到被投产使用之间的时间，其一般是越短越好，越短代表工具平台优化得越好，团队工程能力越强，这也是DevOps最常统计和对比的指标之一。

总之，对于研发过程来讲，这些看起来也许都是很不起眼儿的小事，但从务实的角度来说却很重要。每个微反馈回路的优化都非常关键，都可以让工程师减少等待时间和被打断的次数，并且不必处理不必要的复杂和琐碎的手工操作或长时间的延迟，而将全身心聚焦在创造性、增值的研发活动上。

（3）完善一站式体验。在对每个微反馈回路进行关注和优化的基础上，也要完善研发效能平台的一站式体验。

我们经常看到，很多企业所谓的“一体化”平台都是按功能领域（如项目域、代码域、测试域、部署域等）划分并展现相关能力的，或者说是一个“拼凑”起来的平台。而研发真正需要的是内部工具相互打通、深入整合具有内在逻辑串联的研发一站式平台。

工程师易用的平台一定是按照“研发场景”进行组织的，比如以特性流动为核心的敏捷协作、以应用变更为主线的交付流、以应用为中心的监控和运维等，如图1.3.4所示。

另外，工具平台还要固化研发规范和实践。只要跟着工具平台操作就能满足研发规范，这样就不再需要人为刷分了。工具可以让用户的体验变得更简单，你可能只需要提交一行代码，后面的系统就会自动帮你解析、配置，把整个流水线都串联起来。

如图1.3.5所示，工具平台在创建项目（或产品）时会进行一系列初始化的工作，包括初始化需求空间、应用、代码库、环境、监控配置等，并根据所选模板确定代码分支规范、研发流程和测试环境管理方式。

研发流程：工具平台把研发流程抽象为五个阶段，每个阶段都包含特定的任务，如代码扫描、单元测试、自动化测试、手工集成测试、发布审批等。在选定所需的流程模板后，工具平台会自动创建流水线，用于任务的串联，在提升自动化水平的同时，提升项目的安全性和合规性。

测试环境：提供基线环境和特性环境组合的能力，帮助用户快速自动创建、部署测试环境，并实现测试环境之间路由调用的自动化配置，帮助开发人员灵活、互不干扰地进行测试，提高协作效率。

在这个例子中，研发过程中大部分高频、重复、确定的活动都已经根据所选择的研发模式或流程的模板定义好了，过程中相关的自动化能力由工具平台按需提供，这样工程师就可以不用操心遵循的流程、如何配置流水线、如何获取环境的事情，把精力更多集中在创造性或需要人工实现的活动上。

（4）实现产品化运作。很多设计和开发研发效能平台的团队都是从做某个领域的小工具开始，逐步演化而来的，从技术的角度设计和实现特定的功能还比较有优势。但有些人员其实并不是专业产品经理出身，他们从技术角度考虑的问题比较多，但“站在用户视角上”对产品进行思考方面做得不够。这样，做出来的工具平台可能会在体验和易用性上与商业或专业产品存在一定差距。

优秀的研发效能平台建设应该实现产品化运作，我们应该使用与用户产品研发相同的方法进行设计和构建，使用相同的用户研究方法、产品规划方法、优先级排序方法，并且建立基于结果的思维方式和用户运营、用户反馈机制。要定期走近用户，倾听用户的声音，结合满意度调查等手段，找到并解决用户遇到的研发效能“真问题”，这样的效能平台才能被更多的人认可和使用。

正如，某大厂研发人员所说：“工具平台团队要以稳定而统一的研发基础服务去支持业务的奇思妙想和各种创新，有时甚至是不靠谱的创意，这也包括了要能对即使是最烂的代码提供最好的研发基础服务支持。”

上面说的是工具平台团队应该要做的事情，但也有一些事情要尽量避免。

（1）强推工具平台。在工具平台推广方面，要注意方式方法，如果不区分业务所处的阶段和不同的研发场景，强加给用户某一种特定的研发模式，即使对方迫于压力接入了，但可能由于缺少具体的使用场景，根本用不起来。

在某个研发工具推广案例中，就看到有研发人员吐槽：“一些既不了解业务也不写业务代码的人，做出一些既不稳定也未经实战检验过的工具，生搬硬套，要业务研发团队接入，接入不顺利还要给业务研发团队扣分”。从这则反馈可以看出，一线的工程师对推广这样的研发工具意见非常大，认为这对他们的工作没有实质性的帮助，这种强行推广的真实效果可想而知。

因此，工具平台的接入要从解决问题的角度推进，不能忽略研发人员的工作环境。在推进的过程中，也要循序渐进，不要一次性引入太多的新名词、新工具或新流程，以免让研发人员日常工作的复杂性和摩擦急剧增加。

还有一点非常重要，就是要关注工具平台的迁移成本。如果用公式来表达，工具平台的价值=（新版体验-旧版体验）-迁移成本。一个新产品想要落地，除了应该带来更好的体验，还需要有较低的迁移成本。

工具平台团队需要提供专业的服务能力。如果必须要做迁移，最好也是工具平台团队提供迁移工具实现自动迁移，或是派人到业务团队去服务，帮助他们完成迁移。

（2）不开放的封闭系统。研发效能工具平台也要避免各自为战，每个都聚焦做SaaS，而对开放接口避而不谈。从行业的普遍情况来看，企业某个研效部门做出来的工具平台，很难100%承接住所有不同业务研发团队提出的个性化需求，因此最终还是要走向开放。

比如，通过开放模块、插件、API等形式对外扩展，跟企业其他团队的工具能力形成友好的生态共建关系，大家一起合力把“蛋糕”做大。在流水线系统上，除官方插件外，各种由第三方提供的插件就是开放生态最典型的例子。

3.效能专家或教练团队

效能专家或教练团队旨在帮助业务团队弥合研发效能方面的能力差距，使之能够持续保持效率和质量上的高水准。除了解决实际问题，也要注重提升业务研发团队自身的相关能力，最终的目标是在效能专家撤离后，业务研发团队能够持续高效地独立工作。

（1）为业务研发团队赋能。效能专家或教练团队要明确业务研发团队当前的痛点和问题，牵头制定解决方案并让各个参与的角色形成合力。比如，协同工具平台团队共同制定接入计划和推进策略；协同开发团队按照定制的研发流程进行交付过程的优化，逐步实现开发中的质量内建，并持续提升开发效能；协同测试团队进行自动化测试的分级分层设计，形成质量防护网，并增加探索性测试等对版本质量进行兜底的能力。

如图1.3.6所示，效能专家或教练团队要深入研发一线，通过方法的导入和实践的落地，引领研发模式的更新升级、研发效能的稳步提升、人员技能的持续进步；要通过教练引导业务研发团队对有问题的研发过程实施干预，从而使团队朝正确的方向演进。

效能专家或教练团队还需要对行业中涌现出的优秀实践保持敏感并持续学习内化。

对于代码评审，Google公开的工程实践文档中对其进行了详细说明，很有参考价值。比如，对于一个CL（Change List，即已经提交给版本控制或正在接受代码评审的一个独立的变更），为了让评审更有效，关注要点为查看CL内容是否有意义且是否拥有清晰的描述、评审CL最核心的部分是否经过良好的设计、按适当顺序查看CL的其余部分。

效能专家或教练团队要对这些优秀实践非常熟悉，并将其进行总结提炼和抽象加工，以易于理解的方式传授给业务研发团队。图1.3.7展示了基于业界优秀实践整理的CL评审要点，其从整体到细节分为三个步骤，每个步骤如果不满足条件就直接结束评审，这样的评审效率会更高。

（2）提炼效能提升知识库。效能专家或教练团队应该把成功案例和效能提升经验整理为效能提升知识库，并与工具平台团队、组织级研效管理团队频繁互动，让来自一线的实践经验被吸纳为组织资产，让研效提升的决策和工具平台的设计更为务实、落地。

4.组织级研效管理团队

组织级研效管理团队的主要工作是确定研效提升的高阶目标，确定每个阶段的整体推进策略，组建研发效能的部门或团队（实体/虚拟），发布相关的标准、规范或制度等。

（1）从整体上推进研效重大事项。比如，制定公司统一的代码规范，推广公司统一的编码风格，减少开发人员和团队之间的代码风格差异，并以此为出发点，普及代码质量意识，推广代码文化，推进跨业务间的代码评审，以此提升公司开发人员的整体代码质量。在公司内构建易于使用的统一软件源服务，满足研发人员在环境搭建、开发、构建、测试等环节的组件和工具依赖需求，提升组织的整体研发效能。另外，还有很多研发效能整体治理的工作，比如编译器版本的统一、组织内同领域不同研效工具底层元数据的对齐、跨领域不同研效工具的相互打通串联、组织级研发效能平台的整体设计等。

总体来说，组织级研发效能管理团队负责公司研发效能领域的顶层规划，加强底层研发基础设施协同共建，促进研发工具平台间串联打通，另外还要推进工程师文化的形成。

（2）适当推进研发效能度量。需要注重将度量指标与目标联系起来，确保所选的度量（指标）始终与其目的（目标）关联。组织级研效管理团队有责任确保组织的时间不会浪费在收集和维护不必要的指标上。

在软件研发场景中，可能会看到如下定义的指标。

方法必须少于80行，方法的参数不能超过4个，方法圈复杂度不得超过20。

为了让研发理解设定这个度量指标的目的，应该将其转化为如下的描述方式：

我们希望代码不那么复杂，并且更容易修改，因此，我们的目标是编写具有较低圈复杂度（小于20）的短方法（少于80行），参数也尽量少（最多4个），以便方法尽可能保持专注，也具备更好的可读性。

我们有时候也会碰到这样一种情况，就是单纯从数字来看，效能度量指标有了提升，比如交付效率和吞吐量都在提高，但业务部门却仍不满意。他们反馈：“好像并没有什么变化！”那么，这个时候我们应该相信谁，是数据部门还是业务部门？正如，杰夫·贝佐斯（Jeff Bezos）所说：“我注意到的是，当传闻和数据不一致时，传闻通常是正确的。”很可能是你度量的方法有问题，或是数据已经失真，这就需要进一步的检视和反思了。

丰田的大野耐一曾经说过：“那些不懂数字的人是糟糕的，而最糟糕的是那些只盯着数字看的人。”每个数字背后都有一个故事，而这个故事往往包含比数字本身所能传达的更重要的信息。现场观察是一个可以与度量结合使用的强大工具，管理团队要到实际的研发交付过程中观察需求和价值的流转过程，看团队是如何进行研发交付的。正式的度量和非正式的观察是相辅相成的，可以对结果进行相互印证。

另外，度量还要从简单地对指标进行观测，进一步延伸到对研发活动进行更深度的洞察上，目前很多头部企业正在进行这方面的探索。

除了上述建议做的事情，还有一些不建议做的。

比如，不要过度控制，盲目推崇一致性。在一些相对稳定的场景下，一致性可以帮助业务研发团队提高效率。但如果脱离产品所处阶段和业务实际情况，盲目推崇一致性，为了统一而统一，反而会给业务研发团队带来很多额外的负担，某种程度上也会抑制创新，这样很难带来所期望的价值。

在《复杂》一书中介绍了一个有意思的案例。沙丁鱼群是一个很复杂的体系，分散的个体几乎没有抵御天敌的能力。但当鲨鱼游进鱼群时，沙丁鱼会迅速自然散开，形成一个可供鲨鱼通过的洞，鲨鱼什么也没吃到就穿过了洞口，当它回头再咬的时候，新的洞口又出现了，鲨鱼只能无功而返，如图1.3.8所示。

这种集体智慧从何而来？科学家们做了大量的研究，发现秘密存在于沙丁鱼基因中的三行“代码”：跟紧前面的鱼；与旁边的鱼保持等距离；让后面的鱼跟上。

沙丁鱼群表现出来的行为是复杂的，虽然并没有一个更高层的“大脑”在做整体控制，但每条鱼只需要遵守这三条原则，鱼群就能表现得非常完美。

这个案例带给我们一些启示，研发场景下的复杂度非常高，基本上无法通过“上帝视角”来规划和定义一切，但是我们可以明确一些大家都要遵守的基本规则。

因此，我们建议不要过度控制，要更多地给个体赋能，在一定程度上尊重和发挥个体的智慧，但是要设定一些大家都遵循的集体规则，这是底线。

1.3.4 不躺平、不内卷，行稳致远

本章主要介绍了如何通过灵活、务实地解决问题，让研发效能提升有效落地，避免“大跃进式”、虚假繁荣的效能提升运动，以及研发效能提升中四类团队应该做什么和不建议做什么。这些内容可以作为研发效能推进过程中的模式和反模式进行参考，也许你的具体场景和上下文有所不同，但这些原则和做法都是相通的。