研发效能提升的八项实践建议

笔者常会被问及这样的问题：“你之前主导的研发效能提升项目都获得了成功，如果请你到我们公司来，几年可以帮助我们把研发效能做好？”

这其实是一个无解的问题。

从某种程度上说，投入大，周期就会短，但是实施周期不会因为投入无限大而无限变短。我们可以避开很多曾经踩过的坑，尽量少走弯路，但是适合自己的路还是要靠自己走出来的，拔苗助长只会损害长期利益。买了一辆跑车，你就能成为赛车手吗？

鉴于此，笔者总结了八项实践建议，如下图所示，供读者参考。

图  研发效能提升的八项实践建议

01

从痛点入手

研发效能提升八项实践建议的第一项，是“从痛点入手”。

很多时候，当我们手上拿着锤子的时候，看什么都像钉子。但是研发效能的提升恰好是反过来了，我们要先找到哪些是最碍眼的钉子，然后用体系化的方法论去打造合适的锤子。

所以在推行研发效能的早期阶段，我们通常会采用自下而上的策略，从一个个工程实践中的实际痛点（钉子）入手，从解决问题的角度打造研发效能提升的亮点，此时我们追求的是“短、平、快”，遵循的是将问题点逐个击破的原则。

比如下面这些场景：

• 本地编译耗时长：提供增量编译和分布式编译能力。

• 本地测试困难，测试环境准备复杂且耗时长：基于 Kubernetes 的 Pod 提供一键搭建测试环境的能力。

• 自动化测试用例数量大，执行回归时间过长：采用并发测试用例执行机制，使用几百、几千台测试执行机并行执行用例，实现用硬件资源换时间。

• 自动化测试用例维护成本高：测试用例采用模块化和分层体系，实现低成本的自动化用例维护。

• 测试数据准备困难：引入统一的测试数据服务（Test Data Service）能力。

• 研发后期阶段，代码递交集中，缺陷井喷：推行测试左移策略，鼓励研发自测，遵循“谁开发、谁测试、谁上线、谁值班”的原则。

• 性能缺陷在研发后期发现，修复重测成本高居不下：从性能测试转变为性能工程，让性能融入软件研发的各个环节，而不是最后的一锤子买卖。

• 安全问题频现：将安全测试能力纳入研发的全生命周期，实现 DevSecOps，而不是早期的 SDL（Security Development Lifecycle，安全开发生命周期）。

• 集群规模庞大，发布过程耗时过长：各个层级的并发部署能力，集群内节点的并发、集群间的并发等。

• 项目的过程数据都是后期集中填充，失去度量意义：项目的过程数据由工具自动填充，不再依赖工程师手工输入。比如，开发完成的时间不再依赖于开发人员手工填写，而是由 Jenkins 构建完成后自动填写，以保证所有过程数据的真实有效性，从而为后面的度量和改进提供可靠的信息输入。

02

从全局切入

第二项是“从全局切入”。

很多时候我们会尝试去优化某个具体的环节，而忽略了全局优化的可能。

举个例子，我们去医院看病，在挂号时经常会出现排队半小时，而实际挂号可能就花费两分钟的情况，接下来很可能又是漫长的排队等待医生就诊，好不容易进入了诊室，可能问诊不到五分钟就又被要求去验血……整个过程中实际有效时间的占比很小。

如果这个时候我们还试图去优化挂号本身的时间，而不去关注优化各个环节的等待时间，那显然是错误的方向。

因此，效率的提升既要关注单个步骤的优化，也要专注减少步骤与步骤之间的无用等待。这一点体检中心就比公立医院做得好很多，我们很少会见到体检中心每个科室门口都大排长龙的情景，因为体检中心出于经济利益的考虑会关注吞吐量，会通过全局排队调度优化来实现更高的盈利。

回到软件研发领域，你会发现类似上面医院这种不合理的排队现象随处可见，比如软件缺陷的流转，软件需求的实现与交付，软件制品包发布等待，等等。

这些也是提升研发效能需要重点关注的领域，需要从全局理清楚全流程，识别出等待浪费的时间，通过流程再造与优化实现全局效率的提升。

03

用户获益

