作者：贺科学（晨末）
背景
纵观软件研发的发展历程，如果说“业务需求开发”是核心主线的话，那么研发效能建设就是这一核心主线之外最大的一条支线。每个历史阶段的研发效能所面对的主要矛盾次要矛盾都不一样，因此大家可以看到，在不同的历史阶段产生了不同的“研发效能提升产品”：从文本编辑器到带有各种功能的 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 研发过程的分层模型
由上图可知，
- 实践过程是一切人类活动的共性、基础过程
- 生产过程是一种专业的、在人员、过程、结果方面都有一定要求的实践过程。
- 信息系统研发过程，是信息产业中软件研发领域的生产过程，具备生产过程的共性，同时也具备信息技术的个性。
- 业务系统研发过程，是信息系统研发过程的一个子集，与之相对的是技术系统研发过程
- 在具体到某个业务的情况下，随着业务生命周期的变化，与之对应的同阶段的研发过程也存在着差异
在分层模型的各个层次中，每个层次的核心要素和关键维度不一样，由下至上来看，上层是下层的特殊子集，具备着下层的共性的同时，存在着自身的个性，从而使之与其他过程有所区分。我们用一个常见的某某公司电商\广告\社交等业务研发过程来看，它具备下层所有的共性，同时也有它自己的个性。在使用分层模型来剖析研发过程的时候，就会发现我们常常使用的各种 CI\CD 工具，解决的是 “信息系统研发过程” 层面中的共性的问题：代码如何不断多周期持续性迭代，如何持续性交付，如何无损地进行持续性的部署；我们经常使用的需求管理工具，解决的也是“信息系统研发过程”层面中的共性问题，如下图所示：
图3 常见的研发效能工具解决的是哪些层面的问题
从上面的图我们可以看到，从这些常见的解决效能问题的技术产品的视角来看，因为技术产品本身要回答 “做产品”还是“做项目” 的问题，因此选择“做产品”的一定瞄准尽可能多的客户的共性问题，在此基础上再解决定制化的问题，即提出各种架构、模式、机制来支持未来可能的定制化，因此它对更上层的、更具体的效能问题其实不解决的，或者说，从投入产出比的角度来看，产品型效能工具在诞生之初就无法做特例情况的支持，只能通过后期的基于各个团队实际情况的自定义开发来解决。所以这就是为什么用了效能工具还有效能问题的根本原因：它只解决了它要解决的效能问题，但是它没有解决你所面临的全部的效能问题。作为研发团队的 Leader，要非常清晰地看到哪些产品解决哪些问题，更要非常清晰地知道自己的团队目前面临的效能问题究竟是什么，怎么形成的，如何解决，事实上就是分析清楚当前团队在研发效能建设领域面临的主要矛盾次要矛盾是什么，这个分析可以参考文章：《技术一号位的方法论【理论篇】—— 分析事物本质的必要性及事物本质分析的操作步骤》中提到的方法来进行分析。当然我们也看到很多方法论，也是需要注意方法论背后的本质或者背后意味着需要做哪些事情，如果只是单纯地模仿，也无法解决团队现状中面对的困境。
通过研发过程的分层模型，我们了解了自己参与的研发过程的个性和共性，也为我们做效能提升时建立指标体系提供了最重要的参考。接下来我们就继续拆解对于一个研发团队而言，研发效能建设究竟是什么样的——肯定不是只使用某个产品或工具就万事大吉了。
研发效能建设是过程管理、结果衡量、效果评估体系的综合体
从研发效能的几个要素来看，我们可以把研发效能建设过程拆分为几个大的体系，首先就是过程管理，然后是结果衡量，最后是效果评估，如下图所示（注意，营销线和销售线没有做细粒度的展开，同时几条线的并行时间对应关系也是示意图，实际情况既不一定要并行或串行，更多是整体并行但是不同线上的阶段会相互衔接）：
图4 研发效能建设体系与研发过程生命周期对应关系图
过程管理，是从业务战略到落地执行的全阶段管理，以技术能力保障需求交付为基础，囊括业务维度的各项事情，也涉及到了团队管理的各项事情。只做技术能力的建设，或只使用各种效能产品来围绕技术维度做提升，只是把效能提升的基础层面覆盖到了，而没有覆盖到业务和团队层面。这是很多研发团队 Leader 非常容易漏掉的一个方面，而继续提升团队效能的空间往往就暗含在这个方面中。
结果衡量，是执行结果的评估体系——用简单通俗的话来讲，就是确定“做事情做到什么程度了、有没有做完”。目标和指标体系的构建，是结果衡量的基础。从 KPI 到 OKR，目标是所有业务的启动原点，也是所有业务的执行终点，而这个过程中需要以指标体系来让业务各方感知到执行过程究竟怎么样，具体到研发团队来说，就是要知道研发本身的目标是什么，在整个落地过程中，哪些指标可以告诉我们目前的研发情况怎么样，要不要做调整，离达成结果还有多远。一般情况下都是以产品功能上线作为事情的结果，作为研发过程的目标，但是实际上应该以业务目标的达成作为研发过程的结果来衡量，而产品功能上线只是关键里程碑之一。一般业务研发团队没有和业务团队形成背靠背的关系，觉得我的产品功能交付了就 OK 了，事实上产品功能 OK 不 OK 得看这样的功能上线以后，对外部客户而言，C 端的用户是不是有了更好的体验，B 端的用户开展业务时是否更顺畅更高效更安全；对内部客户而言，特别是对业务团队来讲，是否为业务团队进行产品商业化的业务运营过程中提供了积极的影响，在营销、销售方面是否形成了更好的助力，而不是对业务团队开展后续业务制造了麻烦甚至是阻力。
效果评估，是执行结果在业务上带来的效果、对业务收益的影响的评估体系——用简单的话来讲，就是判断执行目标达成后，拿到的结果，对业务发展趋势有什么影响，对业务收入有什么影响，影响是积极的还是消极的，具体影响的指标情况是什么样的。对研发团队执行结果的效果评估，实际上就是从研发过程的视角过度到了业务发展的视角，需要一套业务洞察系统，从而能让团队 Leader 或者业务方看到研发对业务发展的影响。
看到这里，有些读者肯定会发现效果评估这个维度有些问题：影响业务发展的因素是多方面的，如何确定某个阶段业务指标的下降是由于研发团队的执行结果引起的？为什么不说是由产品引起的，或者是由运营引起的？想要把这个问题回答清楚，就需要我们先把最基础的实际情况分析清楚：
- 研发过程在业务开展过程中的站位是什么样的？
- 研发过程在业务发展过程中和其他过程的关系是什么样的？
- 研发过程在什么情况下能推动业务发展，什么情况下会阻碍业务发展？
因此接下来的几个小节，我们会继续进一步在理论上把研发效能这个命题分析清楚，让大家对研发效能建设有一个完整的认知，避免被各种大厂出厂的各种 “效能”工具或者业内各大牛分享的各类最佳实践局限住自己的思维，以为只要把工具用起来，把代码行数统计起来，团队的效能就会好。还是要回归最根本的实际情况，在理论的指引下实事求是地解决效能卡点问题，合理使用各种效能产品和工具，把效能建设扎实地覆盖到几个关键的维度，才能让研发团队的效能朝着好的方向发展。
研发效能在业务效能建设中的位置
前面几个小节从研发效能的定义作为切入点讲解了研发效能的概念和一些重要的维度，在认清其内涵之后，就要从整体视角来分析，从宏观的视角看到研发效能在日常工作中的版块位置。作为软件开发的一员，我们目前做的业务都是基于信息系统来完成价值创造的。信息行业的业务建设过程，包含有多个维度，如技术、运营、营销、财税法合规风控等，这些维度共同构成了一个业务价值链条，分别处于不同的环节，共同协作确保业务价值链条的持续循环运转，如下图所示（某个业务的链条还会和其他业务、企业外部协作伙伴构成更大的价值链条，即为产业链，继而与产业链上的上下游企业或价值链形成业务生态，因为与文章主题关系不大，这里就不再继续展开了）：
图5 研发过程在价值链中的位置
由上图可知，在信息产业业务中，信息系统研发过程主要横跨业务的价值创造、业务价值交付两个大的环节，同时也以支撑的形态存在于其他几个环节中。研发过程和其他几个核心业务环节共同决定着业务的发展形式，而每个环节发挥的作用不同，对业务的影响也不同，所以业务洞察系统的构建和使用，就能让业务决策者看到不同的环节在业务不同的生命周期中的影响是什么，看到研发过程的效能对整体业务效能的影响，从而可以更合理地定制执行策略，调整组织关系，确保业务发展方向与团队使命愿景和长期价值规划不发生偏离。
所以我们可以从研发过程在业务价值链条的位置得出研发效能在业务效能建设中的版块位置如下：
图6 研发效能建设在业务效能中的版块位置
研发效能直接关系到价值创造的结果，因此处于整个业务的基础版块，没有价值创造就无所谓后续整个链条；业务运营效能板块包含了对客相关的事务、商业化相关的事情，是产品与客户的连接器，也是产品价值的放大器，在产品价值创造完成后，它是最日常、最核心的部分；组织效能则是与人相关的事物的汇总，贯穿于所有的板块中，大的方面包括着单一团队使命履行的整体效能，也包括着多个不同团队之间协作效能，同时团队效能也与个人效能有着直接的相关性。
看清研发效能所处的版块之后，结合研发过程在价值链中的位置，就知道：
- 在业务启动或新的产品功能创建阶段，研发效能对业务结果的影响比重最大；
- 在业务功能上线后，业务运营效能对业务结果的影响比重上升，研发效能对业务结果的影响比重降低，但是仍然不可忽略；
- 在业务进入商业化阶段后，业务的交付模式决定了研发效能对业务结果的影响比重：标准的产品型交付模式下，研发效能对业务结果影响比重不大；定制型的项目型交付模式，研发效能对业务结果影响比重提升。
基于这样的大规律，我们可以根据实际情况合理地得到研发效能的效果评估模型。
研发效能建设与业务生命周期的辩证关系
除了研发过程在价值链中所处的环节不同，会给业务带来不同的影响之外，在业务的生命周期中，不同阶段，研发过程所起到的作用也不一样，因此其效能建设的重点也不同，具体为：
- 在业务启动阶段，研发效能建设的重点是如何确保研发团队能够进行大量、高质量、快速完成业务需求的交付。
- 在业务发展阶段，研发效能建设的重点是如何通过效能指标倒逼团队构建标准化的产品功能，沉淀业务能力，为规模化复制做准备
- 在业务成熟阶段，研发效能建设的重点是则是提升稳定性和效率，降低各维度的成本，促使研发团队在业务增量有限的情况下利用技术的创新带来新的机会，使技术成为业务的增长源之一。
- 在业务消亡阶段，研发效能建设的重点是资产沉淀复用，从而让业务消亡但是组织的长期投入不会跟着消失，而是让过去的成本价值沉淀在技术体系内变为其他业务复用的资产。
由上可知，研发效能建设在业务不同期间的建设重点是什么，常规的做法就是随着业务的变化做研发效能建设的侧重点的调整。而在团队人员充足的情况下，可以适当地多维度展开研发效能的建设工作，不需要被业务生命周期束缚，也就是说，完全可以通过效能建设的超前性来避免下一个阶段可能出现的问题，从而做到“治未病”，也就达到了“善战者无赫赫之功”的境界（这一境界对业务是有利的，对个人而言则要看上层管理者的感知力和偏好了，不展开讨论了）。
研发效能建设与研发团队类型的辩证关系
研发效能建设除了和它自身站位、和它所对应的业务生命周期有关以外，也和研发团队的生命周期有关。人作为实践的主体，团队作为研发过程执行的主体，恰恰是对研发效能影响最大的一个方面，也是最富有变化、最需要实事求是进行针对性的分析和调整的一个维度。
对于小型团队而言，团队特征是小而精，聚焦的业务领域单一，效能建设最重要的是研发过程的效率的提升，而不是需求的交付量。向 5 个人的团队要产出，不如向 5 个人的团队要效率，效率高了，产出和质量都不会差——很多质量问题都是在高压环境下对“某些影响产出质量的关键要素”执行缺失或检查遗漏导致的。如果向小型团队要产量，把需求交付数量作为研发效能建设的考核指标，那么在高压环境（高压环境=需求并行+时间倒排）下只有加班这一个途径能在短期内让“效能指标”看起来达标了，但是实际情况却是：5 个人即便是通宵加班，排除在产出质量方面带来的负面影响不谈，实际按照 50%的加班产出率来算，也只多出来 2.5 个人的产量，可是这却是燃烧团队生命力和未来潜力实现的，综合收益极差。小型团队适合使用效率指标来约束，强调日常工作中所有影响业务产出的工作都尽量工具化、系统化、自动化，降低在非业务产出板块中投入的精力，给业务产出留出更多的时间和精力，那么产量、质量自然会上来。
中型团队的特点是承接比较复杂的整块业务，和不同的业务方进行比较密切的配合，需要把研发效能的建设聚焦到流程和标准的完善上。从而让协同更简单流畅，让关键环节的产出符合质量要求，同样对业务产出和结果有积极影响。
大型团队的特点是综合程度高，往往会承接多个不同的、但是却又紧密相关的业务线，彼此相互独立发展却又相互支撑配合。这样的团队，研发效能建设的重点也不是需求的交付量，而是多个不同团队的产出是否能够相互配合支持，形成合力，在宏观层面对业务形成积极影响。这就需要把研发效能的建设聚焦在结果的评估和效果的衡量上。大型团队是由中型团队组成的，中型团队是由小型团队组成的，对不同类型的团队，结合它们各自的特征，对不同的层面分层次进行建设和约束引导，自然能覆盖到很多重要的效能指标。
很多团队的效能指标会停留在编码量、需求交付量，实际上只是照顾到了最基础的效能指标，却没有分团队类型、分业务阶段做动态调整，自然很难发挥出指标的牵引作用，原因就在于不够实事求是，对团队和业务的个性考虑不足。
全面构建综合性研发效能提升体系
结合第二章各小节的分析结论，我们可以形成一个综合性的研发效能提升体系。
研发效能建设的内涵
研发效能建设是过程管理、结果衡量、效果评估的综合体系建设，整个体系除了研发自身的成本、效率、质量问题之外，还涉及到全业务价值链路、研发组织管理、多业务角色团队协同等大的综合维度。在整个研发效能建设过程中，各类型的研发效率提升工具的使用是基础，目标、指标体系系统是关键，业务洞察系统是核心。同时在研发效能建设过程中，要充分考虑到研发效能和业务生命周期的关系，和团队生命周期、团队规模的关系，在不同的阶段和不同团队规模的情况下，进行有针对性、有侧重点的提升，避免只做常规的效能建设。
研发效能建设的使命
研发效能建设的使命是提升研发过程的效率，降低研发过程的成本，确保研发过程执行的结果能够达到预期的目标，并且通过全业务环节的评估、反馈和调节来提升研发结果对业务发展的积极影响，提升业务结果的经济效益。
研发效能的指标体系
按照图2 研发过程的分层模型来看，研发效能建设也需要针对每个层次做针对性的提升，具体如下：
- 在实践过程这个层面，要做好最宏观的“过程的效率、过程的成本、结果的效益” 三个方面的考量，这个考量是宏观层面的，适用一切实践过程，自然也就是信息系统研发效能建设的宏观综合指标。如下图所示：
图7 实践过程的效能指标
- 在生产过程这个层面，要分别从“生产团队、生产过程、生产系统、生产结果评判”几个维度来感知生产过程的情况，例如团队人员是否具备从事生产活动的基本资格、生产过程是否有流程、有标准、生产系统的产能和先进性、生产结果的收益等等，形成如下图所示的生产过程效能指标：
图8 生产过程的效能指标
- 在信息化系统建设过程这个层面，从团队、业务、技术、技术产出几个维度来感知研发过程和结果的情况，例如研发团队成员技能和素质是否满足信息系统研发要求；业务需求是否合理，是否能够有合理的技术方案实现；技术方面系统和架构设计是否与业务特征匹配等等，具体如下图所示：
图9 信息系统研发过程的效能指标
- 在业务系统研发过程这个层面，维度相同，但是侧重点已经和信息化系统建设存在一定的差异，特别是技术方面的要求，会具体到是否能支撑业务发展，是否能保障业务发展，是否能驱动业务发展，其他维度不再展开讨论，具体如下图所示：
图10 业务系统研发过程的效能指标
- 在成熟业务的研发过程中，业务阶段特征非常明显，对研发团队、研发工作的要求也和业务特征息息相关，总体而言是 业务上“求稳、求变、求生”，团队梯队配置上也是“梯队求稳”、“稳中求变”、“变中求生”，而研发工作上也是“求稳”、“求新”、“求沉淀”，具体如下图所示：
图11 成熟业务系统研发过程的效能指标
- 在具体的自己负责的业务研发过程中，则需要结合当前的团队、业务阶段等特征，来确定指标了，这里就不给出具体的信息了，读者可以根据自己团队的实际情况，从团队、业务、技术、产出结果评价四个维度分别构建出你自己业务的效能指标。
结合研发过程的分层模型，分别把不同层面涉及到效能的指标分析清楚，这样就完成了整个研发效能的指标体系的梳理，结合上一篇文章《技术一号位的方法论【业务篇】——如何设定业务目标》我们可以知道，指标体系的使命是让我们感知到做的事情目前实际情况是怎么样的，让我们能够通过可感知的指标来发现目前事物发展过程中存在的问题。
同时大家可以发现，“研发需求交付数量”在众多指标中只是很不起眼的一个，几乎难以发现。可实际工作中，很多团队喜欢看这个指标，我们抛开传统软件公司不谈，以大家对互联网大厂的了解（不论是亲身经历还是有所耳闻），会有研发团队的工作量是不饱和的吗？作为管理者要思考，是不是存在一种可能性，既在团队现有“需求交付数量”的基线上有所提升，所有人的工作量又有所降低，整体工作负担同时有所下降呢？顶层决策者们想要提升整个团队的产出，下面的管理者们就会要求团队加班，这个对策简单、直接、粗暴、最重要的是见效快，见效快意味着好用而无心理负担，所以顶层老板不细看真的会觉得这个 Leader 执行力强，可是长期来看，却是在饮鸩止渴，这就要求顶层决策者们多些思考，在执行的引导上多些智慧，使用合理的指标、恰当的方式来促进团队产出的提升。
不同阶段研发效能的考核目标
指标体系建立以后，我们可以通过指标体系的反馈来看到当前的研发过程中存在哪些问题，能通过各种现象来分析背后的问题是什么，从而确定近期的主要矛盾次要矛盾，于是就得出了当前研发效能建设的短期目标；宏观层面的指标需要经过较长时间的持续努力和改进，因此我们也能从指标体系里面可以得到中长期的目标，于是可以得出整个研发效能建设的目标体系。阶段性的目标和指标体系的对应关系如下图所示。需要注意的是，该示意图只展示了普遍的、普适的情况，没有画出特殊情况，因为特殊情况千变万化：比如有的团队就是把“成本下降”当做短期目标，想要在短期内看到成效，这种情况就是根据其团队的实际情况得出的特殊情况，看起来是和下图的关系不相符的。但是事实上从更大的更宏观的尺度来看，成本降低是一个全生命周期的长期的事情，近期成本压下去了就不做长期的治理，那么成本问题依然会在某个阶段跳出来需要“再治理一次”，所以最终来看还是符合下图所示的对应关系的：
图12 阶段性目标与指标体系的对应关系
实践案例介绍
背景情况介绍
4.1.1 业务方面
- 现状
- 成熟电商平台业务，核心业务模式已经趋于稳定，受客户群体特征和规模限制，已经进入平台期
- 业务领域复杂，多达 8 个核心域，分别为商品域、管控域、交易域、订单域、支付域、优惠域、结算域、商业化域，也包括 8+支撑业务域，如权限域、合同域、租户域、用户域、积分域、互动任务域、流量变现、风控等
- 为了避免可预料到的业务规模见顶带来的业务目标增长停滞，需要尝试新的业务模式带来增量，整体提升业务规模。
- 特征
- 业务模式为 B2B2C，即服务企业客户，同时服务企业客户的 C 端用户。
- 现有业务模式进入成熟期
- 成熟业务模式存在数以百计的企业客户
- 需要探索新的业务模式和客户群体，寻找业务增量
- 面对的挑战
- 需要保障成熟业务模式稳定发展
- 需要探索新的业务模式
4.1.2 技术方面
- 现状
- 分布式技术体系+复杂业务数字化
- 经过 4 年的建设，技术系统众多，除了业务领域对应的微服务之外，还有众多的“业务中间件”，包括事件服务、mock 系统、分布式锁、元数据服务、异步任务服务、文件服务、网关服务、业务配置服务等等
- 特征
- 受业务特征的影响，技术体系特征也划分为 ToB 和 ToC 两类
- ToB 业务模式下，多租户、基于标准业务能力的定制化、复杂业务建模是主要的技术命题
- ToC 业务模式下，大流量、高并发、高可用、跨业务方的数据一致性、分布式业务系统的最终一致性等是主要的技术命题
- 高度复杂、流量巨大、业务数据体量巨大的情况下，整体系统的正确性、稳定性提升、成本控制、效率提升
- 面临的挑战
- 架构设计的演进和分布式技术体系的落地
- 分布式技术系统的稳定性建设
- 技术领域和业务领域建设的相互促进
- 受业务形态影响，技术团队承载着对外技术服务的职责
4.1.3 团队方面
- 现状
- 技术团队：12 服务端（1 主管 + 3 正式员工 + 8 外包员工）+ 2 数据 + 3 测试 + 3 前端
- 团队属于综合型团队，承载着：业务需求、研发效能、运营效能、客户技术服务、稳定性建设等几大板块的工作内容。
- 特征
- 团队规模小，业务领域众多，日常工作版块众多
- 综合型技术团队
- 面临的挑战
- 小微型团队支撑大型业务，单迭代需求多，临时紧急性任务多，人为因素引起的研发交付过程管理困难
- 团队梯队亟需优化补充
- 团队涉及的工作板块多，人员日常工作负载较高
整体总结下来，以团队的视角来看，挑战主要集中在如何以小微型团队支撑大型业务，在成熟型业务日常迭代的过程中，还需要服务客户、保障系统稳定、同时需要提升研发、业务运营的工作效能，同时还要肩负着重要的业务模式探索的任务，充分体现了既要又要还要。同时因为团队组成复杂，人员培养也是重中之重，在这种情况下，作为团队 Leader，应该如何提升研发效能？
效能建设原则确定
根据 2.7 小节内容可以知道，小型研发团队的研发效能侧重点不在于需求交付数量，而是在于日常工作效率和质量方面。因此在大团队的效能指标的基础之上（代码量、单测覆盖率），我们结合自己团队的情况，确认团队的研发效能建设围绕着 “保业务需求，提工作效率，降工作负担，数字化清晰化精细化”展开，具体而言：
- 实事求是地解决团队效能问题，既不是简单地使用某个工具某套系统就觉得万事大吉，也不是简单地考核诸如代码量、需求量、需求交付周期等片面的单一维度的指标。
- 业务需求的完成和交付是团队工作的第一优先级，所有的效能建设都围绕保障业务输出来进行，确保小型团队日常工作对业务仍然具有推动能力，而不是让生产力被巨大的业务规模、复杂的业务模式、众多的客户服务工作消耗在巨量的琐碎的事务中。
- 向过程要质量，而不是向结果要质量。这一个原则，针对的是团队日常交付物的质量保障和整个技术体系的稳定保障工作而言的。在团队成员水平参差不齐的情况下，如何确保产出物的质量稳定地处于较高水平的质量基线之上，只有提升过程管理才能达到要求，而在结果上设置再多的卡点，都没有太好的效果，因为结果的卡点是最后一环，单纯追求结果卡点指标不能解决问题，因此需要以过程指标来牵引日常工作，从而确保结果卡点指标的达成。同时由于现有团队规模明显无法按照普通的方式保障大型分布式技术系统的稳定性。一些大型的百人级别的业务团队可以有一定的资源余量来专门做横向的稳定性建设工作，专门去做应急保障，故障出现了做应急、做止血、做恢复、做复盘，小型团队不能学习大型团队的“最佳实践”，只能别开生路、创造性地使用不同的方式完成稳定性的建设工作。
- 工作流程的健全和充分执行，是现阶段团队研发效能建设的主要矛盾。很多小型团队因为人少、事多，因此为了追求“所谓的快”而没有工作协作流程，或者有了流程也打着“敏捷”、“高效”的幌子跳过流程的一些环节，对已经经过实践检验的流程不做充分执行。还有一些团队依靠行政命令所有人严格执行各种流程，但是却对流程每个环节的产出物不设标准、不做检查，这样也只能积累一些流程执行数据而无法真正地解决过程管理要解决的问题。我们的思路不是砍掉流程、或者跳过流程的环节，而是降低研发同学执行流程的成本。让大家花费更低的成本把流程跑完，在自己负责的环节产出符合标准的产出物传递到协作下游，通过流程完成各项工作中和其他角色的高质量协作，让大家既能享受到流程带来的好处，也能节省出更多的时间。所以效能建设的重点就是健全工作协作流程，完善标准定义，降低所有人为了执行流程而投入的精力和成本，其中最后一点也是重中之重，是确保流程可以被所有人接受的前提条件。
- 所有的效能建设都要基于数字化的方式来完成，让所有人既能看得见研发团队的整体负载情况，也能看到各个角色的研发人员日常工作版块，每个版块投入的精力情况，最终能够针对不同的角色和群体进行针对性地效能提升，同时也方便决策者们基于团队当前的负载做出合理的决策，数字化让研发效能建设从简单指标考核过渡到精细化过程管理、体系化地结果评估成为可能。
在这 5 个原则的指引和约束之下，几年以来我们分阶段进行了一系列的效能提升工作，具体见后续章节。
效能建设实践过程
4.3.1 研发日常工作版块梳理
研发效能的第一个阶段始于3年前，在《技术一号位的方法论【业务篇】——如何画业务大图》一文中我提到过当时团队面临的一些情况以及通过业务大图如何做了组织关系的设计和调整，其他方面的具体细节本文不再重复，只讲一下研发效能方面做的一些事情。
- 划分业务领域和版块，让所有人，包括协作的上下游产品团队、运营团队都从过去杂乱的认知演变为 “产品功能——业务领域——工作版块”体系，并且根据团队成员的个人特征、主观意愿、未来期望划分人员与工作版块的对应关系，在研发团队内部形成版块 Owner 的角色。
- 分析各个工作板块中的关系，以 “C 端核心业务链路” 和 “B 端管控链路” 为两大核心板块，以“稳定性建设、研发效能、运营效能建设” 为横向底层支撑性板块，以 “业务生态建设” 为未来发展布局版块 组合成了目前的工作版块，整个体系已经稳定存在了 3 年，支撑了业务各个发展阶段的需求，到目前来看也不需要做大的调整。
- 客户技术服务工作内容多、杂、要求高、易被投诉，当时占用大量的研发资源，非常明显地威胁到了业务需求的交付，在无法扩张团队规模的情况下，把技术服务体系暂时归拢到 “稳定性建设、研发效能、运营效能建设”版块中，构建了多级技术服务体系，分别是 “机器人+知识库”作为第一级， “稳定性建设、研发效能、运营效能建设”版块的外包同学作为技术服务的第二级，该板块的 Owner 作为技术服务的第三级，各个业务领域的一线研发同学作为最后一级。
在研发效能第一阶段的建设完成之后，基本上形成了一个比较好的局面，整个技术团队的工作效能在“需求的承接和交付数量”方面，较过去有明显的提升，同时过去一直遗漏的客户服务方面也有了体系化的支持工作，成为了综合性研发团队的重要工作版块。
4.3.2 研发日常工作流程梳理
随着业务的持续发展，从最开始的启动期到后面逐步规模化起量期，业务需求也从追求数量变成追求质量。在进入这个业务阶段之后，过去的大量的成块的产品功能不再是研发工作内容的主体，变成了大量的分散的业务需求，在既有功能上适配新的业务场景、在旧的技术架构上适配新的业务需求成了主要内容。因此在代码量上会呈现出非常明显的下降的趋势，而技术方案文档、技术自测报告随着需求变多也呈现出了上升的趋势，一线研发同学在这个阶段工作内容和重点也发生了变化。随着迭代发布的增多，产品功能日趋复杂，在技术团队规模不变甚至小部分萎缩的情况下，需求交付数量提升意味着需求交付质量在不做干预的情况下必然下降。这也是研发效能建设进入第二阶段以后呈现出的特征和重点建设维度。
我们在业务起步期间也有各种各样的研发流程，但是存在这样的问题：
- 研发流程覆盖面非常窄，只涵盖了需求研发的生命周期，而且这个涵盖面比较窄的流程也完全是以 CI/CD 系统为主导的，就是简单的 “写代码、做部署、做测试、做发布、做验证”。
- 大量的日常工作没有协作流程，更不用提协作流程的关键环节的识别和标准的定制
- 后续根据实际情况补充了一些流程，但是流程本身停留在文档和宣贯层面，执行过程依靠相关人员人肉记忆和维护，流程执行不充分，并且新增的流程让团队成员觉得效率变低，投入在非研发工作方面的精力变大，存在一定的抵触情绪，流程的执行依靠一线成员的自觉和管理者的抽查。
在团队出现了“非技术系统 BUG 而是人员本职工作执行不到位引起线上故障的黑天鹅事件”之后，所有的矛盾终于集中爆发，大家经过复盘第一次改变了自己的视角，从一线执行者的视角转变为管理者视角，看到了流程的重要性和必要性。后面作为团队 Lleader，我个人也有所反思，过去的流程都只停留在了文档中，就觉得团队已经有流程了，经过此次也感受到了从决策到执行其实存在着巨大的鸿沟，而这个鸿沟只能先由管理者做出努力想办法填平，才可能顺利地完成决策和执行的过度。因此后面把团队是否有工作流程的标准设定为：
- 是否有工作流程的说明文档，讲清楚流程参与的角色有哪些，不同的角色参与哪些环节，不同流程环节产出物的标准是什么。
- 团队成员是否都知道这个流程的全部信息，如果有一个人不知道这个流程的全貌，就说明流程约等于没有。
- 这个流程要用公司的工作流引擎驱动，不同人在不同阶段在线参与流程的推进和停退工作，如果上游的产物符合标准，则依靠上游输入完成本环节的工作，形成标准产出物，反馈到在线的流程中，最后推进流程向下一个环节流转。每个环节的流转都有即时通信工具（本团队为钉钉）提示到相关人员，既包括执行人，也包括关心流程进展的管理者。
随后把涉及到研发过程（网上各种文章都有，不再细聊）的几个核心流程在线化，避免有人因为忘记而导致关键流程环节被跳过。这些流程包括：
- 产品需求开发流程
- 产品需求提测流程
- 产品需求发布流程
- 系统保障应急流程
每个流程存在很多的环节，都是用宜搭的流程设计器完成搭建和后续的运转。从整个流程从上线到目前为止，已经分别有 100+流程完成流转，下一个阶段的效能建设，就是基于这些流程在运转过程中产生的各种时间数据、状态变化数据形成团队的效能基线，从而能让管理者发现各个指标的变化情况，确定问题根因，进行针对性的改进。
4.3.3 研发日常工作任务数字化
除了工作流程补充和流程的在线化之外，过去使用 AONE 来记录业务需求和各种 BUG，整体记录还是围绕着业务需求来做的，而当前的业务阶段对技术团队的要求已经发生了变化，并且实际工作版块中，业务需求研发的比例呈现一定的下降趋势，客户技术服务、稳定性问题的 解决、业务合规、数据安全、风控、技术方案设计等板块工作量提升明显，过去的工作模式和管控方法已经不能适应这一变化，除了过去管理比较好的业务需求之外，在各种事情的信息的同步、对焦、决策、跟进、解决执行方面都处于比较混乱的状态，严重影响到了整个团队的研发效能。因此在今年下半年开始构建整个团队的综合工作版块大图，使用 teambition 工具记录、跟进研发团队承载的所有各种任务，完成任务的信息化。具体的研发任务大类有：业务需求开发、业务风险、渠道客户对接、客户技术服务工单、协同任务、应急任务等。利用 teambiton 的统计功能，设定各类型任务的周、月报表，可以看到每日的任务延期情况，看到每日的业务风险增量。同时还利用“迭代”功能版块进行过去的业务需求的管理，同时将同一时期的各种其他类型的研发任务都囊括在迭代中，解决过去迭代内容不清晰，研发人员打黑工还要背锅的问题，彻底看到整个小微型团队的整体负载情况。也利用“甘特图”版块进行整个迭代中各个任务的项目管理工作，让工作进度看得见。同时 teambition 新出的“资源管理”功能，能够把团队所有人员每天的工作负载情况非常直观地展示出来，能看到某个人某一天需要完成的任务的并发情况，让研发人员彻底告别做了事情却不被知道，每天并发做几件事情的同时还需要继续接紧急需求的问题，也让业务各方看到单个人的工作负载，从而更好更合理地设定任务的优先级。总之，整个团队从 9 月份开始整体工作进入了信息时代，利用各种指标和与之对应的工作流开展研发工作数字化的实践。
以业务风险为例，整个业务风险大类下面包括了“业务发展风险”、“客户投诉风险”、“数据安全风险”、“业务合规风险”、“研发进度风险”、“系统稳定性风险”这些子类，每天研发团队的“15 分钟项目管理日会” 通过沟通对焦获得各个小组和版块和业务领域的各种风险问题，同时也能知道目前正在进行的工作的进展怎么样，是不是有新的紧急的事情要插队支持，于是很容易就能根据甘特图看到被紧急任务波及的相关同学是否还有余量承接需求，该研发人员是否并发度过高，是否需要根据任务的优先级调整其他任务的计划。一线研发同学不再需要在每个迭代复盘时解释为什么某个事情有延迟，系统内的记录一目了然，这样一来也可以让管理者在优化过程管理时，更精准地定位某个迭代中真正导致延期的事情和原因。
再以企业客户技术服务工单类的任务为例，我们构建了不同类型的客户技术服务的流程，针对普通客户和核心大客户提供不同的服务 SLA，在有限的人力下，分别在工单响应速度、工单结单速度、工单各级渗透率（从 L1 渗透到 L2，从 L2 渗透到 L3，从 L3 渗透到 L4）等方面都设定了不同的标准，来满足不同客户的要求。同时利用工单日会复盘流程，将客户工单中提到的到问题转为产品功能需求、技术系统 BUG、技术效率工具建设的源动力，通过客户侧的声音和反馈来驱动整个业务、具体的产品、以及研发团队自身的成长。通过任务系统完成了工单处理的基本的信息化工作，后续配合相关的指标体系来继续指引团队的数字化实践。
最终，团队整体也多加了三个大的流程，
- “15 分钟项目管理日会——团队周会”流程，主要感知风险、感知研发进度、调整任务计划和安排；
- 客户服务流程，包括工单处理子流程、工单日会复盘流程、工单转需求流程、工单转风险流程；
- 团队内部运营、建设流程，主要是在其他流程的驱动和产出物的基础上不断完成团队日常工作运转，补充团队技术能力和业务能力
这几个流程围绕着 4 个核心研发工作流程，共同覆盖了研发团队日常工作的各个板块，使大的协作必有流程，流程关键环节必有产出标准，整体控制研发日常工作过程质量。因为数据安全的关系，这里只给出整体的项目截图，不再给出具体的一些指标和图表细节，如下图：
图13 Linkedmall 团队研发任务项目管理
图中顶部菜单可以看到以上文字中提到的几个重要的信息化工具，迭代、甘特图、统计、资源管理、研发效能流程（宜搭流程让日常工作流程线上化）。由此也可以看出，研发团队效能提升需要多种多样的工具支持，是综合的、复杂的，不是单一工具就能解决的。
4.3.4 研发效能目标体系建设
参考 3.3 研发效能的指标体系 一节中的内容可知，整个研发效能指标体系内容较多较复杂，这里不再重复。在有了指标体系的基础之上，我们可以结合目前团队、业务的实际情况构建团队研发效能建设的短期目标——随着实践的不断深入，团队在极为有限的人力的情况下，选择当下最影响效能的几个方面作为短期（一个财年）阶段性的目标（更加细粒度到具体事项和时间线的目标拆解内容就不再详细展示了，请勿认为目标不符合 SMART 原则）：
1. 短期目标
- 团队方面
- 提升一线研发同学的综合能力，使全员具备复杂业务系统建模及架构设计能力，在现有业务复杂度和技术命题的场景下能够独挡一面。
- 降低团队成员在日常工作中非业务研发工作投入的精力，降低团队协作成本。
- 技术方面
- 持续通过过程管理保障业务需求交付质量和数量，确保交付能力在基线之上
- 持续通过效率工具体系的建设降低各角色员工日常工作成本，提升单人和协作工作效率
- 业务方面
- 逐步构建业务指标体系，让研发工作结果有标准可衡量。
- 逐步尝试业务落地过程数字化实践，进行业务洞察体系的早期建设
2. 中长期（2-3 年）的效能建设目标如下：
- 团队方面
- 在有条件的情况下扩大团队规模。目标解释说明：团队效能工作做得再好，在对团队需求承载能力和交付数量、质量方面，可能不如增加几个人见效更快。但是需要注意的是，加人只在研发效能的某些维度会有很好的效果，但是加人解决不了信息传递不畅的问题，更解决不了决策存在缺陷偏差的问题，所以加人虽然见效快，但是仍然是简单粗暴的，在精细化过程管理方面该做的功课还是得做。
- 构建合理的团队梯队，将整个效能建设做到体系化地传承和传递，确保效能方面的认知始终上下一致。
- 通过合理的方式方法把科学的效能提升方法传递到上下游的协作团队，统一各方认知，形成步调一致的实践行为，在对研发效能形成组织保障的同时，力争对业务效能建设产生积极影响。
- 技术方面
- 对常见的研发效能指标形成准确的、自动化的衡量工具，或使用已有的效能产品工具完成研发常见效能指标的跟踪
- 构建适用于业务研发团队的效率工具体系，确保易扩展、易复用
- 结合团队目前的技术体系特征，构建对应的技术系统和工具解决稳定性、日常发布运维过程中存在的效率问题，持续实践业务落地过程数字化，构建相关技术能力。
- 业务方面
- 利用既有的实践基础，构建覆盖面广、复用性强的指标体系系统
- 在业务落地过程数字化实践方面总结经验理论，进行业务洞察体系的中长期建设
3. 效能建设的终局目标
- 利用已有的效能产品结合部分自建的工具系统，构成横跨整个研发生命周期、覆盖研发日常工作各个板块的过程管理体系和系统，并且形成与之配套的工作流和方法论，建立与之对应的准确地、无干扰的、能反馈团队效能真实情况的指标体系。
- 完成构建通用的业务洞察系统，通过工具系统、方法论来提升整体做业务的效能，降低决策成本，提升决策正确率，以科学的系统和体系保障业务发展。
4.3.5 研发产出效果度量体系建设
研发产出效果度量体系建设是一个更加长期的建设，需要的是一个业务洞察系统，能够从完整的业务维度完成研发工作、运营工作、产品工作、商务工作等对业务发展的影响和评估，这里就不再继续展开了。
实践案例总结
从团队现状背景信息，到研发效能建设原则的确定，再到阶段性地研发效能建设实践，抛开以往的各种最佳实践和宣传，就实事求是地基于现状、结合指标体系进行针对性的提升，并且明确短期建设、长期建设分别要达到什么样的目标，这样才能真正地、全面地解决团队的研发效能问题。基于理论指导实践，再基于实践总结并完善理论，并且逐步将复杂深奥的理论简化以后形成大多数人可以理解的、易于执行的方法论，就完成了从实践到理论再到实践的过程。接下来就带着大家一起看下经过简化的方法论是什么样的。
研发效能到底应该怎么做
我们常常看到很多团队的研发效能建设会集中在代码量、需求交付量、需求交付时间上，可是读者朋友们需要关注的是当前您所在的团队的背景是否和那些常见的“最佳实践”类似，如果类似的话，直接参考去做没有任何问题，但是需要考虑的是：如果按照网上最佳实践的方式做了一些调整，后面“感觉”还是觉得效能有问题，那个时候该怎么办呢？所以大家需要再回过头，看一下毛主席的实践论中写到的实践和理论的辩证关系，“最佳实践” 只能是在一定条件下的、不全面的 “实践”，虽然是最佳的，但是还是实践的范畴；而理论是通过感性到理性、片面到全面的指导性的，来源于实践但是超脱于实践的，因此大家在花费力气实践别人的最佳实践的时候，也别忘了提升理论，从最基础最核心的本质来看研发效能究竟是什么，应该怎么提升，这样有了理论的加持、有了某些场景的最佳实践的指引，才能让您的团队真正在效能方面有提升。同时也要注意的是，谈论研发效能的提升，不能只谈论研发或技术，这样得出的结论是就是局部的，不是适用于整体的，而应该也谈论组织、业务，这样才是全面的，才是一个团队在研发效能领域面对的真实的情况。本文作者也给大家提供一些简单的容易实操的方法，能够让所有人都知道什么是效能的提升，如何提升个人的效能，如何提升团队的效能。
从最抽象的层面看工作的本质
我们每天在公司工作的内容，综合下来就是以下几个流的不断交互和轮转：
- 信息流，从信息的产生方，通过某种形式被感知，再被传递，到达依赖这些信息做决策的节点，这个节点可能是某个人，也可能是某几个人，也可能是某个团队，整个信息的传递过程中也存在着二次加工，传递的信息与原始信息相比可能附加了新的决策后的信息，或被覆盖也可能。
- 决策流，在某个层面的决策者拿到信息后，进行分析、决策，形成新的信息，这些信息有的会继续传递下去，有的转为执行的指令，触发执行流。
- 执行流，就是在和决策者对齐决策信息后，开始进行实际执行的过程，包括了确定目标、明确策略、具体执行、反馈上报调整、最终完成执行这样一系列的环节。
- 价值流，就是一个或多个业务中，各种各样的执行流所得的结果，汇聚成整体的对他人、客户的价值流，沿着价值链传递，完成价值创造和获利的整个链条的循环。
- 利益流，就是在整个价值创建和变现周期内，参与价值创造与变现的各方所获得的利益的过程，利益分配的形态，构成了整个利益流。这个链条是最隐蔽的，也是最重要的链条，很多局面的形成和破解，往往最终都会聚焦在利益流上面。在建设优质、积极的价值链条时，要关注利益流的某个环节是否可能会影响、干扰甚至阻塞了整体价值链的运转；而在打破一些劣质、消极的价值链条时，则要关注利益流的某个环节是不是不当的、是所有问题产生的根源，从而进行针对性的改造，让劣质、消极的利益链条发展变化，转变为优质、积极的利益链条。利益流还有很多内容可谈，未来会在 《技术一号位的方法论——组织篇》中深入展开讨论。
这些承载着不同的载体、扮演着不同的角色的链条共同推进着工作内容的向前发展，效能问题就隐藏在某些链条当中，想要找出所有的效能问题，就得明白你的工作中存在哪些“流”、涉及到了哪些“流”，最终如何让他们彼此顺畅地相互配合，而不是相互阻塞。
分析你的工作信息流和决策流是什么样的，构建出整个团队的工作板块大图
以当前我所在的研发团队为例，如下图所示：
图14 研发团队工作板块大图（未标出价值流和利益流）
整个团队由“一线研发同学、领域 Owner、团队 Leader、大团队领导、协作方、协作方领导”构成了一个自下而上的“信息——决策”体系 和 自上而下的“决策——执行”体系，同时对 B 端客和稳定性收拢到一个团队，所以团队内部也存在着面向客户的协作流。
可以看到信息的来源有以下几种：客户、协作团队、团队内部、信息系统、横向团队，因此这些信息的流动和流向是不一样的，有些是一线研发同学第一感知的，有些是业务领域 Owner 首先感知的，有些是团队 Leader 首先感知的，这些不同的信息源发出的信息会沿着不同的协作流程完成“传递、分析处理、决策、执行”这样的路径。从这个图中可以非常清晰地看到一个团队的 Leader 是他负责的板块的信息汇聚点，扮演着信息上传下达的关键角色，同时也是很多决策执行的发起者和责任人。由此也可以看出，一个研发团队的 Leader 工作内容和职责，如果整个板块梳理不清、没有好的工作方法、没有流程来规范协同过程，那么基本上团队的 Leader 本人非常容易形成瓶颈。（题外话：从图中可以看到，团队 Leader 本身的职责范围和工作内容已经和一线研发人员的工作内容和职责有较大差异了，因此这个图中的各种角色的能力模型都是不一样的，不能对各个角色没有标准和要求，也不能对所有的角色使用同一套标准和要求，这两种情况都是不实事求是的）在整理出团队工作版块和信息流、决策流、执行流的大图之后，就可以结合团队的实际情况来看整个团队是不是缺乏必要的流程，关键流程是否有阻塞，流程环节是否没有产出物的标准导致协作成本高，最终哪里需要调整。
根据工作板块大图和各种“流”寻找让信息流转出现问题的点
根据上一小节画出的工作版块和业务流程图，开始结合具体的问题进行分析，分析是人的问题，则增加团队的培养，提升团队成员的认知，促进其实践行为的改善；如果是机制流程的问题，则建立健全机制流程，考虑到协作各方是谁，分别扮演什么角色，核心利益诉求是什么；以此类推，在信息维度关注信息的收集、存储、传递，在决策维度关注信息的感知、分析、决策过程是否存在问题；在执行维度关注 目标、策略、执行、阶段复盘调整、取得结果这些方面是否存在问题，在价值方面关注价值的营销、销售、交付、收款等方面是否存在问题；在利益方面要看收入、利润、利益分配是否合理等。
结合指标体系，针对性地做改进提升
在找到团队内影响效能的点之后，利用好各种各样的效能产品、效率工具，整体设计布局，基于指标体系感知实际情况，分阶段分目标进行调整实践，就能知道现在效能的基线是什么，经过实践以后哪些有提升，最终效能改进到什么程度，是否满足阶段性的效能建设目标，是否可以启动下一个阶段的效能改进实践，以此循环往复，完成高效的、综合性的团队的建设工作，保障业务发展，完成团队使命。
-文章内容未经授权禁止引用转载-
「」往期回顾
