「技术人生」第10篇：如何做研发效能提升（即指标体系建设过程回顾）

背景

纵观软件研发的发展历程，如果说“业务需求开发”是核心主线的话，那么研发效能建设就是这一核心主线之外最大的一条支线。每个历史阶段的研发效能所面对的主要矛盾次要矛盾都不一样，因此大家可以看到，在不同的历史阶段产生了不同的“研发效能提升产品”：从文本编辑器到带有各种功能的 IDE（Integrated Develop Environment），从单一的命令行脚本到覆盖代码发布全生命周期的 CI/CD 系统，从各种“上古时代”的协作表格或文档到目前已经发展出的横跨软件研发生命周期、覆盖软件开发关键维度的在线协作系统，似乎你能想到的降本提效的方法和途径，都有人帮你做了专业的产品用来满足你的各种要求和与众不同的偏好。

可是实际上从真实的体验来看，“研发效能”的大山仿佛从未被撼动过，让决策者和执行者经历着种种怪现象：

一方面，尽管从一线 leader 到一线研发同学都被各种工具全副武装到牙齿，日会连着周会，周会连着复盘会，但是研发效能建设取得的结果似乎很难让决策者满意：看不到投入的人力物力在短期内给业务发展带来的积极影响，只能在“坚信大方向正确”的基础上怀疑研发效能建设的执行过程有问题。

另外一方面反观研发效能建设过程的一线亲历者们，除了业务需求的 deadline 之外，所有人还要遵守领导划下的 guideline，去关心月度编码量的 redline，以及年度需求交付数量的 bottomline。最终所有人的实际体感就是：会没少开、代码没少写、事情反而变多了，最终整体效率变低了：白天开会晚上编码，写出来的 BUG 可以绕地球 365 天（实际可以绕几圈不知道，但是几乎天天要解 BUG 是肯定的）。

从决策者的维度来看，看不到研发效能建设一段时间后的积极影响，一般原因有两方面，一方面是实际上已经产生了积极影响却不感知、更有甚者无法感知。这种情况的根源就在于决心要做研发效能建设的人，没有明确的短期目标，也没有明确的中长期目标，所以事情做了，但不知道做到了什么程度，更不知道怎么衡量做到了什么程度。另外一方面是做了很多事情花费了很多人力同时也激起了很多矛盾冲突，但是确实没有对业务发展产生积极影响。决策者的信心也在随之动摇，犹豫之中还得继续坚持那些自己都在怀疑是不是样子工程的各种措施。这些“为了效能而最终却不怎么效能”的情况，则在于决策者没有搞明白研发效能要解决的问题究竟是什么、怎么执行才能得到所有人的行之有效的支持，只是“别人做了我也要做，别管我做的怎么样，就看我做的跟XX团队像不像”。

从执行者的维度来看，大家感觉事情变多了效率变低了，主要是因为真正“吃效率”的怪兽似乎一直是藏在屋子里的大象（比喻显而易见的事物却被人视而不见），所有人都视而不见，不但决策者假装它不存在，上下游协作者也假装它不存在，甚至连我们一线研发团队自己也感觉不到它的存在，这也是为什么产品经理常常问你：“我这个月不就是提了这么几个需求么，你怎么会又双叒叕（you、shuang、ruo、zhuo）延期呢”，而你只能回之以满脸的迷茫和后知后觉的愤怒，因为你既不知道自己的时间去哪了，也不愿意在自己已经努力得要死的情况下还得背一个不能按时交付需求的黑锅。没错，你在日常工作中用各种工具、各种快捷键、各种飞花摘叶信手拈来的代码片段节省出来的 10 分钟，抵不过一场 15 分钟都没把问题聚焦起来的对焦大会；你用 git + docker + CI/CD 系统+蓝绿发布偶尔还来下金丝雀发布一整套云原生豪华大礼包跑完全部流程节省下来的 60 分钟，也抵不过产品经理路过你工位时轻飘飘的给你来一句“需求要改了，晚上加个班”；当然，你用 teambition + 甘特图 + 项目任务燃尽图费劲脑汁地做多项目并行排班并发推进多条任务线最后节省出来的 10 天，也抵不过 leader 拉你进入紧急处置群，里面看到的第一句话就是“老板改想法了”。

从决策者到执行者，但凡是在研发效能建设的过程中鸡飞狗跳的，无一不是因为认不清研发效能的本质所以只能邯郸学步随大流，重视它却又不是那么真正地关心，不愿真正投入精力所以只会机械应付考核指标从而自欺欺人。在失败的研发效能建设实践过程中，从业务方到产研团队，从决策者到执行者，所有人都是受害者。

为了早日摆脱研发效能建设方面的一些误区，走出盲区，能与大家一起变成研发效能建设的受益者，本文会从以下几个方面展开：

1. 先按常规讲清楚研发效能的本质。

2. 结合作者目前正在进行的研发效能建设来抛砖引玉，给面临同类问题的读者提供一个参考；

3. 最后结合上一篇《技术一号位的方法论【业务篇】——如何设定业务目标》中讲的一些方法，给出作者在研发效能方面的定制的目标体系，向读者提供“如何定制业务目标体系”的参考样例。

本文内容一如既往非常长，文章最开始提供目录，方便大家挑选感兴趣的内容阅读：

一、背景

二、“效能”的定义

2.1 什么是效能

2.2 什么是研发效能

2.3 研发过程的分层模型

2.4 研发效能建设是过程管理、结果衡量、效果评估体系的综合体

2.5 研发效能在业务效能建设中的位置

2.6 研发效能建设与业务生命周期的辩证关系

2.7 研发效能建设与研发团队类型的辩证关系

