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

Posted 2023-01-19 阿里云云栖号

背景

纵观软件研发的发展历程，如果说“业务需求开发”是核心主线的话，那么研发效能建设就是这一核心主线之外最大的一条支线。每个历史阶段的研发效能所面对的主要矛盾次要矛盾都不一样，因此大家可以看到，在不同的历史阶段产生了不同的“研发效能提升产品”：从文本编辑器到带有各种功能的 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 提供一个查漏补缺的视角，让大家知道为什么在使用了各种“效率神器”、各种“全生命周期价值交付”的方法论以后，团队效能看起来还是没有太大改观：问题很可能就在于之前的做法仅仅是参照了各种最佳实践来使用各种工具，却没有把方法论和自己团队的实际情况结合起来进行实践——真正地分析团队目前在做什么事情，哪里有影响研发效能的问题，如何切实地与团队成员一步一步通过执行完成问题的解决，从而把效能提升起来。

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

参考本文作者在《技术一号位的方法论【业务篇】—— 信息技术与业务的关系》一文中提到的，某事物与其他事物相比具有共性和个性，因此可以这个视角来完成研发过程分层模型的建设，我们把共性的内容放在最下面，个性的内容放在最上面，因此一般的业务研发过程分层模型具体如下图所示：

​

图2 研发过程的分层模型

由上图可知，

1. 实践过程是一切人类活动的共性、基础过程
2. 生产过程是一种专业的、在人员、过程、结果方面都有一定要求的实践过程。
3. 信息系统研发过程，是信息产业中软件研发领域的生产过程，具备生产过程的共性，同时也具备信息技术的个性。
4. 业务系统研发过程，是信息系统研发过程的一个子集，与之相对的是技术系统研发过程
5. 在具体到某个业务的情况下，随着业务生命周期的变化，与之对应的同阶段的研发过程也存在着差异

在分层模型的各个层次中，每个层次的核心要素和关键维度不一样，由下至上来看，上层是下层的特殊子集，具备着下层的共性的同时，存在着自身的个性，从而使之与其他过程有所区分。我们用一个常见的某某公司电商\\广告\\社交等业务研发过程来看，它具备下层所有的共性，同时也有它自己的个性。在使用分层模型来剖析研发过程的时候，就会发现我们常常使用的各种 CI\\CD 工具，解决的是 “信息系统研发过程” 层面中的共性的问题：代码如何不断多周期持续性迭代，如何持续性交付，如何无损地进行持续性的部署；我们经常使用的需求管理工具，解决的也是“信息系统研发过程”层面中的共性问题，如下图所示：

​

图3 常见的研发效能工具解决的是哪些层面的问题

从上面的图我们可以看到，从这些常见的解决效能问题的技术产品的视角来看，因为技术产品本身要回答 “做产品”还是“做项目” 的问题，因此选择“做产品”的一定瞄准尽可能多的客户的共性问题，在此基础上再解决定制化的问题，即提出各种架构、模式、机制来支持未来可能的定制化，因此它对更上层的、更具体的效能问题其实不解决的，或者说，从投入产出比的角度来看，产品型效能工具在诞生之初就无法做特例情况的支持，只能通过后期的基于各个团队实际情况的自定义开发来解决。所以这就是为什么用了效能工具还有效能问题的根本原因：它只解决了它要解决的效能问题，但是它没有解决你所面临的全部的效能问题。作为研发团队的 Leader，要非常清晰地看到哪些产品解决哪些问题，更要非常清晰地知道自己的团队目前面临的效能问题究竟是什么，怎么形成的，如何解决，事实上就是分析清楚当前团队在研发效能建设领域面临的主要矛盾次要矛盾是什么，这个分析可以参考文章：《技术一号位的方法论【理论篇】—— 分析事物本质的必要性及事物本质分析的操作步骤》中提到的方法来进行分析。当然我们也看到很多方法论，也是需要注意方法论背后的本质或者背后意味着需要做哪些事情，如果只是单纯地模仿，也无法解决团队现状中面对的困境。

通过研发过程的分层模型，我们了解了自己参与的研发过程的个性和共性，也为我们做效能提升时建立指标体系提供了最重要的参考。接下来我们就继续拆解对于一个研发团队而言，研发效能建设究竟是什么样的——肯定不是只使用某个产品或工具就万事大吉了。

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

