| 编辑推荐: |
本文主要介绍研发效能落地过程中的典型成功/失败的案例，提炼出一些值得借鉴的做法，希望对你有一些启发。
本文来自于CSDN ，由火龙果软件Alice编辑，推荐。 |
|
如今我们已经身处数字化时代，如何能以更快的速度、更高的质量研发和交付，是企业普遍关注的话题。
在国内，从一线互联网大厂开始，越来越多的企业开始重视研发效能的提升，有的公司还为此成立了专门的研效部门，在借鉴硅谷一些实践的同时，也在探索适合自己的发展道路。
本文会盘点一下研发效能落地过程中的典型成功/失败的案例，提炼出一些值得借鉴的做法，希望对你有一些启发。
— 1 —
"研发效能"是今年的热词
大概是从今年开始，研发效能更火了，国内成功举办了专注于研发效能这一领域的技术大会，发布了研发效能宣言，也有相关书籍出版（或即将出版）。对我个人来说，能深度参与到这波浪潮之中并与之同行，也是一件非常有意义的事情。
但是，要想研发效能获得实际提升也并非易事，今年以来我看到挺多有意思的案例，成功的也好、不理想也罢，总是有很多相似的故事每天轮番上演。
本文我们就来分析一下，推动研发效能提升时常见的困境，以及有什么样的解法。
你是否也遇到过以下的问题：
意识到研发效能要提升，却不知如何下手？
业务实在太忙，根本没空搞研效，怎么办？
要搞出场面，就得自上而下强推一致性和标准规范？
折腾了好几个月，但发现效率指标反而下降了，怎么办？
领导要求快速见效，能不能动用绩效考核、行政手段来推？
工具不完善，标准规范只能人肉来扛，效率更低了，怎么办？
费了好大力气做出工具，却引来一片吐槽，用不起来，怎么办?
研发效能到底能不能度量？度量之后开始有人刷分造数据，怎么办？
举个例子
某小企业要搞研发效能提升，相关负责人希望找到一个抓手并快速见效，于是想到硅谷标杆公司Google、Facebook都非常推崇单元测试，业界还流传一个测试金字塔模型，据说单元测试应该占70%以上的比例。而当前现状是单测的基础很薄弱，大家也没有写单测的习惯，这可不行！于是拍板，决定要从强推单元测试开始。
先找了一个部门开始试点，这个部门的业务范围挺庞大，既有稳健增长的业务，也在布局一些探索中的新业务，还维护了一些公司的核心框架和基础库。
那怎么推呢？先定义一个研发标准吧，即新提交的代码都要被单元测试覆盖。
那怎么衡量效果呢？就定义一个指标吧，叫单元测试增量覆盖率。
那研发团队如果不配合怎么办呢？那就硬性要求，考核啊！如果单元测试指标不达标，考核就减分，绩效受影响！
由于研发效率的事情公司老板很关注，业务研发团队虽然觉得这个要求太高，无奈这也个是政治正确的事情，虽然很勉强但也没办法，那就先这样试试吧！于是这场"研效提升"的运动，就裹挟着各种不同的认知，轰轰烈烈的开展了。
过了一段时间，公司里出现了很多"不和谐"的声音。
首先是很多一线工程师跳出来反抗，吐槽研发效率大幅降低，再不改变就只能离职了。有人反馈说："原来做3天就能完成的需求，现在至少需要5-6天才能完成。比如对单元测试增量覆盖率指标的硬性要求，如果改了一个
legacy file 里的 3 行代码，而这个文件有个 500 行的函数，就得把这 500 行函数拆解/重构并
mock 后写单测，但这对于开发工作量来说大了太多，而在需求评估前极有可能预估不到这种情况。
现在业务进度要求那么紧，根本没有为这些额外多出来的工作预留时间，只能靠高强度加班来做，但质量其实根本无法保证，也不可能长期坚持下去，这个压力不能只让一线工程师来扛！"
后来有些一线研发Leader也反馈说："研发标准一刀切，考核定的太死，根本没有考虑实际的情况。比如对于核心逻辑、核心框架、基础库等多方依赖引用且需求相对固定的情况，确实要尽可能覆盖高质量的单测，但一般的业务逻辑（尤其是处于探索状态的新产品/新业务）应该以业务的交付效率为重，快速上线验证产品思路更重要。
有些业务很可能上线后不符合产品预期，后续也不会怎么迭代了，对这部分代码没必要将时间浪费在追求很高的指标上。而且考核压力之下，发现好多人的单测都是用工具自动生成的，纯粹为了凑数，里面连断言的都没有，根本就是无效的！"
为了刷这个指标，反而牺牲了很多做有效工作的时间。建议给一线Leader一定的灵活性，自主决定推进的方式和强度，而不是被某些指标牵着鼻子走。
业务部门其实也并不买账："好多需求等着排期呢，研发说因为要搞研效所以没时间做了，这无法接受。而且最关键的，之前搞的研效提升并没有看到什么实际的收益啊！"
正所谓冰火两重天，最怕就是一边热火朝天的推进各种研效提升措施，一边各种来自一线的吐槽之声不绝于耳，最终看起来是做了一些费力不讨好、价值也解释不清楚的事情。
我相信大家对追求研效提升的大目标都是认同的，也都是带着一腔热情想把事情做好。既然大方向都没错，那么遇到这些问题可能就是执行策略和方法的事儿了。
下面我就来聊一聊，如何避免大跃进式、虚假繁荣的效能提升运动，而是通过灵活务实地解决问题，让研发效能提升有效落地。
— 2 —
明确你在研效提升中所扮演的角色
研发效能的提升是个复杂的系统性工程。
在具备一定规模的企业中，参与到研发效能提升中的组织或团队大概有以下几类：
业务研发团队：负责业务端到端的研发过程，对交付的结果全权负责。这个团队的首要目标是实现业务需求，但过程可能会碰到效率、质量、安全等方面的问题和挑战，需要在研发效能专业方向上得到一些支持和帮助。
工具平台团队：研发的日常工作都是基于工具平台承载的，那么工具的效率就会对业务研发团队的交付效率产生正面或负面的影响。工具平台团队一方面要提供高质、高效的服务能力，另外也要想办法降低用户（业务研发团队）的认知负荷，提升工程师的使用体验。
效能专家或教练团队：由研发效能领域的专家组成，比如效能专家、敏捷教练、工程教练等，主要目标就是赋能业务团队，补齐业务团队研发效能的能力短板，对其进行服务化的能力支撑。通过传播和推广新理念、新实践、新技术、新工具，来帮助业务研发团队达成更优的交付效率和质量。
组织级研效管理团队：比如技术委员会或制定研效标准的团队。职责通常包括：确定研效提升的高阶目标，确定每个阶段的整体推进策略，组建研发效能的部门或团队（实体/虚拟），发布相关的标准、规范或制度等。
在规模小一些的企业中，可能并不存在这样完整编制的团队，但一定会有负有相关责任的角色，哪怕是一个人承担了多种角色，但想要获得效能的提升，这些事情总要有人做的。
下面我们就分别看一下，每个团队都应该怎么做。
— 3 —
搞清楚你应该做什么，不能做什么
一、业务研发团队
业务研发团队可以根据当前业务和产品所处阶段，确定研发效能提升的重点和目标，并通过正确、适当地使用度量，对效能提升的效果进行洞察。
应该要做的：
理解业务和产品所处的阶段
业务和产品是在初创期、成长期、成熟期还是衰退期。是要快速探索、以最快的速度占领先机，还是要稳定增长、尽量规避质量上的瑕疵呢？明确的阶段定位对于找准效能提升的方向选择非常关键。
根据阶段现状，确定研发效能提升的重点
问题，先于解决方案。效能的提升是从痛点出发的，如果现阶段就是要更快地交付，而在技术上可以选择先主动负债，比如架构解耦、自动化测试的全面覆盖都可以后面再补。如果现阶段就是要更加稳定，比如高并发的在线支付业务，线上缺陷会带来巨额资金损失的风险，而需求交付效率其实"正常发挥"就好，并没那么急迫。所以针对不同的上下文，研发效能提升的重点也是各不同的，可以设置不同的目标。
明确研发效能提升的目标
业务研发团队当然应该优先实现业务目标，有大把的业务需求需要实现。但是对于想长期可持续发展的组织来讲，既要关注当前业务目标的快速交付，也要兼顾中长期的研发效能提升。正可谓磨刀不误砍柴工，就像微软的CEO萨提亚·纳德拉所说的："So
I would, any day of the week, trade off features for
our own productivity"，提升研发生产力的工作与交付新的业务需求同等重要。
以前追求做业务要先赢、追求交付速度，负债运行没问题，但这是有代价的。我们看到一些企业里面文件级的代码重复率达到了惊人的80%以上，这是高技术负债的明确信号，也是对资源的巨大浪费。如果都为了快，很多代码一没有注释，二没有文档，实现逻辑混乱，根本没人做过代码评审，以前只关注线上能跑通，这样的"祖传"代码没人敢碰，一旦发生故障也没人能维护。
研发效能提升其实是业务研发团队自己的事情，所做的效能改进工作，最终也是为可持续地实现业务目标服务的。所以，要根据实际的研发痛点，针对性设置研发效能改进或提升的目标。如果自己都看不到问题或提不出需求，工具平台或专家教练团队也是爱莫能助。
度量指标作为参考，辅助决策
研发效能度量很重要，还是需要去策划和推进的，但要方式、方法要得当。把度量作为考核的"武器"风险比较大，最好是回归到辅助参考和决策，以及洞察问题的本质上去。
举个例子
很多企业都会度量的需求前置时间（ Lead Time），如果真实情况就是10多天，与部门期望还有些差距，那大不了去做一下复盘，然后定期分析一下是哪些原因引发的超时过多，再针对性地优化与提升。
千万不要因为考核，单纯为了追求这个指标好看，用一些短视的手段去粉饰太平，从而掩盖了真正的问题，反而丧失了改进的机会。
二、工具平台团队
工具平台团队应该提供简单、易用的效能平台，支撑业务研发团队的日常研发活动。向下屏蔽复杂的系统实现，向上提供简约、整合好的平台能力，在不增加工程师认知负荷的前提下，"润物细无声"地优化研发每一步的工作场景，提升其工作效率。
应该要做的：
拥抱开发者体验
我们经常看到一些企业的研发效能平台都是优先面向管理者服务的，说直白点就是面向老板编程。比如提供一些项目和敏捷管理能力，可以管理项目立项、需求流转过程；提供一个管理驾驶舱，可以查看研发过程中项目、需求、代码、缺陷、工时的各种数据，提供各式各样的报表报告等。这些当然也很有价值，但是有时却忽略了为研发过程中最庞大的用户群体--工程师--服务。
比如最基本的，从几个G的大库中拉取代码要够迅速，编译构建速度要够快、部署发布要够简单，最好能一键式操作，无论工具平台逻辑多复杂，提供给工程师的是最简化、已聚合好的工作台。
举个例子
下图是百度代码管理工具iCode的代码评审页面。可以看到在代码提交时，工具会自动触发一系列代码扫描、检查和测试的校验，并有质量门禁的守护。比如代码风格（编码规范）检查、代码静态扫描、代码可维护性检查、安全检查、持续集成（触发一条流水线进行动态测试验证）等，最后才是人工评审。
工程师每天用的最多的是写代码的IDE，然后就是这个页面。这里屏蔽了底层复杂的逻辑和系统调度实现，呈现给工程师的是非常清晰、简单、易用、整合之后的信息，真正帮助工程师不用再操心细节、摆脱繁琐操作，从而提升效率。
优秀的研发效能平台，应该要拥抱开发者体验，并且对使用者是基本透明、无感的。从代码提交到上线过程是高度自动化的，工程师提交代码后就可以由工具平台触发一系列动作，工程师不必过于关心如何实现，只要稍作等候就能收到平台的处理结果和反馈通知。
优化微反馈回路
前一阵看国外有篇文章提到了"微反馈回路"一词。这是指研发人员每天要做几百次、上千次的小事情。比如在修复错误的同时运行一下单元测试、在本地或开发环境中进行的代码变更、刷新配置或数据并重新运行测试、在生产环境中发布变更并进行业务监控等。这些操作非常高频，但由于每个点看起来很小且过于普通，经常被研效平台设计者忽略。
如果每个人每次在这些操作上浪费几分钟，但因为会重复非常多次，每天被浪费的时间可能就要以小时来记了。更严重的是，这些小的停顿是让研发失去注意力并丢失上下文的机会。有研究表明，如果让工程师工作被打断并脱离了心流状态，可能需要长达
23 分钟才能恢复到之前的高的生产力水平。
如果反馈回路较短，研发人员将倾向于更频繁地执行反馈回路，这样持续集成、持续交付就才能做的起来。更早、更频繁地进行验证可以减少后期的返工。简单、易于解释结果的反馈回路，减少了来回的通信和认知的开销。
举个例子
我所在的部门一直在负责一站式DevOps平台的建设，近期的重点就是在优化研发过程中的这些微反馈回路，虽然看起来没那么亮眼，但这是一项比较务实的研发效能提升的工作。
比如，我们会统计出来使用最频繁的流水线插件（如代码拉取、编译构建、推送镜像、单元测试、代码扫描、安全扫描、自动化部署、自动化测试、灰度发布等），然后监控这些插件的执行时长和稳定性；我们会统计出来高频使用的服务接口（如创建需求、创建任务、创建分支、创建合并请求等），然后监控这些接口的时效性和有效性。
我们还会关注稍微全局一些的指标，比如研发前置时间（从代码最后一次提交或合并到远端仓库上的主分支，到对应制品首次部署到生产环境的时间），因为这个指标的反映出了从代码写好到可以被投产使用之间的时间，这个指标一般是越短约好，越短则代表工具平台优化的越好、团队工程能力越强，这也是DevOps圈中最常统计和对比的指标之一。
总之，对研发过程来讲，这些看起来也许都是很不起眼儿的小事，但从务实的角度来说却很重要。每个微反馈回路的优化是非常关键的，可以让工程师减少等待、打断，不必处理不必要的复杂性、琐碎的手工操作或长时间的延迟，使他们能够全身心聚焦在创造性的、增值的研发活动上。
完善一站式体验
在每个微反馈回路都关注和优化的基础上，我们也要完善研发效能平台的一站式体验。
经常看到很多企业所谓的"一体化"平台是按功能领域（如项目域、代码域、测试域、部署域等）进行划分并展现相关能力的，或者说是一个"拼凑"起来的平台，就像一本黄页一样把各种工具简单地堆砌在一起。
而研发真正需要的不是小时候玩儿电子游戏时的那种"十八合一"的游戏卡，而是内部工具相互打通、深入整合后的、有内在逻辑串联的研发一站式平台。
让工程师使用趁手的、易用的平台一定是按照"研发场景"进行组织的，比如：以特性流动为核心的敏捷协作，以应用变更为主线的交付流，以应用为中心的监控和运维等等。
另外，工具平台还要固化研发规范和实践。只要跟着工具平台走来就能满足研发规范，这样就不再需要人为去刷分了。工具可以让用户的体验变得更简单，你可能只要提交一行代码，后面的系统会自动帮你解析、帮你配置，把整个流水线都串联起来。
举个例子
如下图所示，工具平台在创建项目（或产品）的时候会进行一系列初始化的工作。包括初始化需求空间、应用、代码库、环境、监控配置等，并根据所选模板确定代码分支规范、研发流程和测试环境管理方式。
研发流程：工具平台把研发流程抽象为五个阶段，每个阶段包含特定的任务，如代码扫描、单元测试、自动化测试、手工集成测试、发布审批等，选定所需的流程模板后，工具平台会自动创建出流水线用于任务的串联，在提升自动化水平的同时，提升项目安全性和合规性。
测试环境：提供基线环境和特性环境组合的能力，可以帮助用户快速自动创建、部署测试环境，并实现测试环境之间路由调用的自动化配置，帮助开发人员灵活、互不干扰地进行测试，提高协作效率。
在这个例子中，大部分研发过程中高频的、重复性的、确定性的活动都已经根据所选择的研发模式或流程的模板定义好了，过程中相关的自动化能力会由工具平台按需提供，这样工程师就可以不用操心遵循什么样的流程、如何配置流水线、如何获取环境，而把精力更多集中在创造性或需要人工实现的活动上了。
实现产品化运作
很多设计和开发研发效能平台的团队都是从做某个领域的小工具开始，逐步演化而来的，从技术角度设计和实现特定的功能还比较在行。但有些同学其实并不是专业产品经理出身，他们会从技术角度考虑问题比较多，而"站在用户视角上"对产品进行思考则普遍做的不够。这样做出来的工具平台可能会在体验和易用性上与商业或专业产品存在一定差距。
优秀的研发效能平台建设，应该实现产品化运作。应该使用与用户产品研发相同的方法来进行设计和构建，应用相同的用户研究方法、产品规划方法、优先级排序方法，并且建立基于结果的思维方式和用户运营、用户反馈机制。要定期走近用户，倾听用户的声音，结合满意度调查等手段，找到并解决用户遇到的研发效能"真问题"，这样的效能平台才能被更多的人认可和使用。
正如某大厂研发同学所说："工具平台团队要以稳定而统一的研发基础服务去支持业务的奇思妙想各种创新，有时甚至是不靠谱的创意，这也包括了要能对即使是最烂的代码做出最好的研发基础服务支持。"
不建议做的：
上面说的是工具平台团队应该要做的事情，但也有一些事情是要注意尽量避免的。
强推工具平台
好不容易把工具平台做出来了，那下一步自然就是推广了，让业务研发团队多多使用起来。
但这时也要注意方式方法，如果不区分业务所处的阶段和研发场景，强加给用户某一种特定的研发模式。即使对方迫于行政命令的压力接入了，可能由于缺少具体的使用场景，后面也仅仅会是摆摆样子，实际根本就用不起来。
举个例子
在某个研发工具推广的案例中，就看到有研发吐槽："一些既不了解业务也不写业务代码的人，搞出一些既不稳定也未经实战检验过的工具，然后生搬硬套要业务研发团队接入，接入不顺利还要给业务研发团队扣分。"
从这则反馈可以看出来，一线的工程师对推广这样的研发工具意见非常大，认为这对他们的工作没有实质性的帮助，这样强行推广的真实效果可想而知。
所以工具平台的接入是要从解决问题的角度推进的，不能忽略了研发人员的工作环境。在推进的过程中也要渐进式来做，也不要一次性引入太多的新名词、新工具，亦或是太多的新流程，让研发人员的日常工作复杂性和摩擦急剧增加。
还有一点非常重要，就是要关注工具平台的迁移成本。如果用公式来表达，工具平台的价值 = ( 新版体验
- 旧版体验 ) - 迁移成本。一个新产品想要落地，除了应该带来更好的体验之外，还需要有够低的迁移成本。
工具平台团队，需要提供专业的服务能力。如果必须要做迁移，最好也是工具平台团队提供迁移工具实现自动迁移，或是派人到业务团队去服务，去帮助他们完成迁移。
不开放的封闭系统
研发效能工具平台也要避免要各自为战，每个都聚焦在做SaaS，而对开放接口避而不谈。从行业里面的普遍情况来看，企业中某个研效部门做出来的工具平台，很难100%承接住所有不同业务研发团队提过来的个性化需求，因此最终还是要走向开放。
比如通过开放模块、插件、API等形式对外扩展，可以跟企业里面其他团队的工具能力形成友好的生态共建关系，大家一起合力把蛋糕做大。在流水线系统上除官方插件外，各种由第三方提供的插件就是开放生态最典型的例子。
三、效能专家或教练团队
效能专家或教练团队旨在帮助业务团队弥合研发效能方面的能力差距，使之能够持续保持效率和质量上的高水准。除了解决实际问题，也要注重提升业务研发团队自身的相关能力，最终的目标是在效能专家撤离后，业务研发团队能够持续高效地独立工作。
应该要做的：
为业务研发团队赋能
效能专家或教练团队要明确业务研发团队当前痛点和问题，牵头制定解决方案并让各个参与的角色形成合力。比如可以协同工具平台团队，共同制定接入计划和推进策略；可以协同开发团队，按照定制的研发流程进行交付过程的优化，逐步实现开发中的质量内建，并持续提升开发效能；可以协同测试团队，进行自动化测试的分级分层设计，形成质量防护网，并增加探索性测试等对版本质量进行兜底的能力。
如上图所示，效能专家或教练团队要深入研发一线，通过一个个方法、实践的导入和落地，引领研发模式的更新升级、研发效能的稳步提升、人员技能的持续进步。要通过教练引导业务研发团队对有问题的研发过程实施干预，从而使团队朝正确的方向演进。
效能专家或教练团队还需要对行业中涌现出的优秀实践保持敏感并持续学习内化。
举个例子
对于代码评审这个具体实践，Google 公开的工程实践文档中就对其进行了详细说明，很有参考价值。比如，对于一个CL（ChangeList，即已经提交给版本控制或正在接受代码评审的一个独立的变更），为了让评审更有效，关注要点为：查看CL内容是否有意义且拥有清晰的描述、评审CL中的最核心部分是否经过了良好的设计、按适当顺序查看CL的其余部分。
效能专家或教练团队要对这些优秀实践非常熟悉，并将其总结提炼、抽象加工后，以易于理解的方式传授给业务研发团队。比如，下图展示了基于业界优秀实践整理出的CL评审要点，从整体到细节分为三个步骤，每个步骤如果不满足条件就直接结束评审，这样的评审效率会更高。
提炼效能提升知识库
效能专家或教练团队应该把成功案例和效能提升经验整理为效能提升知识库，并与工具平台团队、组织级研效管理团队频繁互动，让来自一线的实践经验能够被吸纳为组织资产，让研效提升的决策和工具平台的设计更为务实、更为落地。
四、组织级研效管理团队
组织级研效管理团队的主要工作是确定研效提升的高阶目标，确定每个阶段的整体推进策略，组建研发效能的部门或团队（实体/虚拟），发布相关的标准、规范或制度等。
应该要做的：
从整体上推进研效重大事项
比如制定公司统一的代码规范，推广公司统一的编码风格，减少开发人员间以及团队间的代码风格差异。并以此为出发点，普及代码质量意识，推广代码文化，推进跨业务间的代码评审，以此提升公司开发人员的整体代码质量。在公司内构建易于使用的统一软件源服务，满足研发人员在环境搭建、开发、构建、测试等环节的组件和工具依赖需求，提升组织的整体研发效能。
还有很多研效整体治理的工作，比如编译器版本的统一、组织内同领域不同研效工具底层元数据的对齐、跨领域不同研效工具相互打通串联，组织级研发效能平台的整体设计等等。
总体来说，组织级研效管理团队负责公司研效领域的顶层规划，加强底层研发基础设施协同共建，促进研发工具平台间串联打通，另外还要推进工程师文化的形成。
适当地推进研发效能度量
除了上文中提到的不要把度量武器化、不要直接用于考核，还要注重将度量指标与目标联系起来，确保所选的度量（指标），始终要与其目的（目标）关联。组织级研效管理团队有责任确保组织的时间不会浪费在收集和维护不必要的指标上。
举个例子
在软件研发的场景中，可能会看到如下定义的指标：
方法必须少于 80 行，方法的参数不能超过 4 个，方法圈复杂度不得超过 20。
为了让研发理解设定这个度量指标的目的，应该转化为如下的描述方式：
我们希望代码不那么复杂，并且更容易修改。因此，我们的目标是编写具有较低圈复杂度（小于 20 ）的短方法（少于
80 行），参数也尽量少（最多4个），以便方法尽可能保持专注，也具备更好的可读性。
我们有时也会碰到一种情况，就是纯从数字来看，效能度量指标有了提升，比如交付效率和吞吐量都在提高，但业务部门却仍不满意，他们的反馈是：”好像并没有什么变化!”
那么这个时候，我们应该相信谁呢，是数据还是业务部门的声音？正如杰夫·贝佐斯(Jeff Bezos)的名言所说：“我注意到的是，当传闻和数据不一致时，传闻通常是正确的”。很可能是你度量的方法有问题，或是数据已经失真，这就需要进一步的检视和反思了。
丰田的大野耐一曾经说过：”那些不懂数字的人是糟糕的，而最最糟糕的是那些只盯着数字看的人”。每个数字背后都有一个故事，而这个故事往往包含比数字本身所能传达的更重要的信息。现场观察(Gemba)是一个可以与度量结合使用的强大工具，管理团队要到实际的研发交付过程中去，观察需求和价值的流转过程，看一下团队是如何进行研发交付的。正式的度量和非正式的观察是相辅相成的，可以对结果进行相互印证。
另外，度量还要从简单地对指标进行观测，进一步延伸到对研发活动更深度的洞察上，目前很多头部企业都正在进行这方面的探索。
关于研发效能度量的方法和实践，我之前写过五篇连载文章进行详细说明，可以在这里找到链接：终极指南：如何在中大规模企业成功落地研发效能度量？
不建议做的：
不要过度控制，一刀切地盲目推崇一致性
在一些相对稳定的场景下，一致性可以帮助业务研发团队提高效率。但如果脱离产品所处阶段和业务实际情况一刀切地盲目推崇一致性，为了统一而统一，反而会给业务研发团队带来很多额外的负担，某种程度上也会抑制创新，这样很难带来期望中的价值。
举个例子
在《复杂》一书中介绍了一个有意思的案例。沙丁鱼群是个很复杂的体系，分散的个体几乎没有抵御天敌的能力。但当鲨鱼游进鱼群时，沙丁鱼会迅速自然散开，形成一个可供鲨鱼通过的洞，鲨鱼什么也没吃到就穿过了洞口，当它回头再咬的时候，新的洞口又出现了，鲨鱼只能无功而返。
这种集体智慧从何而来？科学家们做了大量的研究，发现秘密存在于沙丁鱼基因中的三行代码：（1）跟紧前面的鱼；（2）与旁边的鱼保持等距离；（3）让后面的鱼跟上。
沙丁鱼群表现出来的行为是复杂的，虽然并没有一个更高层的"大脑"在做整体控制，但每条鱼只需要遵守这三条原则，鱼群就能得表现得非常完美。
这个案例带给我们一些启示，在研发场景下，复杂度非常之高，基本上无法通过"上帝视角"来规划和定义一切。但是我们可以明确出一些大家都要遵守的基本规则。
所以我们建议不要过度控制，而更多是给个体赋能，在一定程度上尊重和发挥个体的智慧。但是要设定一些大家都遵循的集体规则，这是底线，规则可以不多，比如上面提到的研效治理工作之一就是要把这些规则制定好。管理好知识工作者要给予一线一定的自由度，像给人穿上紧身衣一样把所有事情束缚得太死效果可能反而不好。
— 4 —
不躺平、不内卷，行稳致远
本文主要讲述了如何避免大跃进式、虚假繁荣的效能提升运动，而是通过灵活务实地解决问题，让研发效能提升有效落地。
我分别介绍了参与到研发效能提升中的四类团队，以及他们应该做什么、不建议做什么。
这些内容可以作为研发效能推进过程中的模式和反模式被参考，也许你的具体场景和上下文会有所不同，但这些原则和做法应该都是相通的。
最后想说的是，研发效能是要服务于业务的，而不能让业务反过来迁就研发效能。
研发效能应该解决业务研发过程中真正的痛点，切切实实地帮助到他们，大家双赢才是最好的结局。
|
