概述

越来越多的公司开始重视研发效能，甚至单独成立一个部门来支撑和改进公司整体的研发效能，但却不知道如何下手，或者研发效能在落地的时候效果差强人意，有的公司甚至起到了负效果。你的公司是否存在以下这些现象呢：

• 公司气氛差，产品跟研发打，研发跟测试打，测试跟运维打，最后再混战，变成甩锅之战。

• 每次上线都延期，上线后 bug 不断

• 每次上线过程都很漫长，不断的重新发布，不断的重新测试，不断的回滚……不断到了清晨的 4 点

• 研发辛苦加班好几天赶出来的项目，上线后效果极差，1 个月后处于不维护状态

• 产品经理总是在提测后，再来改需求，然后导致项目延期及各种问题

• 产品 bug 永远是用户发现，发现后又定位不到，定位到又解决不了，解决的了又费了老长时间，最后用户已经抛弃了自家产品选择了竞品

• 公司最近再推研发效能，但我感觉自己做的事更多了，效能没看到，其他事倒是变多了不少。

本文将从研发效能的“道”-原理与“术”-实践分别进行阐述，希望可以帮助读者在自己公司中完成最佳实践。（道不常变，而术常变）

道与法

道具普适性，用来指明方向，法主要指规章制度，用来巩固道的落地；但是也需要结合自身和周围环境的不同而适当做出调整

1 什么是研发效能

1.1 研发效能的来源

搜寻了很多资料，并没有一个准确的定义，这里我们借鉴 不知名网友腾讯新闻 及 知乎网友 goxplanet 的回答 研发效能的历史和未来

权威的出处，或许是 DORA 调查报告和《加速》这本书。首先书名《加速:精益软件和 DevOps 背后的科学--构建和规模化高效能技术型组织》中就有效能。

研发效能被作为明确的研究领域被提出来之前，行业内已经有了一些自觉的实践，从各种开发工具到各类的敏捷活动，实践虽多，尚未形成一个明确的概念。典型的实践集合包括用例管理，故事卡，结对编程，代码走差，自动化测试，持续集成和持续交付。对应的工具包括敏捷看板，持续集成流水线，配置管理数据库，自动化配置工具，自动化冒烟测试工具，性能测试工具以及后续出现的兼容性和混沌测试工具。系统化地构建研发效能的框架，我们可以追溯到 SRE。《SRE:Google 运维解密》迄今仍然是可靠性工程的经典指南，系统地对可靠性工程过程进行了说明，明确提出了工程化的概念。

1.2 定义

由于业内没有统一的定义，说下我个人的理解：

• 效率 = 完成的成果/所用的时间

• 效能 = 有效的成果/所用的时间

• 高效能团队 = 有效的成果/所用的时间 * 高效能状态的持续

效能跟效率的区别是效率讲的是做事的速度，而效能更关注所做的事有多少是有效用的。

而我们强调的高效能团队不仅仅是指在一件事，一段时间，更应该是长期保持这么一种状态的团队。

2 为什么需要提升研发效能

2.1 宏观

从国家和企业的角度看，国内互联网大环境已经从野蛮无序生长期，变成了精细化运营期，整个互联网环境竞争少了很多，像以前为了快速发布而无休止加班，压榨员工的做法已经越来越行不通，国家层面也开始逐渐关注互联网公司加班的乱象，在这样的大趋势的发展下，工作时间少了，如果要保证产出必须提升整体团队的研发效能才可以，同时提效是降本的最直接手段，可以帮企业节约成本。

2.2 微观

从团队和员工的角度看，无休止的加班、开会、扯皮都是研发效能低的表现，团队文化只会逐渐恶化，产出速度也会越来越低，质量更别提能有多高了，团队成员没有充足的生活时间来丰富提升自己，只会导致恶性循环。

2.3 题外话（推行研发效能的阻力）

某些中层领导，或者技术一把手不愿意进行效能提升，主要有两个角度

1. 公司文化鼓励加班，觉得技术就应该加班拼命干，殊不知大家都是摸鱼的而已。

2. 国内招聘乱象，团队规模决定了管理能力。。。这个招聘要求基本上是所有公司的招聘要求，我作为管理者自然愿意多招点人，但是不忙不加班的话我怎么跟业务要人呢？

3. 人的惰性，人都是不愿意改变的，没有足够的利益的话，很难去实施。

3 如何度量研发效能

3.1 明确指标

这里主要参考 葛俊老师的 《高效研发：硅谷研发效能方法与实践》 还有工信部推出的 《云上软件开发效能度量分级模型》 （原件未找到，欢迎大家补充）还有结合自己在本公司的时间整理得出部分指标，红色部分是个人认为比较重要的，当然各家公司一定要结合自身情况去做取舍。

3.2 统计指标

统计指标是个很难推进的事，这个要结合术来进行，总之就一个原则