从研发效能的几个要素来看，我们可以把研发效能建设过程拆分为几个大的体系，首先就是过程管理，然后是结果衡量，最后是效果评估，如下图所示（注意，营销线和销售线没有做细粒度的展开，同时几条线的并行时间对应关系也是示意图，实际情况既不一定要并行或串行，更多是整体并行但是不同线上的阶段会相互衔接）：

​

图4 研发效能建设体系与研发过程生命周期对应关系图

过程管理，是从业务战略到落地执行的全阶段管理，以技术能力保障需求交付为基础，囊括业务维度的各项事情，也涉及到了团队管理的各项事情。只做技术能力的建设，或只使用各种效能产品来围绕技术维度做提升，只是把效能提升的基础层面覆盖到了，而没有覆盖到业务和团队层面。这是很多研发团队 Leader 非常容易漏掉的一个方面，而继续提升团队效能的空间往往就暗含在这个方面中。

结果衡量，是执行结果的评估体系——用简单通俗的话来讲，就是确定“做事情做到什么程度了、有没有做完”。目标和指标体系的构建，是结果衡量的基础。从 KPI 到 OKR，目标是所有业务的启动原点，也是所有业务的执行终点，而这个过程中需要以指标体系来让业务各方感知到执行过程究竟怎么样，具体到研发团队来说，就是要知道研发本身的目标是什么，在整个落地过程中，哪些指标可以告诉我们目前的研发情况怎么样，要不要做调整，离达成结果还有多远。一般情况下都是以产品功能上线作为事情的结果，作为研发过程的目标，但是实际上应该以业务目标的达成作为研发过程的结果来衡量，而产品功能上线只是关键里程碑之一。一般业务研发团队没有和业务团队形成背靠背的关系，觉得我的产品功能交付了就 OK 了，事实上产品功能 OK 不 OK 得看这样的功能上线以后，对外部客户而言，C 端的用户是不是有了更好的体验，B 端的用户开展业务时是否更顺畅更高效更安全；对内部客户而言，特别是对业务团队来讲，是否为业务团队进行产品商业化的业务运营过程中提供了积极的影响，在营销、销售方面是否形成了更好的助力，而不是对业务团队开展后续业务制造了麻烦甚至是阻力。

效果评估，是执行结果在业务上带来的效果、对业务收益的影响的评估体系——用简单的话来讲，就是判断执行目标达成后，拿到的结果，对业务发展趋势有什么影响，对业务收入有什么影响，影响是积极的还是消极的，具体影响的指标情况是什么样的。对研发团队执行结果的效果评估，实际上就是从研发过程的视角过度到了业务发展的视角，需要一套业务洞察系统，从而能让团队 Leader 或者业务方看到研发对业务发展的影响。

看到这里，有些读者肯定会发现效果评估这个维度有些问题：影响业务发展的因素是多方面的，如何确定某个阶段业务指标的下降是由于研发团队的执行结果引起的？为什么不说是由产品引起的，或者是由运营引起的？想要把这个问题回答清楚，就需要我们先把最基础的实际情况分析清楚：

• 研发过程在业务开展过程中的站位是什么样的？
• 研发过程在业务发展过程中和其他过程的关系是什么样的？
• 研发过程在什么情况下能推动业务发展，什么情况下会阻碍业务发展？

因此接下来的几个小节，我们会继续进一步在理论上把研发效能这个命题分析清楚，让大家对研发效能建设有一个完整的认知，避免被各种大厂出厂的各种 “效能”工具或者业内各大牛分享的各类最佳实践局限住自己的思维，以为只要把工具用起来，把代码行数统计起来，团队的效能就会好。还是要回归最根本的实际情况，在理论的指引下实事求是地解决效能卡点问题，合理使用各种效能产品和工具，把效能建设扎实地覆盖到几个关键的维度，才能让研发团队的效能朝着好的方向发展。

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

