关于研发效能推进提升的一点感受

1. 点 -> 线 -> 面

先找问题点，一个点一个点解决。

先找问题点，一个点一个点解决。做事的方法需要按照问题进行驱动，尤其像 Devops 其实没有什么统一'银弹'，不同公司属性/业务特征/项目类型/所处阶段/人员能力等等，都不尽相同，在当下能最高效解决问题的模式/体系，那就是好的体系。我们不断学习了解业界其他的模式流程，其实是为了能够知道更多不同问题点出现时解决方案是什么，提炼改造融入到自己所负责的业务当中，而不是有一个'完美通用'的模式，直接拿来用套用。所以应该以问题来进行驱动行动，把每个解决问题的点做好，才能有线；把多条线跑通，才能形成面；把多个面覆盖全，才有构建体系。

2. 提供实质需求，而不是'伪需求'

雪中送炭 or 锦上添花

雪中送炭 or 锦上添花在推进过程中，会有两种角色，研发效能方和业务方，可以理解为研发效能方提供了体系、流程、CI/CD 能力，将这些东西进行落地。但这里可能会存在一个问题，就是在推进时会有'通过以往的经验，我觉得你需要 XXX'，然后按照这种思路进行推进。这时业务方对于这部分的需求的态度，可能就是，I don't care，要搞就搞吧。这样无论是推进效率还是落地效果，其实都会大打折扣。

3. 需求来源的不同发展阶段

先取，从业务中来；再推，到业务中去

先取，从业务中来；再推，到业务中去一开始推进落地时，研发效能方其实应该更多的是倾听者，从业务中多多倾听他们目前的痛点，要解决的问题，将这些问题作为推进落地的抓手，列入高优先级。按照问题优先级将一个点一个点进行落地，每个点都保证能产生效果数据，而这样慢慢的业务方会主动来索要，希望可以接入到更多的能力。

4. 趋势 > 数值

拉长时间周期，才能看的更清楚

拉长时间周期，才能看的更清楚在推进研发流程建设 CI 能力一个月后，线上问题从 8 月份 20 个降为 9 月份 15 个。这样的数据真的有效吗？需求数有没有变化？需求大小是否不同？测试人力变了吗？线上问题种类是啥？CI 发现了哪些问题？线上问题减少如何归因到 CI 的接入？

5. 某阶段只有 1 个北极星指标

兵力有限，敌人太多，单点突破

兵力有限，敌人太多，单点突破在推进初期，你会发现有太多的优化点、提升点，这时一定要控制住自己的想一口气全部消灭的欲望。就像游戏一样，里面有一堆的 boss，不能上来就跟一堆 boss 去打，而是要通过判断找到最合适的那个先突破。研发效能提升也是如此，在人力精力有限情况下，全路推进，其实会造成一个啥啥都推、啥啥效果都不太明显的尴尬处境，莫不如先将最痛问题解决，逐个攻破，这样推进更快效果也更显著。

6. Devops 和度量指标没有前后顺序

在基建完善前先把已有数据用起来

在基建完善前先把已有数据用起来有时会觉得想把 Devops 整体建立起来、平台间数据打通，这些做完之后开始指标度量。其实这两者并不是串行关系，在建立 Devops 的同时就应该开始进行指标度量，平台数据没打通，那就先从每个平台分别取数/分析，而不是要把所有的基建全部完善后，才分析数据。数据越早分析，越能提供更多的信息，帮助你进行下一个环节的决策。

研发效能提升之路没有终点，我们始终在路上。