概念
更高效、更高质量、更可靠、可持续地交付更优的业务价值
- 更高效：价值的流动过程必须高效顺畅，阻力越小越好。
- 更高质量：如果质量不行，流动越快，死的也会越快。
- 更可靠：安全性和合规性要保障好。
- 可持续：输出不能时断时续，小步快跑才是正道，不要憋大招。
- 更优的业务价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。比如：“女生减肥不是本质问题，女生爱美才是”。
我们引出持续开发，持续集成，持续测试，持续交付和持续运维的理念，它们是研发效能落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。
需求及作用
1、很多企业存在大量重复造轮子
就像“中台“概念一样，现在很多大企业的产品线非常广，其中存在大量重复的轮子，如果我们关注业务上的重复轮子，那么就是业务中台；如果我们关注数据建设上的重复轮子，那么就是数据中台；如果我们关注研发效能建设上的重复轮子，那就是研效平台，其实研效平台在某种程度上也可以称之为”研发效能中台“，其目标是实现企业级跨产品跨项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0到1“，没人有精力去关注更有价值的”1到n“。现代化的研效平台会统一来打造组织级别通用研发能力的最佳实践平台。
2、toC产品已经趋向饱和
现在toC已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出
3、部分企业存在谷仓困局
研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。
研发效能方向
考虑到
- 软件架构本身的复杂度提升（微服务，服务网格等）
- 软件规模的不断增长（集群规模，数据规模等）
- 研发团队人员规模不断扩大引发沟通协作难度增长
我们能做的不是提升研发效能的绝对值，而是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，努力保持现状就是成功。
当前存在问题
- 迷信单点局部能力，忽略全局优化和拉通的重要性
- 具有普适性的通用研发效能工具其实没有专属工具来的好用
- 用“伪”工程实践和“面子工程”来滥竽充数
- 忽略研发效能工具体系的长尾效应
- 盲目跟风
- 迷信外部专家
- 研效度量的罪与罚