前面几个小节从研发效能的定义作为切入点讲解了研发效能的概念和一些重要的维度，在认清其内涵之后，就要从整体视角来分析，从宏观的视角看到研发效能在日常工作中的版块位置。作为软件开发的一员，我们目前做的业务都是基于信息系统来完成价值创造的。信息行业的业务建设过程，包含有多个维度，如技术、运营、营销、财税法合规风控等，这些维度共同构成了一个业务价值链条，分别处于不同的环节，共同协作确保业务价值链条的持续循环运转，如下图所示（某个业务的链条还会和其他业务、企业外部协作伙伴构成更大的价值链条，即为产业链，继而与产业链上的上下游企业或价值链形成业务生态，因为与文章主题关系不大，这里就不再继续展开了）：

​

图5 研发过程在价值链中的位置

由上图可知，在信息产业业务中，信息系统研发过程主要横跨业务的价值创造、业务价值交付两个大的环节，同时也以支撑的形态存在于其他几个环节中。研发过程和其他几个核心业务环节共同决定着业务的发展形式，而每个环节发挥的作用不同，对业务的影响也不同，所以业务洞察系统的构建和使用，就能让业务决策者看到不同的环节在业务不同的生命周期中的影响是什么，看到研发过程的效能对整体业务效能的影响，从而可以更合理地定制执行策略，调整组织关系，确保业务发展方向与团队使命愿景和长期价值规划不发生偏离。

所以我们可以从研发过程在业务价值链条的位置得出研发效能在业务效能建设中的版块位置如下：

​

图6 研发效能建设在业务效能中的版块位置

研发效能直接关系到价值创造的结果，因此处于整个业务的基础版块，没有价值创造就无所谓后续整个链条；业务运营效能板块包含了对客相关的事务、商业化相关的事情，是产品与客户的连接器，也是产品价值的放大器，在产品价值创造完成后，它是最日常、最核心的部分；组织效能则是与人相关的事物的汇总，贯穿于所有的板块中，大的方面包括着单一团队使命履行的整体效能，也包括着多个不同团队之间协作效能，同时团队效能也与个人效能有着直接的相关性。

看清研发效能所处的版块之后，结合研发过程在价值链中的位置，就知道：

1. 在业务启动或新的产品功能创建阶段，研发效能对业务结果的影响比重最大；
2. 在业务功能上线后，业务运营效能对业务结果的影响比重上升，研发效能对业务结果的影响比重降低，但是仍然不可忽略；
3. 在业务进入商业化阶段后，业务的交付模式决定了研发效能对业务结果的影响比重：标准的产品型交付模式下，研发效能对业务结果影响比重不大；定制型的项目型交付模式，研发效能对业务结果影响比重提升。

基于这样的大规律，我们可以根据实际情况合理地得到研发效能的效果评估模型。

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

除了研发过程在价值链中所处的环节不同，会给业务带来不同的影响之外，在业务的生命周期中，不同阶段，研发过程所起到的作用也不一样，因此其效能建设的重点也不同，具体为：

1. 在业务启动阶段，研发效能建设的重点是如何确保研发团队能够进行大量、高质量、快速完成业务需求的交付。
2. 在业务发展阶段，研发效能建设的重点是如何通过效能指标倒逼团队构建标准化的产品功能，沉淀业务能力，为规模化复制做准备
3. 在业务成熟阶段，研发效能建设的重点是则是提升稳定性和效率，降低各维度的成本，促使研发团队在业务增量有限的情况下利用技术的创新带来新的机会，使技术成为业务的增长源之一。
4. 在业务消亡阶段，研发效能建设的重点是资产沉淀复用，从而让业务消亡但是组织的长期投入不会跟着消失，而是让过去的成本价值沉淀在技术体系内变为其他业务复用的资产。

由上可知，研发效能建设在业务不同期间的建设重点是什么，常规的做法就是随着业务的变化做研发效能建设的侧重点的调整。而在团队人员充足的情况下，可以适当地多维度展开研发效能的建设工作，不需要被业务生命周期束缚，也就是说，完全可以通过效能建设的超前性来避免下一个阶段可能出现的问题，从而做到“治未病”，也就达到了“善战者无赫赫之功”的境界（这一境界对业务是有利的，对个人而言则要看上层管理者的感知力和偏好了，不展开讨论了）。

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