三、全面构建综合性研发效能提升体系

四、实践案例介绍

4.1 背景情况介绍

4.1.1 业务方面

4.1.2 技术方面

4.1.3 团队方面

4.2 效能建设原则确定

4.3 效能建设实践过程

4.3.1 研发日常工作版块梳理

4.3.2 研发日常工作流程梳理

4.3.3 研发日常工作任务数字化

4.3.4 研发效能目标体系建设

4.3.5 研发产出效果度量体系建设

4.4 实践案例总结

五 研发效能到底应该怎么做

5.1 从最抽象的层面看工作的本质

5.2. 分析你的工作信息流和决策流是什么样的，构建出整个团队的工作版块大图

5.3. 根据工作版块大图和各种“流”，寻找让信息流转出现问题的点。

5.4. 结合指标体系，针对性的做改

“效能”的定义

研发效能建设是目前研发技术体系内非常重要的一个分支，已经逐步变成各大公司重要的研发基础支撑领域，都在投入大量人力在这方面进行着不断地投入，期望改善整个研发群体的效能现状。对于非研发效能建设领域的一线业务开发者而言，“研发效能”是一个天天听天天做，但是没有过多深入研究的领域，我们期望抛开各种眼花缭乱的产品概念包装，从最原始的定义来让读者深入了解研究什么是效能，什么是“研发”，什么是研发效能，研发效能和业务、和团队有什么样的关系，从而让大家对研发效能建设构建起全维度的认知。

什么是效能

1. 效能，是指使用行为目的和手段方面的正确性与效果方面的有利性。
https://wiki.mbalib.com/wiki/效能
2. 效能是指有效的、集体的效应，即人们在有目的、有组织的活动中所表现出来的效率和效果，它反映了所开展活动目标选择的正确性及其实现的程度。效能是衡量工作成果的尺度，效率、效果、效益是衡量效能的依据。
https://www.zdic.net/hans/效能

从以上对效能的定义和解释来看，我们可以得知，效能是指做一件事情是否达成了目标，达成目标的过程是否高效，达成目标后所带来的实际效果，以及最终效果所带来的效益如何的整体评判，它是对做事过程全生命周期的各个关键环节的评估的总体衡量。

什么是研发效能

结合上面“效能的定义”，我们很容易得出：研发效能，就是采用信息技术作为主要交付手段，将客户业务需求转换为信息化系统这一事情在过程的效率、目标的达成、结果的效果、效果的效益几方面的综合评判。其中，过程管理、结果评估、效果评估是研发效能建设的几个关键维度，如下图所示：

​

图1 研发效能的关键维度

在效能的定义和几个关键维度的拆解基础之上，我们再来看下业内几个经典的研发效能定义是什么样的：

“研发效能”就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。
张乐 腾讯 DevOps 与研发效能资深技术专家

本文作者对该定义的解读如下：

• 更高效：形容的是研发过程
• 更高质量：是形容研发过程产出的结果
• 更可靠：是形容研发体系及其产出，包括团队、技术体系、产出共同构成的实际属性和对客体感
• 可持续：是形容研发过程产物的交付生命周期和方式
• 更优的业务价值：是形容研发结果对业务的积极影响以及所带来的收益。

持续顺畅地高质量交付有效价值
张刚 阿里巴巴-云研发 《ALPD 技术实践 云原生时代的架构方法》

本文作者对该定义的解读如下：

• 持续：研发过程产出物的交付方式和研发过程的生命周期
• 顺畅：形容研发过程的协作效率
• 高质量：形容研发过程产出的结果
• 有效价值：形容产出结果对业务的积极影响以及所带来的收益

由上面的分析可以看到，研发效能领域的顶级专家们对研发效能的定义或描述，都涵盖到了“过程管理”、“结果评估”、“效果评估”这几个关键维度，并且在关键维度上有类似的期望和衡量指标。

研发过程的分层模型

上个小节讲解了研发效能的定义，但是光有定义却不能在“如何进行研发效能建设”方面做出有效的指引，因此我们接下来就对 “研发效能”做进一步地拆解分析：首先彻底弄明白效能提升的对象——“研发”是什么 ，拆解分析研发过程，构建出“研发过程”的分层模型图，对“研发”形成全面多维度的认知之后，一线业务研发人员就能看到自己每天都在进行的研发过程的全貌是什么，从而让大家了解整个研发过程中，哪些层面、分别容易出现什么问题、会导致团队效能下降；也能让大家看到日常使用的效能工具分别在“什么层次”解决了“研发过程中存在的哪些问题”。同时也希望能够通过研发过程分层模型图，给业务研发团队 Leader 提供一个查漏补缺的视角，让大家知道为什么在使用了各种“效率神器”、各种“全生命周期价值交付”的方法论以后，团队效能看起来还是没有太大改观：问题很可能就在于之前的做法仅仅是参照了各种最佳实践来使用各种工具，却没有把方法论和自己团队的实际情况结合起来进行实践——真正地分析团队目前在做什么事情，哪里有影响研发效能的问题，如何切实地与团队成员一步一步通过执行完成问题的解决，从而把效能提升起来。

分层模型的科学性来源于哲学层面的“事物的共性与个性的辩证关系”——世界上任何一个事物都是共性和个性的对立统一体，因此世界上任何一个事物都是可以按照从共性到个性来进行分层描述的。我们日常生活中最常见的分层描述方式就是生物界的“界门纲目科属种”体系，通过这样的分层体系，我们既能了解某物种与其他物种的共性，又能了解该物种有别于其他物种的个性部分，这对于我们深刻研究某个事物而言是非常有帮助的。

参考本文作者在