对于研发效能的提升，有一点我们必须牢记，那就是成功的标准不是研发效能平台的成功，而是客户的成功。只有客户获益才是检验研发效能项目成功的唯一标准，下面我们再总结一些要点。

伪需求：伪需求是指研发效能团队自己臆想出来的需求，是属于典型的“手里拿着锤子，看什么都像钉子”的典型案例。那么如何识别伪需求呢？识别标准其实很简单，就看用户是不是愿意和你分摊成本，如果业务线已经开始做了，或者想要开始做，那就说明那是业务线的刚需，如果研发效能平台能帮助用户提供方案，那么研发效能平台的接入就是水到渠成的事情。笔者见过很多这类刚需的例子，比如微服务架构下集成测试环境的搭建就是其中的典型。

结构问题：著名商业顾问刘润说过“结构不对，什么都不对”。比如，两个和尚分粥的故事想必大家都听过，一碗粥两个和尚要均分，但是分粥的和尚总想多喝点粥，那怎么才能做到无监管情况下的公平呢？教育分粥的和尚说出家人“以少吃为怀”吗？显然一旦没有了监管，他就会给自己多分点，解决这个问题的最好办法就是一个和尚分粥，另一个和尚选粥——这个体制就决定了分粥的均匀性。

因此，好的策略是承认每个人都是自私的，但是我们制定的策略要能够在人人都是自私的基础上获得全局利益的最大化。

如果全局利益最大化是建立在要求每个人都是大公无私的基础上，那就是失败的设计，因为这必然会导致失败。回到研发效能提升这个问题上，我们必须抱着“不是我们的研发效能平台有多好，而是业务线用了以后有什么提升”的态度来定位自己，才能从结构上获得成功的筹码。

服务意识：理解了上面的观点，再来理解服务意识就很容易了。在研发效能平台落地的过程中，我们需要和业务线互助以实现双赢，业务线收获现成可用的方案，研发效能平台收获最佳实践的沉淀，这些最佳实践的沉淀是至关重要的，为后期的批量成功复制提供了技术基础。

04

持续改进

持续改进是研发效能平台自身发展的必经之路。

很多问题在开始时，我们的关注点是如何快、速简单地解决问题，但是当用户量和接入团队日益增长后，我们更需要关注解决方案的普适性和通用性。如果一开始就试图寻找完美的方案，那么必然会得不偿失。

比如，我们需要在 Jenkins 中通过 hook 机制去触发一些操作（比如代码静态扫描、单元测试等），最简单的做法就是在 hook 中实现操作的具体步骤，这种实现在开始的效率很高，也非常容易实现，但却不是最优的方案，因为 hook 中的代码只会被执行一次，而且 hook 越来越多以后，各种实现都散落在各个地方，难以维护，一旦有新的需要（比如要加入慢 SQL 扫描），就需要改 hook 实现，而且这种做法也违背了 IaC（Infrastructure as Code）原则。

更好的做法是引入研发效能的消息中心，通过下游操作的订阅模式来实现未来的可扩展性。

但是，如果我们从一开始就创建消息中心，实现的难度和成本都会大增，业务线有可能就等不及这个方案，从而研发效能的提升就无法如期落地。所以我们认为，研发效能的落地可以采取“先圈地、后改进”的策略。

05

全局优化

研发效能提升的落地，光靠自下往上和光靠自上往下都是行不通的，而是应该双管齐下，“从两边往中间挤”才是切实可行的方案。

研发效能提升的初期，主要是靠“自下往上”的工程实践来实现各种痛点问题的各个击破，比如通过分布式编译来降低编译的时长，通过 AI 技术来自动生成单元测试的用例，通过分析代码递交历史自动推荐最合适的代码评审者等。通过这些专项的效率提升逐渐向管理层证明研发效能提升的实际价值，由此引起管理层对研发效能的重视，进而为管理层从上往下推进研发效能的提升打下基础。

随着研发效能实践逐渐进入深水区，单一领域效能提升的边际效应会逐渐递减，此时基于横向拉通的全局优化变得非常关键，自上往下的推动在此时将会起到关键的作用。很多横向跨部门的流程优化和整合必须借助管理层的力量才能有效地向前推进。