研发效能建设除了和它自身站位、和它所对应的业务生命周期有关以外，也和研发团队的生命周期有关。人作为实践的主体，团队作为研发过程执行的主体，恰恰是对研发效能影响最大的一个方面，也是最富有变化、最需要实事求是进行针对性的分析和调整的一个维度。

对于小型团队而言，团队特征是小而精，聚焦的业务领域单一，效能建设最重要的是研发过程的效率的提升，而不是需求的交付量。向 5 个人的团队要产出，不如向 5 个人的团队要效率，效率高了，产出和质量都不会差——很多质量问题都是在高压环境下对“某些影响产出质量的关键要素”执行缺失或检查遗漏导致的。如果向小型团队要产量，把需求交付数量作为研发效能建设的考核指标，那么在高压环境（高压环境=需求并行+时间倒排）下只有加班这一个途径能在短期内让“效能指标”看起来达标了，但是实际情况却是：5 个人即便是通宵加班，排除在产出质量方面带来的负面影响不谈，实际按照 50%的加班产出率来算，也只多出来 2.5 个人的产量，可是这却是燃烧团队生命力和未来潜力实现的，综合收益极差。小型团队适合使用效率指标来约束，强调日常工作中所有影响业务产出的工作都尽量工具化、系统化、自动化，降低在非业务产出板块中投入的精力，给业务产出留出更多的时间和精力，那么产量、质量自然会上来。

中型团队的特点是承接比较复杂的整块业务，和不同的业务方进行比较密切的配合，需要把研发效能的建设聚焦到流程和标准的完善上。从而让协同更简单流畅，让关键环节的产出符合质量要求，同样对业务产出和结果有积极影响。

大型团队的特点是综合程度高，往往会承接多个不同的、但是却又紧密相关的业务线，彼此相互独立发展却又相互支撑配合。这样的团队，研发效能建设的重点也不是需求的交付量，而是多个不同团队的产出是否能够相互配合支持，形成合力，在宏观层面对业务形成积极影响。这就需要把研发效能的建设聚焦在结果的评估和效果的衡量上。大型团队是由中型团队组成的，中型团队是由小型团队组成的，对不同类型的团队，结合它们各自的特征，对不同的层面分层次进行建设和约束引导，自然能覆盖到很多重要的效能指标。

很多团队的效能指标会停留在编码量、需求交付量，实际上只是照顾到了最基础的效能指标，却没有分团队类型、分业务阶段做动态调整，自然很难发挥出指标的牵引作用，原因就在于不够实事求是，对团队和业务的个性考虑不足。

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

结合第二章各小节的分析结论，我们可以形成一个综合性的研发效能提升体系。

研发效能建设的内涵

研发效能建设是过程管理、结果衡量、效果评估的综合体系建设，整个体系除了研发自身的成本、效率、质量问题之外，还涉及到全业务价值链路、研发组织管理、多业务角色团队协同等大的综合维度。在整个研发效能建设过程中，各类型的研发效率提升工具的使用是基础，目标、指标体系系统是关键，业务洞察系统是核心。同时在研发效能建设过程中，要充分考虑到研发效能和业务生命周期的关系，和团队生命周期、团队规模的关系，在不同的阶段和不同团队规模的情况下，进行有针对性、有侧重点的提升，避免只做常规的效能建设。

研发效能建设的使命

研发效能建设的使命是提升研发过程的效率，降低研发过程的成本，确保研发过程执行的结果能够达到预期的目标，并且通过全业务环节的评估、反馈和调节来提升研发结果对业务发展的积极影响，提升业务结果的经济效益。

研发效能的指标体系

按照图2 研发过程的分层模型来看，研发效能建设也需要针对每个层次做针对性的提升，具体如下：

1. 在实践过程这个层面，要做好最宏观的“过程的效率、过程的成本、结果的效益” 三个方面的考量，这个考量是宏观层面的，适用一切实践过程，自然也就是信息系统研发效能建设的宏观综合指标。如下图所示：

​

图7 实践过程的效能指标

1. 在生产过程这个层面，要分别从“生产团队、生产过程、生产系统、生产结果评判”几个维度来感知生产过程的情况，例如团队人员是否具备从事生产活动的基本资格、生产过程是否有流程、有标准、生产系统的产能和先进性、生产结果的收益等等，形成如下图所示的生产过程效能指标：

