摘自CPP与系统软件联盟

1、痛点

第一性原则

顺畅指的是整个的价值交付，从需求变成可交付的软件，并且让用户用到软件的过程必须顺畅。不能做完功能没有发布窗口或者没有办法做测试等等都是不顺畅的表现。
第二个要高质量，如果你跑得快、质量差，换句话说也会死的越快。所以说要跑得快，同时质量要求还是比较高的。
持续交付是指效率能够做的很高，也能够系统化的保证这个效率，而不是通过加班等不可持续的方式。我们要求持续交付要是持续的、系统性的、高效的。
有效价值是针对需求，更多是从产品经理角色去讲，要听用户讲，但不要去照着做。
最后要形成闭环，要能够快速反馈。

在这下面就引出了五个持续：开发过程要能够持续，不能中断；CI集成过程要能持续；测试要能够持续，阶段性交付、接口、模块跟模块之间的集成能做测试。而且能非常轻量级的来做测试，不能变成一锤子买卖；持续交付，东西做完能快速给到生产环境做部署、发布；对于互联网产品还要持续的运维过程。
在这个理念下，我们关注价值的流动速度，关注长期稳定的质量，同时关心客户价值的交付，整个过程必须透明化，以数据驱动的方式来展开 这就是我对研发效能的比较系统的定义。

精准代码提示，现在有很多AI工具会自动读取或学习现有的案例，然后做到更精准。代码预测能够让代码提示功能比原来提升一个数量级。数据表明，Python不用工具输入同样代码，键盘敲击次数要达到300多次。工具优化之后，可以从300多下降到50次左右。支持最差的是C++/C语言，也能从100次降低到降低到50次左右。像分支模型，那么到底是主干发布还是分支发布，根据团队的规模，发布的频率，人员的技术水平，自化的表现程度选择最适合你的。

2、用MVP的思想来提升研发能效

(Minimum Viable Product)
那么研发效能的提升，尤其对大的企业，可以使用MVP的思想。从研发效能角度来讲，不要做一个流程或一个工序对现在没用但为了以后有用。一定要把一个有价值的东西拆成一个小片，哪怕改进点是非常小，但是对你的用户或者研效平台的使用者可以带来实际的价值

3、经验

·从痛点入手（从下往上走）
本地编译时间长就从分布式编译入手；自动化测试用例数量很大执行维护成本很高，可以做微服务；数据准备困难，可以通过测试中台去打造Test Data Service

·从全局切入.
刚才已经讲过的一个BUG的流转生命周期，一定要站在更高的宏观视角去审视效率的提升，单点优化带来的提升是有限的，全流程拉通目前阶段来看更有价值。

·用户获益
第一是伪需求，做研发效能经常会碰到的尴尬情况，比如说要帮用户做测速率的版本，而用户连自动化测试平台都没有建起来。所以这种情况下，那怎么来识别需求，就看看业务团队自己有没有在做。

第二是结构问题有一句话是结构不对，什么都不对。那结构问题讲的是什么呢？要把利害关系理清楚，用体制帮你去推进，制定好规则，其他由系统去保证。做底层逻辑设计时， 要假设任何人都是自私自利的。如果体制设计能在每个人都自私自利的情况下获得全局利益最大化，那这个制度设计就是成功的。

最后是服务意识，做研发效能的人要放低姿态。用户用工具，驱动产品的过程，必须提供全程的保姆式服务甚至要帮助“背锅”。

·持续改进
永远不要想把一件事情一下子就吃透。

·全局优化（自上而下）
研发效能到底从下往上做还是从上往下做？答案是两边要同时做。靠工程师推不动，老板不知道你的工程上有哪些东西可以改进，这些东西的改进点一定是在工程师更了解。

·效率平台的灵活性
主要的一个点在于我们应该尽可能的去搭建一个平台，而不是把所有的东西都自己来做。当规模做大到一定程度抽象成平台，然后让用户按需使用垂直能力来符合业务上的一些特殊的要求。

·杜绝掩耳盗铃
虚荣性指标和可执行指标要重点强调，为什么要做研发效能，需要有指标来度量就有两种指标一种叫虚荣性指标。比如Sonar在企业内部推广之后，怎么来衡量推广成功还是失败？很多企业都用有多少项目或者有多少百分比的项目接入了Sonar，这个就是虚荣性指标。Sonar的可执行指标不是接入百分比或者接入用户数量、项目数量，而应该是Sonar里面的关键问题存在时长，Sonar的P1的issue的增长趋势、变化趋势，能够知道接下来行动的度量指标才是有益的。

·吃自己的狗粮
我在腾讯内部负责研发效能资源平台，资源平台本身是为TEG各个部门产品提供研发效率的提升，提供Devops、测试、监控、运维相关的能力。那我们这个平台自己的开发遵不遵守我们这套体系呢？答案是我们必须用自己的产品来发规范和内容的，因为只有这样我们才能明白用户的疾苦。

4、研发效能行业的趋势

研发流程全链路打通与过程可视化->”敏态”和”稳态”齐头并进->研发能力中台的沉淀->数据驱动下的效能提升->研发能效”从无到有”

研发流程全链路打通与过程可视化，这是必然的。现在的研发效能差在哪里，都是单点提升。比如说测试跟开发有没有打通，运维如何跟开发人员结合，安全测试如何融入到整个研发体系当中去，这些东西都是可以深入讨论提升的。全链路打通同时要过程可视化。所有的数据要有看板，数据一定是要通过工具自动触发状态的变更、流转，让整个过程可视化，让数据可相信。

第二个是敏态和稳态的齐头并进。一些快速迭代变更的产品要用敏态，但是一些后端的、偏底层的、稳态的，瀑布模型依然有它的市场，依然有它的业务场景。

第三个研发能力的中台沉淀，很多东西跨部门跨产品，有很多努力是应该被沉淀下来，尤其像Devops，自动化的测试，静态代码的分析等等，都应该要被沉淀成一个垂直的单点。然后可以在研发效能的上层平台做组合。

第四个是讲研发效能不是拍脑袋，所有的东西都应该有数据来支撑