06

效能平台架构的灵活性

这里我们先来讲两个概念：“唱戏的”和“搭台的”。刚开始做研发效能的时候，我们既是搭台的又是唱戏的，在研发效能平台（搭台）的基础上提供各业务线的解决方案（唱戏）。但是，当业务线的接入规模不断扩大的时候，各个垂直领域的多样化需求越来越多，我们已经很难应对各家的个性化非通用需求了（每家要唱的戏都不同）。此时，研发效能平台的开放能力就成为关键，它必须能够应对这种多样性，让业务线能够在平台上实现各自的个性化需求，所以研发效能平台本身的技术架构设计必须考虑可扩展性和灵活性。

比如，我们可以 Jenkins 持续集成工具视为一个平台，在这个平台上支持安装各种插件，以增强平台功能，从而实现平台架构的灵活性。

07

杜绝“掩耳盗铃”

“掩耳盗铃”是我们在落地研发效能过程中经常会犯的错误。下面给出了一些研发效能的“最差实践”，读者可以在心里默默数一数被砸中几条。

• 代码质量门禁 Sonar 设而不卡。

• 单元测试只是执行，不写断言 Assert。

• 代码覆盖率形同虚设。

• Peer Review 走过场。

• 代码递交过于随意。

• 监控超配，有报警但无人认领。

另一种掩耳盗铃的错误实践是普遍采用虚荣性指标来做度量效能。

那么到底什么是虚荣性指标呢？

虚荣性指标是指那些不能直接用来指导后续行动的指标，我们需要的是可以指导我们行动的可执行指标，可以参考以下内容。

• “接入 Sonar 的工程数”就是虚荣性指标，与之对应的可执行指标是“Sonar 问题的增长趋势”和“Sonar 问题的修复时长”。

• “系统用户数”就是虚荣性指标，与之对应的可执行指标是“DAU 单日活跃用户数”和“MAU 月活跃用户数”。

• “接入研发效能平台的项目数”就是虚荣性指标，与之对应的可执行指标是“百分之多少的项目使用过研发效能平台来完成开发测试和发布流程”。

总而言之，我们需要的是雪中送炭，而不是锦上添花。

08

吃自己的“狗粮”

最后一点，吃自己的“狗粮”，意为“做自己研发效能平台的第一个用户”，研发效能平台本身的研发流程必须通过自己的平台来执行，这样才能站在用户的角度看待自己的方案，才能和业务线用户“共情”。

如果我们作为效能工具平台的研发团队，自己都不用自己的工具平台来完成研发过程，就很难要求别人也来使用我们的研发效能平台。

基于这项理念，我们始终践行的做法是，研发效能团队主持开发的产品和解决方案，自己必须是第一个用户，同时我们自己必须认可其带来的价值，只有这样才能站在用户的视角来客观地评价我们的产品和方案，不至于出现“王婆卖瓜自卖自夸”的现象。

* 本文节选自《软件研发效能提升之美》一书，欢迎阅读此书了解更多内容！

11.jpg

▊《软件研发效能提升之美》

吴骏龙 茹炳晟 著

如果你想了解更多软件研发效能的系统知识和趣闻轶事，或正在从事软件研发效能相关工作，希望进一步深造学习，请不要错过这本《软件研发效能提升之美》。

本书由两位行业知名专家联袂编写，汇聚了行业前沿的研发效能提升实践与案例，同时提炼出大量方法论和经验反思，以诙谐幽默而又不失严谨详实的风格，全方位多角度覆盖研发效能领域的核心知识，深入浅出，发人深思。收录作者行业知名大会热门演讲精华内容，集合研发效能提升的前沿技术与理念，40 余名行业专家与企业高管倾情推荐。

做好研发效能提升是不容易的，我们需要的不仅仅是前沿技术的加持，更重要的是理念的更新换代和优秀实践的传承，而这些，正是本书所希望带给读者的核心价值。我们不仅会告诉你“怎么做”，还会告诉你这么做的“缘由和故事”，呈现所有人都能学得会且带得走的研发效能实践。这样，也许若干年后你重读本书，依然能够时读时新，有全新的收获。