​

图8 生产过程的效能指标

2.在信息化系统建设过程这个层面，从团队、业务、技术、技术产出几个维度来感知研发过程和结果的情况，例如研发团队成员技能和素质是否满足信息系统研发要求；业务需求是否合理，是否能够有合理的技术方案实现；技术方面系统和架构设计是否与业务特征匹配等等，具体如下图所示：

​

图9 信息系统研发过程的效能指标

3.在业务系统研发过程这个层面，维度相同，但是侧重点已经和信息化系统建设存在一定的差异，特别是技术方面的要求，会具体到是否能支撑业务发展，是否能保障业务发展，是否能驱动业务发展，其他维度不再展开讨论，具体如下图所示：

​

图10 业务系统研发过程的效能指标

4.在成熟业务的研发过程中，业务阶段特征非常明显，对研发团队、研发工作的要求也和业务特征息息相关，总体而言是 业务上“求稳、求变、求生”，团队梯队配置上也是“梯队求稳”、“稳中求变”、“变中求生”，而研发工作上也是“求稳”、“求新”、“求沉淀”，具体如下图所示：

​

图11 成熟业务系统研发过程的效能指标

5.在具体的自己负责的业务研发过程中，则需要结合当前的团队、业务阶段等特征，来确定指标了，这里就不给出具体的信息了，读者可以根据自己团队的实际情况，从团队、业务、技术、产出结果评价四个维度分别构建出你自己业务的效能指标。

结合研发过程的分层模型，分别把不同层面涉及到效能的指标分析清楚，这样就完成了整个研发效能的指标体系的梳理，结合上一篇文章《技术一号位的方法论【业务篇】——如何设定业务目标》我们可以知道，指标体系的使命是让我们感知到做的事情目前实际情况是怎么样的，让我们能够通过可感知的指标来发现目前事物发展过程中存在的问题。

同时大家可以发现，“研发需求交付数量”在众多指标中只是很不起眼的一个，几乎难以发现。可实际工作中，很多团队喜欢看这个指标，我们抛开传统软件公司不谈，以大家对互联网大厂的了解（不论是亲身经历还是有所耳闻），会有研发团队的工作量是不饱和的吗？作为管理者要思考，是不是存在一种可能性，既在团队现有“需求交付数量”的基线上有所提升，所有人的工作量又有所降低，整体工作负担同时有所下降呢？顶层决策者们想要提升整个团队的产出，下面的管理者们就会要求团队加班，这个对策简单、直接、粗暴、最重要的是见效快，见效快意味着好用而无心理负担，所以顶层老板不细看真的会觉得这个 Leader 执行力强，可是长期来看，却是在饮鸩止渴，这就要求顶层决策者们多些思考，在执行的引导上多些智慧，使用合理的指标、恰当的方式来促进团队产出的提升。

不同阶段研发效能的考核目标

指标体系建立以后，我们可以通过指标体系的反馈来看到当前的研发过程中存在哪些问题，能通过各种现象来分析背后的问题是什么，从而确定近期的主要矛盾次要矛盾，于是就得出了当前研发效能建设的短期目标；宏观层面的指标需要经过较长时间的持续努力和改进，因此我们也能从指标体系里面可以得到中长期的目标，于是可以得出整个研发效能建设的目标体系。阶段性的目标和指标体系的对应关系如下图所示。需要注意的是，该示意图只展示了普遍的、普适的情况，没有画出特殊情况，因为特殊情况千变万化：比如有的团队就是把“成本下降”当做短期目标，想要在短期内看到成效，这种情况就是根据其团队的实际情况得出的特殊情况，看起来是和下图的关系不相符的。但是事实上从更大的更宏观的尺度来看，成本降低是一个全生命周期的长期的事情，近期成本压下去了就不做长期的治理，那么成本问题依然会在某个阶段跳出来需要“再治理一次”，所以最终来看还是符合下图所示的对应关系的：

​

图12 阶段性目标与指标体系的对应关系

实践案例介绍

背景情况介绍

4.1.1 业务方面

1.现状

