研发效能是目前互联网企业和传统软件企业都高度关注的领域：
- 一线互联网企业希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发；
- 腰部厂商则希望通过“研发效能”实现弯道超车，充分发挥后来者居上的优势；
- 中小企业看到国内一线互联网企业不约而同地在这个领域重点投入，纷纷也是摩拳擦掌准备在效能领域发力。
一夜之间，似乎只有推进了研发效能，才能提升研发团队的效率，才能让自己在和友商的比拼中不至于输在起跑线上。
研发效能是啥
和敏捷的概念类似，研发效能很难被精确定义。其实很多复杂概念也不是定义出来的，而是逐步演化出来的，是先有现象再找到合适的表述。纵观人类发展史，效率和效能就是生产力和生产效率提升发展的表述，在数字化时代，研发效能的重要性被凸显了出来。
如果要用一句话来总结研发效能的话，就是“更高效、更高质量、更可靠、可持续地交付更优的业务价值”。
更高效：价值的流动过程必须高效顺畅，阻力越小越好。
更高质量：如果质量不行，流动越快，死得也会越快。
更可靠：安全性和合规性要保障好。
可持续：输出不能时断时续，小步快跑才是正道，不要憋大招。
更优的业务价值：这是从需求层面来说的，交付物是不是真正解决了用户的本质问题。
当在项目经理在实践的时候，不免总会碰到一个问题：“如何衡量研发效能”。项目经理的理工脑袋会不由自主地把逻辑题转成数学题，试图用数字指标去证明一些“不证自明”的方法论。
但衡量研发效能，真的只要摆出一堆数字指标就行？或者说好的量化指标一定会带来好的结果吗？
阿里做法是从交付价值、研发成本、交付时长来定义、衡量，再加亿点点指标细化，从而量化研发效能。假设目标是提高技术团队的效能，会得到如下OKR（Objectives and Key Results，目标与关键成果法）：
定义交付价值
首先要纠正下常见的误区：
误区1：交付的价值就是产出方案、代码的数量和质量
这样衡量交付价值，就很少有人愿意建设公共设施了，因为质量好不好很难量化，建设公共设施初期的耗时往往明显大于直接完成业务需求，也很少有人愿意使用公共设施，因为用别人的不如自己建，还能拿个结果。而对于技术团队，长期创造价值的能力，离不开公共设施的完备和对公共设施的使用。
误区2：交付的价值就是业务KPI中指标的增量
有很多功能并不带来直接的增量，或者比较难以衡量，但可能带来公司的竞争壁垒，如产品的体验。这样衡量交付价值，带来的问题就是，大家都只关注短平快的增量功能（比如营销），最终产品的竞争力下降。
阿里的答案：交付价值是需求背后的客户价值
不完全是技术方案、代码的数量和质量，也不完全是KPI指标的增量。交付价值就是按照用户的需要，对用户提供的整个产品、服务的数量和质量。这个定义几乎是不证自明的。
但是把交付价值定义为客户价值，会不会让这件事情更加复杂，变得更加不可能量化？这就需要项目经理转变一下思路，通过按照优先级加权的需求的工作量来衡量。
按照优先级加权的需求的工作量代表着客户价值，做一些基本假设。
假设1：技术的上游（业务、产品）对客户价值的判断是基本准确的
我们知道业务是会试错的，给业务小成本试错的机会、在业务试错的过程中沉淀一些通用的产品技术能力，往往不是局部最优，但是全局最优。
假设2：技术的上游会按照客户价值推演出优先级然后给技术提需求
假设3：技术的上游提给技术的需求是充分的
充分就说明不存在业务产品人员配置的缺失而导致需求质量数量不足的情况。
基于这几个假设，上游提出的需求可能就很大程度上代表着客户价值，研发在非功能性需求方面对上游的需求做补充。
衡量交付价值
交付价值有个非常主观但有效的衡量方式——上游的满意度。背后的逻辑是：交付价值往往很难量化，而产品业务的满意度不仅体现了技术与业务是否很好的协同，也反映了技术是否很好的交付价值。
不应该通过工时来评估需求的工作量，不同团队对于相同功能点的开发时长是不同的。需求的工作量的单位应该分解到最后的功能点数量。再细化一些，对于服务端是领域模型、领域服务数量，流程分支节点数量，对于前端、交互这类偏展示层更多的是页面区块、交互流程、行动点的数量。
衡量研发成本
在一般的工程效能里面，会将研发成本简单地理解为工时，用单纯的交付工时来衡量比较简单：整个团队的人数 x 工作天数。但站在企业成本的视角，项目经理很容易忽视的是，交付工时可能还要按照开发人员的收入进行加权。从这个角度来看，技术团队效能里面的研发成本，就是公司对于研发的金钱投入，包括购买服务器、云服务、培训、行政投入。
这就要项目经理思考这两个点：
软件开发是一个边际成本递减的行业，如何让功能更简单地得到复用，可能是对效能提升最有帮助的部分之一。例如复用50个工时的功能模块，几乎等于省了50个工时的研发成本。当然也可能存在复用及后期维护的成本大于新建成本的情况，需要有良好的设计去规避。
定义交付时长
不少项目经理都会陷入一个误区：认为交付时长就是从开始开发到完成上线，这个时间跨度就是交付时长。但是回到客户价值这个维度来思考，技术团队交付时长应该是从业务的一个想法到验证、立项、完成发布、灰度，到最终用户可以真正使用的时长。
于是单位价值的平均交付时长，就变成了以下公式：
衡量交付时长
衡量交付时长其实也比较简单，记录下业务提出该功能的时间以及功能开发的时间。难点可能是整个价值流交付过程中要细化的指标，毕竟细化的指标更能帮助项目经理发现问题。
可以从一般项目的生命周期来看，哪些节点的时长会影响项目的交付：
衡量交付时长也可以为项目经理带来以下思考：
1、需求的拆分成基本的功能闭环进行迭代（以不引入或少引入测试的重复回归为标准），或许能比较有效的降低需求价值量的平均交付时长。
2、自测充分、减少bug数量，最终减少联调、测试回归的次数和时长，在一定的单测覆盖率要求以前，是收益大于成本的。
3、代码合并有时候冲突解决很麻烦，会导致一次部署的时间很长，且代码合并引入了更多次的测试回归工作（这可能是某些BU往主干开发分支发布走的原因之一）。所以基于业务的理解，进行应用的拆分，减少单个应用的并发数量，也可以提升研发效能。
4、在缺乏有效的项目管理的情况下，资源的相互等待可能是项目延期的一大因素，有时候某端开发完了，另一端资源没到位，一直不能联调提测。项目管理的同学对于资源目前的分工和瓶颈应该给上游及时的反馈。
写在最后
阿里认为，好的量化的指标往往是好的结果的必要不充分条件。
但简单粗暴地优化某项指标往往会因为两个问题而使最终结果背道而驰：
- 某项指标变好，带来的是其他指标的降低，这属于局部最优，并非是全局最优。如，取消技术方案的编写和评审，造成的是编码时间或者后期维护时间的增加。
- 效能是多个变量共同作用的结果，缺乏理论基础和方法论的情况下，很可能在短期优化指标的时候，忽略了长期的团队成长、系统能力沉淀等因素；或是忽视了业务方满意度等难以量化的因素。
阿里研效工具体系固然有其先进性，但是否能够适配你的研发规模和流程是有待商榷的。很多时候研效工具应该被视为起点，而不是终点，就像你买了一辆跑车，你依旧不能成为赛车手。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。