1.6.1从痛点入手
研发效能提升八项实践建议的第一项，是“从痛点入手”。很多时候，当我们手上拿着锤子的时候，看什么都像钉子。但是研发效能的提升恰好是反过来了，我们要先找到哪些是最碍眼的钉子，然后用体系化的方法论去打造合适的锤子。
所以在推行研发效能的早期阶段，我们通常会采用自下而上的策略，从一个个工程实践中的实际痛点（钉子）入手，从解决问题的角度打造研发效能提升的亮点，此时我们追求的是“短、平、快”，遵循的是将问题点逐个击破的原则。比如下面这些场景：
?本地编译耗时长：提供增量编译和分布式编译能力。
?本地测试困难，测试环境准备复杂且耗时长：基于Kubernetes的Pod提供一键搭建测试环境的能力。
?自动化测试用例数量大，执行回归时间过长：采用并发测试用例执行机制，使用几百、几千台测试执行机并行执行用例，实现用硬件资源换时间。
?自动化测试用例维护成本高：测试用例采用模块化和分层体系，实现低成本的自动化用例维护。
?测试数据准备困难：引入统一的测试数据服务（TestDataService）能力。
?研发后期阶段，代码递交集中，缺陷井喷：推行测试左移策略，鼓励研发自测，遵循“谁开发、谁测试、谁上线、谁值班”的原则。
?性能缺陷在研发后期发现，修复重测成本高居不下：从性能测试转变为性能工程，让性能融入软件研发的各个环节，而不是最后的一锤子买卖。
?安全问题频现：将安全测试能力纳入研发的全生命周期，实现DevSecOps，而不是早期的SDL（SecurityDevelopmentLifecycle，安全开发生命周期）。
?集群规模庞大，发布过程耗时过长：各个层级的并发部署能力，集群内节点的并发、集群间的并发等。
?项目的过程数据都是后期集中填充，失去度量意义：项目的过程数据由工具自动填充，不再依赖工程师手工输入。比如，开发完成的时间不再依赖于开发人员手工填写，而是由Jenkins构建完成后自动填写，以保证所有过程数据的真实有效性，从而为后面的度量和改进提供可靠的信息输入。
1.6.2从全局切入
第二项是“从全局切入”。很多时候我们会尝试去优化某个具体的环节，而忽略了全局优化的可能。
举个例子，我们去医院看病，在挂号时经常会出现排队半小时，而实际挂号可能就花费两分钟的情况，接下来很可能又是漫长的排队等待医生就诊，好不容易进入了诊室，可能问诊不到五分钟就又被要求去验血……整个过程中实际有效时间的占比很小。如果这个时候我们还试图去优化挂号本身的时间，而不去关注优化各个环节的等待时间，那显然是错误的方向。因此，效率的提升既要关注单个步骤的优化，也要专注减少步骤与步骤之间的无用等待。这一点体检中心就比公立医院做得好很多，我们很少会见到体检中心每个科室门口都大排长龙的情景，因为体检中心出于经济利益的考虑会关注吞吐量，会通过全局排队调度优化来实现更高的盈利。
回到软件研发领域，你会发现类似上面医院这种不合理的排队现象随处可见，比如软件缺陷的流转，软件需求的实现与交付，软件制品包发布等待，等等。这些也是提升研发效能需要重点关注的领域，需要从全局理清楚全流程，识别出等待浪费的时间，通过流程再造与优化实现全局效率的提升。
1.6.3用户获益
对于研发效能的提升，有一点我们必须牢记，那就是成功的标准不是研发效能平台的成功，而是客户的成功。只有客户获益才是检验研发效能项目成功的唯一标准，下面我们再总结一些要点。
伪需求：伪需求是指研发效能团队自己臆想出来的需求，是属于典型的“手里拿着锤子，看什么都像钉子”的典型案例。那么如何识别伪需求呢？识别标准其实很简单，就看用户是不是愿意和你分摊成本，如果业务线已经开始做了，或者想要开始做，那就说明那是业务线的刚需，如果研发效能平台能帮助用户提供方案，那么研发效能平台的接入就是水到渠成的事情。笔者见过很多这类刚需的例子，比如微服务架构下集成测试环境的搭建就是其中的典型。
结构问题：著名商业顾问刘润说过“结构不对，什么都不对”。比如，两个和尚分粥的故事想必大家都听过，一碗粥两个和尚要均分，但是分粥的和尚总想多喝点粥，那怎么才能做到无监管情况下的公平呢？教育分粥的和尚说出家人“以少吃为怀”吗？显然一旦没有了监管，他就会给自己多分点，解决这个问题的最好办法就是一个和尚分粥，另一个和尚选粥——这个体制就决定了分粥的均匀性。
因此，好的策略是承认每个人都是自私的，但是我们制定的策略要能够在人人都是自私的基础上获得全局利益的最大化。如果全局利益最大化是建立在要求每个人都是大公无私的基础上，那就是失败的设计，因为这必然会导致失败。回到研发效能提升这个问题上，我们必须抱着“不是我们的研发效能平台有多好，而是业务线用了以后有什么提升”的态度来定位自己，才能从结构上获得成功的筹码。
服务意识：理解了上面的观点，再来理解服务意识就很容易了。在研发效能平台落地的过程中，我们需要和业务线互助以实现双赢，业务线收获现成可用的方案，研发效能平台收获最佳实践的沉淀，这些最佳实践的沉淀是至关重要的，为后期的批量成功复制提供了技术基础。
1.6.4持续改进
持续改进是研发效能平台自身发展的必经之路。很多问题在开始时，我们的关注点是如何快、速简单地解决问题，但是当用户量和接入团队日益增长后，我们更需要关注解决方案的普适性和通用性。如果一开始就试图寻找完美的方案，那么必然会得不偿失。
比如，我们需要在Jenkins中通过hook机制去触发一些操作（比如代码静态扫描、单元测试等），最简单的做法就是在hook中实现操作的具体步骤，这种实现在开始的效率很高，也非常容易实现，但却不是最优的方案，因为hook中的代码只会被执行一次，而且hook越来越多以后，各种实现都散落在各个地方，难以维护，一旦有新的需要（比如要加入慢SQL扫描），就需要改hook实现，而且这种做法也违背了IaC（InfrastructureasCode）原则。
更好的做法是引入研发效能的消息中心，通过下游操作的订阅模式来实现未来的可扩展性。但是，如果我们从一开始就创建消息中心，实现的难度和成本都会大增，业务线有可能就等不及这个方案，从而研发效能的提升就无法如期落地。所以我们认为，研发效能的落地可以采取“先圈地、后改进”的策略。
1.6.5全局优化
研发效能提升的落地，光靠自下往上和光靠自上往下都是行不通的，而是应该双管齐下，“从两边往中间挤”才是切实可行的方案。
研发效能提升的初期，主要是靠“自下往上”的工程实践来实现各种痛点问题的各个击破，比如通过分布式编译来降低编译的时长，通过AI技术来自动生成单元测试的用例，通过分析代码递交历史自动推荐最合适的代码评审者等。通过这些专项的效率提升逐渐向管理层证明研发效能提升的实际价值，由此引起管理层对研发效能的重视，进而为管理层从上往下推进研发效能的提升打下基础。
随着研发效能实践逐渐进入深水区，单一领域效能提升的边际效应会逐渐递减，此时基于横向拉通的全局优化变得非常关键，自上往下的推动在此时将会起到关键的作用。很多横向跨部门的流程优化和整合必须借助管理层的力量才能有效地向前推进。
1.6.6效能平台架构的灵活性
这里我们先来讲两个概念：“唱戏的”和“搭台的”。刚开始做研发效能的时候，我们既是搭台的又是唱戏的，在研发效能平台（搭台）的基础上提供各业务线的解决方案（唱戏）。但是，当业务线的接入规模不断扩大的时候，各个垂直领域的多样化需求越来越多，我们已经很难应对各家的个性化非通用需求了（每家要唱的戏都不同）。此时，研发效能平台的开放能力就成为关键，它必须能够应对这种多样性，让业务线能够在平台上实现各自的个性化需求，所以研发效能平台本身的技术架构设计必须考虑可扩展性和灵活性。
比如，我们可以Jenkins持续集成工具视为一个平台，在这个平台上支持安装各种插件，以增强平台功能，从而实现平台架构的灵活性。
1.6.7杜绝“掩耳盗铃”
“掩耳盗铃”是我们在落地研发效能过程中经常会犯的错误。下面给出了一些研发效能的“最差实践”，读者可以在心里默默数一数被砸中几条。
?代码质量门禁Sonar设而不卡。
?单元测试只是执行，不写断言Assert。
?代码覆盖率形同虚设。
?PeerReview走过场。
?代码递交过于随意。
?监控超配，有报警但无人认领。
另一种掩耳盗铃的错误实践是普遍采用虚荣性指标来做度量效能，那么到底什么是虚荣性指标呢？虚荣性指标是指那些不能直接用来指导后续行动的指标，我们需要的是可以指导我们行动的可执行指标，可以参考以下内容。
?“接入Sonar的工程数”就是虚荣性指标，与之对应的可执行指标是“Sonar问题的增长趋势”和“Sonar问题的修复时长”。
?“系统用户数”就是虚荣性指标，与之对应的可执行指标是“DAU单日活跃用户数”和“MAU月活跃用户数”。
?“接入研发效能平台的项目数”就是虚荣性指标，与之对应的可执行指标是“百分之多少的项目使用过研发效能平台来完成开发测试和发布流程”。
总而言之，我们需要的是雪中送炭，而不是锦上添花。
1.6.8吃自己的“狗粮”
最后一点，吃自己的“狗粮”，意为“做自己研发效能平台的第一个用户”，研发效能平台本身的研发流程必须通过自己的平台来执行，这样才能站在用户的角度看待自己的方案，才能和业务线用户“共情”。
如果我们作为效能工具平台的研发团队，自己都不用自己的工具平台来完成研发过程，就很难要求别人也来使用我们的研发效能平台。基于这项理念，我们始终践行的做法是，研发效能团队主持开发的产品和解决方案，自己必须是第一个用户，同时我们自己必须认可其带来的价值，只有这样才能站在用户的视角来客观地评价我们的产品和方案，不至于出现“王婆卖瓜自卖自夸”的现象。