• • 成熟电商平台业务，核心业务模式已经趋于稳定，受客户群体特征和规模限制，已经进入平台期
  • 业务领域复杂，多达 8 个核心域，分别为商品域、管控域、交易域、订单域、支付域、优惠域、结算域、商业化域，也包括 8+支撑业务域，如权限域、合同域、租户域、用户域、积分域、互动任务域、流量变现、风控等
  • 为了避免可预料到的业务规模见顶带来的业务目标增长停滞，需要尝试新的业务模式带来增量，整体提升业务规模。

2.特征

• • 业务模式为 B2B2C，即服务企业客户，同时服务企业客户的 C 端用户。
  • 现有业务模式进入成熟期
  • 成熟业务模式存在数以百计的企业客户
  • 需要探索新的业务模式和客户群体，寻找业务增量

3.面对的挑战

• • 需要保障成熟业务模式稳定发展
  • 需要探索新的业务模式

4.1.2 技术方面

1.现状

• • 分布式技术体系+复杂业务数字化
  • 经过 4 年的建设，技术系统众多，除了业务领域对应的微服务之外，还有众多的“业务中间件”，包括事件服务、mock 系统、分布式锁、元数据服务、异步任务服务、文件服务、网关服务、业务配置服务等等

2.特征

• • 受业务特征的影响，技术体系特征也划分为 ToB 和 ToC 两类
  • ToB 业务模式下，多租户、基于标准业务能力的定制化、复杂业务建模是主要的技术命题
  • ToC 业务模式下，大流量、高并发、高可用、跨业务方的数据一致性、分布式业务系统的最终一致性等是主要的技术命题
  • 高度复杂、流量巨大、业务数据体量巨大的情况下，整体系统的正确性、稳定性提升、成本控制、效率提升

3.面临的挑战

• • 架构设计的演进和分布式技术体系的落地
  • 分布式技术系统的稳定性建设
  • 技术领域和业务领域建设的相互促进
  • 受业务形态影响，技术团队承载着对外技术服务的职责

4.1.3 团队方面

1. 现状

• 技术团队：12 服务端（1 主管 + 3 正式员工 + 8 外包员工）+ 2 数据 + 3 测试 + 3 前端
• 团队属于综合型团队，承载着：业务需求、研发效能、运营效能、客户技术服务、稳定性建设等几大板块的工作内容。

2.特征

• • 团队规模小，业务领域众多，日常工作版块众多
  • 综合型技术团队

3.面临的挑战

• • 小微型团队支撑大型业务，单迭代需求多，临时紧急性任务多，人为因素引起的研发交付过程管理困难
  • 团队梯队亟需优化补充
  • 团队涉及的工作板块多，人员日常工作负载较高

整体总结下来，以团队的视角来看，挑战主要集中在如何以小微型团队支撑大型业务，在成熟型业务日常迭代的过程中，还需要服务客户、保障系统稳定、同时需要提升研发、业务运营的工作效能，同时还要肩负着重要的业务模式探索的任务，充分体现了既要又要还要。同时因为团队组成复杂，人员培养也是重中之重，在这种情况下，作为团队 Leader，应该如何提升研发效能？

效能建设原则确定

根据 2.7 小节内容可以知道，小型研发团队的研发效能侧重点不在于需求交付数量，而是在于日常工作效率和质量方面。因此在大团队的效能指标的基础之上（代码量、单测覆盖率），我们结合自己团队的情况，确认团队的研发效能建设围绕着 “保业务需求，提工作效率，降工作负担，数字化清晰化精细化”展开，具体而言：