能自动的就别手动，永远不要相信人类。自动化的程度决定了你做效能提升的关键，只靠项目经理很可能导致动作变形和效能不提反降。

3.3 分析指标

软件研发的效能度量是一件并不像想象中那么容易的事情，搞不好就是团队文化粉碎机，很多业界大牛也都发变过“研发效率不可度量”的观点。马丁·福勒在“Cannot Measure Productivity”（无法衡量生产效率）一文中指出：“这是我认为我们必须承认无知的地方。”；周思博（Joel Spolsky）在一篇名为“Hitting the High Notes”（飙高音）的文章中写道，衡量程序员的工作效率相当困难，原因如下：

1. 几乎任何你能想到的指标（比如调测过的代码行数、功能点个数、命令行参数个数）都很容易被“做数字”；

2. 我们极少要求两个程序员做完全相同的事情，所以很难获取大型项目的有价值度量数据作为参考。

所以在分析研发效能时大的指导原则是：（具体指标也要根据情况来具体分析）

1. 要跟自己比，不要跟别人比 ：每个公司，每个团队做的事情不一样，很多指标不具备横向对比的条件，或者说收益很小，例如拿 AI 团队跟用户产品团队比周期内需求完成数，很明显 AI 团队不具备优势，如果硬要比只会导致 AI 团队为了得到高绩效，编造各种需求，其实也就改改参数，其实是降低了研发效能

2. 相对值比绝对值更有价值 ： 指标的绝对值其实并没有太大的意义，但是整体趋势走向能很好的表明整个团队的效能是否在提升还是下降

3. 不要被局部指标迷惑，优先关注整体 : 由于关注在局部部分指标的优化，可能导致全局恶化，例如一家公司只关注 QA 质量相关指标，却忽视了是由于产品临时经常变更需求导致的质量低下，没有从根本解决问题，很可能导致的就是研发团队畏手畏脚，经常跟产品测试打架，从而导致积极性下降，离职率上升，全局效果变差。

4 如何落地实施

这一部分也需要结合术配合来进行，这里主要讲下原则

4.1 选择自己合适的方案

这里需要谨记，没有一套通用的模板，敏捷和 devops 也不是万能的，一定要根据自身情况结合行业特征去选用合适的提升方案，举个例子：军工行业你敢搞 devops 吗？一个不小心导弹引爆交互变更，带来的影响可不是效能高低能解决的了。

4.2 思想改变行于前

千万不要一上来直接就大搞特搞，做事前先要让大家意识到，现在必须要做这一步了，意识到研发效能是当下一个很严重的问题，同时告诉大家我们做的目的是什么，对大家有哪些影响；如果没有问题那么可以不搞，或者小范围搞。

4.3 通用落地流程

根据自己经验整理，不一定适用于所有公司，请结合自身公司情况适当做出调整，也可以参考工信部发布的开发效能度量分级模型来进行改造：

1. 梳理当前痛点问题 - 吐槽大会，调研问卷，一线采访等形式重要的一线员工的真实的数据和反馈

2. 对痛点进行排序和分析，查找问题根本原因是什么：人、流程、工具、团队配合、公司文化等

3. 将问题公示所有团队等待二次反馈

4. 结合反馈制定新版研发流程

5. 根据流程来完成工具和平台的实现（一定要注意灵活性，允许团队内部在遵循大流程的前提下，进行自主配置）

6. 找愿意尝试的团队进行试点

7. 1-3 个月将结果公示，对有明显提升的团队给予鼓励

8. NPS 调研，获取最新用户净推荐值

9. 根据实践，不断对流程进行优化

工信部：

5 注意事项

1. 尽可能不要把效能指标放在团队 KPI 中！ 在经济学领域有个十分有趣的“古德哈特定律”，即“当决策者试图以一个事物的客观测度指标作为指针来施行政策时，这一指标就再也不能有效测度事物了”。

2. 尽可能不要横向对比两个团队的效能指标！

3. 变化趋势的价值高于指标绝对值

4. 选择适当的而非“标准的”指标，若发现指标没用，果断舍弃。

5. 务必了解指标的获取成本，明确指标意图和针对的企业目标

6. 设计“北极星指标”，指标数量越多，边际收益递减。

7. 不要将指标对所有人透明

8. 让一线人员参与指标制定

9. 始终保持指标的准确性

10. 能自动化的就别手动

11. 能全栈就全栈

Reference

• 高效研发：硅谷研发效能方法与实践 - 葛俊

• 可信云-软件研发效能度量评估

• 阿里云研发效能分享

• hzqiuxm 等网友总结

附录

花了几天时间把关于研发效能道相关的知识点整理了出来，希望对大家有帮助，感兴趣的朋友可以加我微信，后续会拉群促进大家一起交流。

第二章术的部分最近还在整理总结，整理好后会及时发出。