1. 实事求是地解决团队效能问题，既不是简单地使用某个工具某套系统就觉得万事大吉，也不是简单地考核诸如代码量、需求量、需求交付周期等片面的单一维度的指标。
2. 业务需求的完成和交付是团队工作的第一优先级，所有的效能建设都围绕保障业务输出来进行，确保小型团队日常工作对业务仍然具有推动能力，而不是让生产力被巨大的业务规模、复杂的业务模式、众多的客户服务工作消耗在巨量的琐碎的事务中。
3. 向过程要质量，而不是向结果要质量。这一个原则，针对的是团队日常交付物的质量保障和整个技术体系的稳定保障工作而言的。在团队成员水平参差不齐的情况下，如何确保产出物的质量稳定地处于较高水平的质量基线之上，只有提升过程管理才能达到要求，而在结果上设置再多的卡点，都没有太好的效果，因为结果的卡点是最后一环，单纯追求结果卡点指标不能解决问题，因此需要以过程指标来牵引日常工作，从而确保结果卡点指标的达成。同时由于现有团队规模明显无法按照普通的方式保障大型分布式技术系统的稳定性。一些大型的百人级别的业务团队可以有一定的资源余量来专门做横向的稳定性建设工作，专门去做应急保障，故障出现了做应急、做止血、做恢复、做复盘，小型团队不能学习大型团队的“最佳实践”，只能别开生路、创造性地使用不同的方式完成稳定性的建设工作。
4. 工作流程的健全和充分执行，是现阶段团队研发效能建设的主要矛盾。很多小型团队因为人少、事多，因此为了追求“所谓的快”而没有工作协作流程，或者有了流程也打着“敏捷”、“高效”的幌子跳过流程的一些环节，对已经经过实践检验的流程不做充分执行。还有一些团队依靠行政命令所有人严格执行各种流程，但是却对流程每个环节的产出物不设标准、不做检查，这样也只能积累一些流程执行数据而无法真正地解决过程管理要解决的问题。我们的思路不是砍掉流程、或者跳过流程的环节，而是降低研发同学执行流程的成本。让大家花费更低的成本把流程跑完，在自己负责的环节产出符合标准的产出物传递到协作下游，通过流程完成各项工作中和其他角色的高质量协作，让大家既能享受到流程带来的好处，也能节省出更多的时间。所以效能建设的重点就是健全工作协作流程，完善标准定义，降低所有人为了执行流程而投入的精力和成本，其中最后一点也是重中之重，是确保流程可以被所有人接受的前提条件。
5. 所有的效能建设都要基于数字化的方式来完成，让所有人既能看得见研发团队的整体负载情况，也能看到各个角色的研发人员日常工作版块，每个版块投入的精力情况，最终能够针对不同的角色和群体进行针对性地效能提升，同时也方便决策者们基于团队当前的负载做出合理的决策，数字化让研发效能建设从简单指标考核过渡到精细化过程管理、体系化地结果评估成为可能。

在这 5 个原则的指引和约束之下，几年以来我们分阶段进行了一系列的效能提升工作，具体见后续章节。

效能建设实践过程

4.3.1 研发日常工作版块梳理

研发效能的第一个阶段始于3年前，在《技术一号位的方法论【业务篇】——如何画业务大图》一文中我提到过当时团队面临的一些情况以及通过业务大图如何做了组织关系的设计和调整，其他方面的具体细节本文不再重复，只讲一下研发效能方面做的一些事情。

1. 划分业务领域和版块，让所有人，包括协作的上下游产品团队、运营团队都从过去杂乱的认知演变为 “产品功能——业务领域——工作版块”体系，并且根据团队成员的个人特征、主观意愿、未来期望划分人员与工作版块的对应关系，在研发团队内部形成版块 Owner 的角色。
2. 分析各个工作板块中的关系，以 “C 端核心业务链路” 和 “B 端管控链路” 为两大核心板块，以“稳定性建设、研发效能、运营效能建设” 为横向底层支撑性板块，以 “业务生态建设” 为未来发展布局版块 组合成了目前的工作版块，整个体系已经稳定存在了 3 年，支撑了业务各个发展阶段的需求，到目前来看也不需要做大的调整。
3. 客户技术服务工作内容多、杂、要求高、易被投诉，当时占用大量的研发资源，非常明显地威胁到了业务需求的交付，在无法扩张团队规模的情况下，把技术服务体系暂时归拢到 “稳定性建设、研发效能、运营效能建设”版块中，构建了多级技术服务体系，分别是 “机器人+知识库”作为第一级， “稳定性建设、研发效能、运营效能建设”版块的外包同学作为技术服务的第二级，该板块的 Owner 作为技术服务的第三级，各个业务领域的一线研发同学作为最后一级。

在研发效能第一阶段的建设完成之后，基本上形成了一个比较好的局面，整个技术团队的工作效能在“需求的承接和交付数量”方面，较过去有明显的提升，同时过去一直遗漏的客户服务方面也有了体系化的支持工作，成为了综合性研发团队的重要工作版块。

4.3.2 研发日常工作流程梳理

随着业务的持续发展，从最开始的启动期到后面逐步规模化起量期，业务需求也从追求数量变成追求质量。在进入这个业务阶段之后，过去的大量的成块的产品功能不再是研发工作内容的主体，变成了大量的分散的业务需求，在既有功能上适配新的业务场景、在旧的技术架构上适配新的业务需求成了主要内容。因此在代码量上会呈现出非常明显的下降的趋势，而技术方案文档、技术自测报告随着需求变多也呈现出了上升的趋势，一线研发同学在这个阶段工作内容和重点也发生了变化。随着迭代发布的增多，产品功能日趋复杂，在技术团队规模不变甚至小部分萎缩的情况下，需求交付数量提升意味着需求交付质量在不做干预的情况下必然下降。这也是研发效能建设进入第二阶段以后呈现出的特征和重点建设维度。

我们在业务起步期间也有各种各样的研发流程，但是存在这样的问题：

1. 研发流程覆盖面非常窄，只涵盖了需求研发的生命周期，而且这个涵盖面比较窄的流程也完全是以 CI/CD 系统为主导的，就是简单的 “写代码、做部署、做测试、做发布、做验证”。
2. 大量的日常工作没有协作流程，更不用提协作流程的关键环节的识别和标准的定制
3. 后续根据实际情况补充了一些流程，但是流程本身停留在文档和宣贯层面，执行过程依靠相关人员人肉记忆和维护，流程执行不充分，并且新增的流程让团队成员觉得效率变低，投入在非研发工作方面的精力变大，存在一定的抵触情绪，流程的执行依靠一线成员的自觉和管理者的抽查。

在团队出现了“非技术系统 BUG 而是人员本职工作执行不到位引起线上故障的黑天鹅事件”之后，所有的矛盾终于集中爆发，大家经过复盘第一次改变了自己的视角，从一线执行者的视角转变为管理者视角，看到了流程的重要性和必要性。后面作为团队 Lleader，我个人也有所反思，过去的流程都只停留在了文档中，就觉得团队已经有流程了，经过此次也感受到了从决策到执行其实存在着巨大的鸿沟，而这个鸿沟只能先由管理者做出努力想办法填平，才可能顺利地完成决策和执行的过度。因此后面把团队是否有工作流程的标准设定为：

1. 是否有工作流程的说明文档，讲清楚流程参与的角色有哪些，不同的角色参与哪些环节，不同流程环节产出物的标准是什么。
2. 团队成员是否都知道这个流程的全部信息，如果有一个人不知道这个流程的全貌，就说明流程约等于没有。
3. 这个流程要用公司的工作流引擎驱动，不同人在不同阶段在线参与流程的推进和停退工作，如果上游的产物符合标准，则依靠上游输入完成本环节的工作，形成标准产出物，反馈到在线的流程中，最后推进流程向下一个环节流转。每个环节的流转都有即时通信工具（本团队为钉钉）提示到相关人员，既包括执行人，也包括关心流程进展的管理者。

随后把涉及到研发过程（网上各种文章都有，不再细聊）的几个核心流程在线化，避免有人因为忘记而导致关键流程环节被跳过。这些流程包括：

1. 产品需求开发流程
2. 产品需求提测流程
3. 产品需求发布流程
4. 系统保障应急流程

每个流程存在很多的环节，都是用宜搭的流程设计器完成搭建和后续的运转。从整个流程从上线到目前为止，已经分别有 100+流程完成流转，下一个阶段的效能建设，就是基于这些流程在运转过程中产生的各种时间数据、状态变化数据形成团队的效能基线，从而能让管理者发现各个指标的变化情况，确定问题根因，进行针对性的改进。

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

除了工作流程补充和流程的在线化之外，过去使用 AONE 来记录业务需求和各种 BUG，整体记录还是围绕着业务需求来做的，而当前的业务阶段对技术团队的要求已经发生了变化，并且实际工作版块中，业务需求研发的比例呈现一定的下降趋势，客户技术服务、稳定性问题的 解决、