百度研发效能从度量到数字化蜕变之路
作者 | 乌拉
导读
企业降本增效的诉求越发强烈，研发效能成为近来极为火爆的话题，本文从效能分析整体思路、实践案例、技术实现介绍了如何从效能度量逐步演变形成基于价值的数字化决策系统的过程，通过本文可以了解到：
1、研发效能的本质和数字化分析思路
2、以实际分析场景为例，了解如何通过数据构建问题分析模型，挖掘效能问题并驱动改进落地
3、搭建具备数字化智能诊断决策能力的数字化平台的技术实现方案
全文 9164 字，预计阅读时间 23 分钟。
01 前言
企业降本增效的诉求越发强烈，研发效能成为近来极为火爆的话题，效能数字化建设也成为很多公司度量效能现状，发现效能瓶颈的不二选择。关于研发效能度量百度已经深耕多年，从开始通过工程能力地图的形式驱动工程能力提升，到建立研发效能度量平台，通过在线化报表数据驱动各业务团队研发核心指标的提升。
△工程能力地图
△在线化度量报表
前期的效能分析基本分为两步开展：
定性分析：主要通过指标趋势分析等方式来了解效能变化情况，是提升了还是下降了，进而判断团队效能好坏。
定量分析：通过下钻、逻辑树、相关性分析等方式找到效能提升或者下降的原因，并根据原因制定改进措施。
可以看到，这样的效能分析模式是基于问题驱动的，从结果指标找到有异常的点，通过异常点驱动深入分析，找到改进点优化带来效能提升。这样的方式在数字化前期能够快速识别问题，驱动改进带来效果，随着结果数据逐步趋于稳定，就难以再持续推进研发效能的提升，且面临着以下几个问题：
过于以追求指标为目标达成容易导致数据失真和造成忽视研发效能的本质，容易走弯路；
问题驱动的方式往往聚焦于局部优化，比如数据指标关注测试质量，为了达成指标增加大量的测试环节，漏测率是变少了，但是测试周期大幅度提升，并没能达成全局最优；
未给出影响核心目标的关键行动，无法指导业务团队改进。
为了规避以上问题，效能数字化工作在思路上转向针对实际的业务场景进行数据分析模型的建立，并通过指标分析找出关键问题给出改进方案，避免陷于"数字游戏"。在新的形式下，数字化不仅要指出问题在哪里，还需要能指导应该改哪里，改完的预期效果怎么样观测，数字化技术层面从度量平台开始向诊断、归因、决策平台转变。如前所介绍，本文不再以围绕如何构建一套研发效能指标体系的思路进行介绍（如需了解百度的研发效能指标体系，可以留言后续我们逐渐登出），而将会介绍我们效能分析的整体思路、实践案例、技术实现，先理解研发效能的本质和数字化思路的前提下，重在用实际案例介绍如何剖析效能潜在的那些“瓶颈”，而非只是流程与工具，让大家了解我们是如何通过效能分析引导并驱动团队行为上的改变而不是仅仅数据上“好看”。
02 效能分析思路
主要思路是从研发效能的定义出发，**找到影响研发效能的关键因素，围绕关键因素孵化和设计场景，建立分析模型，**通过可控的过程改进，驱动效能长期持续的提升。
2.1 影响效能的关键因素
研发效能定义：“ 研发 效能 ”就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力。
研发效能 ：单位时间内研发团队完成的对业务有实际价值的需求的人均产出 ，即：一定时间内，需求吞吐 * 有价值的需求占比 * 价值 / 成本
从上述定义，可以提取出影响研发效能的三个核心因素：
做正确的（高价值的）事：我们的研发资源是否投入在了更有价值的需求上，核心是洞察高价值的需求以及资源投入与需求匹配情况。
正确的做事：通过采用更加合理的方式提升研发效率、质量，减少资源、时间浪费最终提升需求吞吐，降低成本。
可持续的顺畅交付：让交付过程顺畅、稳定、可持续，能够持续保障高的需求吞吐。
2.2 影响效能的关键场景
基于上面提到的影响研发效能的 3 个核心因素，我们采用 GQM 的方法进行分析，提取效能分析的指标体系以及关键场景。以下是部分场景提取示例：
2.3 从度量向诊断决策转化
有了明确的分析模型之后，我们就能通过指标情况来了解我们关注的问题结论，但是分析结论最终需要转化成能够驱动业务行动才能带来实际的收益，所以除了数字化分析能力还需要打造能够把分析结论有效分发，改进效果有效回收的能力。如下图所示，基于数字化分析模型，构建多渠道的分析结论应用闭环通路，协助数字化高效诊断以及决策落地，完成从度量向自动诊断决策服务的转化。
03 分析改进案例
下面通过实际案例来详细介绍，如何通过数据分析来了解某个问题场景，挖掘其中隐藏的问题，并对挖掘到的问题提出针对性的改进提案推动落地，从而促进目标达成。
PS：以下案例数据为虚构数据，仅作为分析思路讲解使用。
3.1 做正确的事-人效分析
3.1.1 分析目标
研发资源是否投入在了有价值的事情上，这是决定最终产出的核心因素。我们希望分析不同的岗位角色，人力是如何分配的，评估当前的人力资源分配是否合理，驱动资源分配优化配置，从而提升最终产出。
下面以业务测试人员为例分析。
3.1.2 分析思路
人效最终追求的是最优资源配置，所以我们要回答的问题是现有的需求量下，投入多少人员，如何分配能得到最大产出。基于该问题我们首先得定义，业务测试人员的投入和产出分别是什么。
参考制造业的 OLE 指标体系可以看到，最终的 OLE 涉及到三个层面的问题：
1、时间利用率：在这里相当于测试需求饱和度，可以用测试需求时长/理论上的总工时
2、生产效率：在这里相当于测试产出效率。在这里我们测试产出是 BUG，所以以发现 bug 的效率作为衡量指标。
3、质量合格率：在这里相当于项目质量，我们可以用漏测率来表示。
OLE = 时间利用率 * 生产效率 * （1- 漏测率）
基于以上公式，我们可以从人员的时间利用率、测试效率、测试质量三个方向来进行分析。
3.1.3 指标体系
基于上述分析，我们采用 GQM 方法分解出如下的业务测试人员人效分析指标体系：
下面是指标的详细说明：
3.1.4 分析实例
测试人效数据受到工程能力、业务代码复杂度、等因素影响。故业务差异较大的团队间不具备可对比性。以下实例以单个业务作为分析主体，不考虑工程能力视角因素对人效数据的影响。
结果面分析
首先我们通过结果面数据也就是直接影响 OLE 值的三大因素指标的趋势情况来了解当前现状，如下图所示：
饱和度：长期稳定在 30%左右，说明平均每天有将近 60%的人力处于不饱和状态，具备较大提升空间。
平均人天 BUG：1，2 月份受到过年前后假期影响，偏低，其他月份稳定在 0.8 上下。结合饱和度也较为平稳的数据可以判断，该业务需求的 bug 密度处于较稳定状态。
漏测率：呈现不稳定波动，和人员饱和度无相关性，说明人员负载目前没有对测试质量产生影响。
由于人员饱和度过高易导致漏测率的上升，可以长期观察以上三个指标帮助团队达到在可接受的漏测率标准下最大的饱和度和单位产出。
过程面分析
接下来我们通过过程面不同视角的分析，来挖掘核心问题是什么，需要改进的方案是什么（以下仅以需求和人员视角为例）
需求分配视角
需求根据修改风险大小，可以使用不同的质量保障手段。如低风险需求可以采用研发自测+CI 自动化手段保障质量。
需求分配视角主要回答以下两个问题：
测试任务是否采用了最低成本的的测试手段来完成质量保障工作。
通过对比最终上线后没有 bug 的需求占比，和实际需求采用的测试方案可以看到，我们只有大概 20%是实际有 bug 的，但是采用研发自测方式保障的需求仅占比 50-60%。说明我们有大量的测试人力消耗在无 BUG 需求上。
△无 bug 需求占比
需要分配到测试人员的测试任务分配是否均衡，是否有闲置人员和闲置时间。
通过饱和度在时间维度和人员维度上的分配分布，可以看到在时间维度上，存在明显的忙时和闲时，人员维度上存在明显的不均衡情况，且存在 0 饱和度成员。
△时间维度饱和度分布
△人员维度饱和度分布（横轴代表饱和度百分比）
人员能力视角
人员能力视角主要回答以下问题：
是否存在能力不足成员
通过人员粒度的交付需求量以及漏测率的散点图数据可以看到，存在产出少且产出质量差的成员。
△人员交付 &漏出情况
改进方案挖掘
基于以上过程面分析，可以看到在需求分配、人员能力层面都有明显的问题，针对某一个具体的问题指标我们需要挖掘具体的改进方案并驱动落地，下面我们以需求分配维度的时间均衡度问题为例进行详细分析拆解。
关联分析
观察人员饱和度分布可以看到，忙时周期和发版周期一致，说明发版周由于存在批量提测导致人员饱和度提升。为了能够在发版周保障按时交付，业务需要保障有充足的测试人员可用。
△时间维度饱和度分布
解决时间维度分配不均衡问题我们需要做到在忙时能够有充分的人力资源可用，在闲时能够释放人力资源。由于人员不可能快速增加或减少，所以我们希望看下是否可以通过在更大的团队范围内进行资源共享来达成以上目的。分析不同业务的需求饱和度周期分布如下：可以发现不同团队间的忙闲时段是有差异的，如下图 A 团队在周三最忙而 B 团队是在周五，说明以上提议可行。所以针对需求分配的时间均衡度问题提出改进方案:通过建立多团队间的测试人员池化机制，提升整体饱和度。
△A 团队时间维度饱和度分布
△B 团队时间维度饱和度分布
3.2 正确的做事 - CR 过程分析
3.2.1 分析目标
CR（CodeReview）是代码指标保障中的重要一环，也是研发日常工作中的一个重要组成部分，我们希望通过对于 CR 过程和 CR 投入产出的情况进行分析，评估当前 CR 工作的投入产出情况，驱动 CR 工作过程改进带来质量和效率的提升。
3.2.2 分析思路
由于评审对后续质量效率的数据相关性，一是很难立刻获取到，二是获取到后是否有正相关性不可控，受其它因素影响很多，所以暂时不以 CR 对于质效结果指标的影响为分析重点，而是假设 CR 工作以及良好的 CR 习惯，可以提升项目质量效率，那么我们可以通过引领团队提升 CR 参与度，规避不好的实践，落地好的实践来改进 CR 过程提升 CR 产出。
所以在结果面上，我们追求的是 CR 的投入产出比，在过程面上我们首先需要提升 CR 的投入度，其次需要关注 CR 执行过程，识别好的实践和不好的实践。调研业内好的 CR 时间原则，我们总结了几个核心要素：
CR 评审需要快速响应，避免由于 CR 导致流程阻塞，一般应当在一个工作日内完成
挑选能对你代码做出最全面最准确评价的人为评审者，保障评审质量
避免单次提交过多代码，尽可能小的，增量的，实现一个完整功能的提
3.2.3 指标体系
基于上述分析，我们采用 GQM 方法分解出如下的 CR 分析指标体系：
下面是部分指标的详细说明
3.2.4 分析实例
通常指标数据需要有对比基准，和业界或者和自己历史情况对比才好判断优劣，但是这个案例是首次分析不是看趋势所以没有历史数据对比，相关指标业界也没有对应的数据披露，所以这里没有采用基线对照的方式评估。
结果面分析
首先我们通过结果面指标情况，来了解 CR 现状，判断是否需要改进以及哪些团队需要重点改进，如下图所示可以看到如下结论：
70%的团队有效评审数较小，且这 70%的团队内有大量团队平均 CR 耗时超过较高，存在高投入低产出现象，需要改进。
当前单有效评论成本和有效 CR 率呈现一定的负相关性。
过程面分析
接下来我们通过四个角度的过程面分析，来挖掘核心问题是什么，需要改进的方案是什么。
△评审过程规范情况
首先从评审提交和评审过程规范情况来分析，可以看到上面两张图所示数据：
提交角度：单次提交大于 400 行的占比占比 12%，这部分提交不利于评审人员快速评审发现问题
评审过程：
秒过率在 16%以上且有上扬趋势，说明存在大量"走过场"的 CR，仅仅为了代码合入操作评审通过，并未实际评审。这种情况完全没有产出，而且消耗的一定的流程成本
自评率维持在 5%左右，虽然占比不高，但是这类 CR 和秒过类似，都是为了代码合入而走的流程，需要优化
24 小时以上完成率 8%左右，无明显问题
△人员分配是否合理
接着从人员分配角度来看是否合理：
参与度：从参与度上看保持在 40%左右，说明有大量的研发同学是没有参与到 CR 工作，这不利于技术讨论氛围的建立和知识交流，需要提升。
饱和度：饱和度长期处于 10-15%之间，说明 CR 工作当前对于大家来说不是一个高频工作，不会造成太大负担。
职级分布：从职级分布来看，大量的 CR 是由中级工程师来完成的，高级工程师作为经验丰富能够给出更多有效建议的团体人均评审量较低，可以结合项目重要度合理分配更多 CR 任务。
改进方案挖掘
基于以上过程面分析，可以看到在评审提交、执行以及人员分配视角我们都有需要提升和改进的指标，那针对某一个具体的指标改进如何挖掘具体的改进方案并驱动落地呢？下面我们以秒过率为例进行详细分析拆解。
下钻分析
为了进一步发现问题，我们可以针对指标进行下钻分析，如下图：
△按照部门维度下钻
△按照人员维度下钻（右）
从部门维度下钻看秒过率数据，可以看到 部门 1、部门 6、部门 8 三个部门的秒过率大于 20%，是所有部门内最高的，可以将这个对比数据通过分析报告的形式推送给对应部门负责人进行改进。部门维度可以进一步下钻到人员维度，给部门负责人提供秒过率异常高的人员信息，作为改进的抓手推进具体的优化。
关联分析
除了从不同维度下钻找到足够细粒度的，可执行层面的优化点，还可以通过关联分析的方式分析目标指标受到哪些因素的影响，通过关联因素分析来制定更合理的优化方案细则。
△与职级关联
从职级关联度数据可以看出，随着职级的提升，秒过率越低，大量秒过发生在低级别人员互评场景，所以我们可以从评审分配优化以及制定 CR 实践规范并向低级别人员宣贯的方式提升执行规范度。
从秒过率和代码变更行量的关联数据分析，并未出现代码行越多秒过率越低的情况（如果都是认真评审的话，改动越大花费时间越长越不会秒过），说明当前的很多秒过评审确实是无脑过单，并不是代码改动小评审速度快。
针对不同异常现象详细数据进行细化分析原因，根据原因分类分别制定优化方案。举例如下：
代码更改量大但是秒过
未查看代码就直接过单：可以通过在 CR 工具链上增加友情提示以及快捷评审标记的方式，在降低 CR 成本的同时及时提醒大家遵守规范，降低此类走过场行为。
配置改动/微小改动不需要细看：提升 CR 提交自动化扫描能力，针对变更能自动识别变更类型和风险程度，对于低风险 CR 可自动通过无需人工介入，降低 CR 成本。
针对过程面分析中提到的各个需要优化的指标，采用上述下钻分析、关联分析、相关性分析等方式，就可以得出不同指标不合理的原因、进而找到应该由谁来执行改进，以及具体的改进内容，从而切实的驱动执行落地。
3.3 可持续的顺畅交付 - 流程瓶颈分析
3.3.1 分析目标
通过业务流程全局视角，观察并分析研发测试周期各环节存在的瓶颈点和根因，驱动瓶颈优化带来整体效率的提升。
3.3.2 分析思路
考虑到服务端和 APP 端的交付流程存在差异，分两个业务类型切分不同的流程阶段来分析。
首先通过全流程阶段透视的方式，挖掘流程中的明显瓶颈点。瓶颈指在整个项目流程中制约产出的各种因素，一旦出现瓶颈，从阶段数据上有以下两种现象，在评估初期，可以重点关注等待耗时。
存在较长等待周期
某个阶段耗时过长
“等待”贯穿于整个需求交付周期里，以明线（绿色）和暗线（灰色）为两种方式存在，如下图，可通过统计各阶段耗时分布进行瓶颈识别：
明线：具有明确的时间起止点，可被明确度量，通常原因往往是人力层面的问题。
暗线：暂无明确的时间起止点，原因复杂。
针对第一步找出的明显瓶颈点，进行归因分析，驱动实际落地改进
3.3.3 指标体系
下面是部分指标的详细说明：
上图部分指标是复合计算指标，如需求复杂度、自动化能力等，基于多个基础指标计算，可进一步细化挖掘，此处未一一罗列。由于各维度指标过多，上图主要体现分析的 5 大维度，并未列全指标。
3.3.4 分析实例
结果面分析
首先通过等待耗时占比和各阶段耗时占比来了解现状，找到 top 的等待耗时环节：
等待耗时占比：在 20%左右波动，近期占比有所回落，有较大优化空间。
各环节等待/耗时占比：可以看到等待耗时集中在集成等待、测试等待、上车等待三个阶段。
过程面分析
接下来我们从上面列出的影响维度来分析，对于测试等待现象进行归因逻辑树梳理如下：
篇幅所限下面以人力不足为例进行细化分析：
业务测试人员产能是否足够
假设每个测试人员的产能一样，每天能完成的需求个数为 X，每个版本的测试阶段周期为 Y 天，每个版本的需求量为 Z。
以上三个值的估算逻辑如下：
人均产能：取历史上测试饱和度 90%以上的人天数据计算人天吞吐作为人均产能。
测试周期：按照业务版本周期的 30%时间核算
版本需求量：由于每个版本的需求量是有波动的，所以取历史上所有版本的 80 分位需求数为参考计算，偶尔超出的部分可以通过临时借调人员来进行补充。
示例业务 X * Y > Z 说明，测试产能有富余。
业务测试分配是否均衡
从时间和人员两个维度，来看业务版本人力使用的均衡性，如下图：
时间维度：存在明显的提测集中挤兑现象，11 月 14 日的提测量占版本总量的 42%。
人员维度：人员负载和产出存在较大差异，负载最高的人员承担了版本 40%的需求，最低的仅 3%，高负载人员的测试等待耗时较高。
△时间维度提测和测试吞吐情况
△人员均衡情况
业务测试是否存在人员单点瓶颈情况（某些类型的需求仅固定人员能负责，导致相关任务多的时候阻塞）
通过历史数据，统计不同业务方向/代码模块的需求的测试人员分布，看曾经测试过某个业务方向/代码模块的人数占业务总人数的占比，如下：
可以看到整体分布较均匀，未出现明显单点瓶颈
改进方案挖掘
基于以上过程面分析，可以看到人员层面在时间和人员分配上存在较大均衡度问题。下面以时间维度分配不均衡为例进行改进方案挖掘。
需求提测时间过于集中，可能有以下几方面原因：
1、版本计划就是这样制定的
2、研发估点误差较大，较多需求都堆积到 deadline 提测
3、临时插入需求较多或需求调整过多
依照以上 3 个方向进行进一步细化分析如下：
从以上数据可看出，导致时间维度上提测挤兑现象的主要原因是临时需求插入较多、有提测 delay，且这两类问题集中在 10、11 两日内出现，所以针对该问题从临时需求管控以及按时提测率两方面改进。
临时需求管理流程进行优化:
1、临时需求插入需要有准入机制
2、临时需求插入后需要置换等量的暂未开始开发的低优需求移出
3、版本临时插入设定 deadline 日期，deadline 后不允许再插入
4、临时需求占比作为长期度量指标，定期披露数据，驱动改进
提测 Delay 是由多种原因导致的，针对提测 delay 现象的优化，需要进一步的细化分析，这里就不展开了。
04 数字化系统工程实现
4.1 技术挑战
随着数字化分析场景的拓展和逐渐深入，对于数据的丰富性、时效性以及数据分析的效率都有更高的诉求，数字化技术层面面临着以下几个方面的挑战：
研发全过程指标采集和治理带来的数据采集、存储和维护成本剧增，同时高速增长的数据量和灵活多变的查询诉求也给数据查询性能带来了高挑战。
个性化分析场景诉求剧增，但是具备数据分析能力的团队成员有限，分析人力和效能难以满足业务数据分析诉求。
数据分析结论依靠各层级人员下发，系统不具备分发到具体执行人员的能力，难以自动完成改进效果回收。
4.2 详细方案
为了解决上面提到的问题，我们从以下三个方面进行建设：
建立低成本的数据采集、清洗、存储、管理方案，提供高性能的查询。
建立一套能够通过配置化的方式实现用户关注指标的智能分析，给出分析结论、建议的系统，达到可规模化服务的效果。
面向的不同的用户，提供不同场景下的产品化能力，达到分析结论有效触达和效果回收。
整体技术架构设计如下：
底层数仓：统一数仓、配置化的数据采集能力、数据分层设计、高性能的数据查询服务
决策引擎:
元数据：提供，表、字段、指标等基础元数据自动化采集，结构化存储，以及查询能力，提供指标元数据的增删改查能力。
算法中心：提供对单指标、多指标的常用数据分析算法能力，如趋势分析、分布分析、异常识别等。
模型管理：实现根据模型配置调用分析服务获取分析数据，并存储分析结果，生成可视化分析报告，提供模型结果数据查询服务。
触达：与内部多系统打通，数字化分析出的风险问题可通过触发服务生成待跟进任务提醒到对应负责人，驱动闭环。
服务场景：
业务负责人：提供详细的数字化分析报告，包含问题分析和改进提案。
一线经理：提供个性化的自动诊断报告、在线化报表以及数据问题快速定位能力。
一线员工：提供异常问题通知、闭环等能力。
4.3 自动分析案例
4.3.1 新建分析模型
1、创建新的分析模型
2、新建分析策略，选择策略类型以及需要分析的指标
3、配置要分析的数据范围，范围值可以采用动态参数的形式配置
4、配置要分析的维度（示例是趋势分析，所以有主维度配置）
4.3.2 分析报告
模型创建后会自动生成一个模型对应的分析报告页面，如下：
过滤条件依赖模型配置内的动态参数生成，可在页面内填入不同的值，获取不同数据范围的分析结果。
根据策略配置生成对应的指标图表以及基础数据解读。
05 总结
以上我们从效能分析整体思路、实践案例、技术实现介绍了我们是如何逐步形成基于价值的数字化决策系统，通过上面介绍可以了解到：
1、影响研发效能的三个核心因素：做正确的（高价值的）事、正确地做事、可持续顺畅交付。
2、业务测试人员人效分析：人员需求饱和度不足，其中一个原因是需求分配不均衡，可以通过人员池化的方式提升人效。
3、CR 过程分析：CR 工作存在高投入低产出现象，其中一个原因由于 CR 执行中存在大量秒过现象，可以通过 CR 工具链优化进行改善。
4、瓶颈分析：全周期中存在不少的纯等待耗时，其中测试等待占比较高，其中的一个原因是临时需求插入多，导致短时间内集中提测出现挤兑，可以通过临时需求管理机制优化进行改善。
5、数字化系统工程实现：搭建具备数字化智能诊断决策能力的数字化平台的技术实现思路。
效能数字化工作可以帮助团队形成基于数字分析的决策系统，通过数据的诊断、归因，挖掘出问题原因并推荐改进方案来影响决策，驱动真实的价值达成。
06 展望
数字化分析的核心是分析数据的完备性、有效性和基于研发效能本质情况下场景挖掘数字化，我们先需要有数据才能进行分析改进，而当前研发过程中还是有大量工作是未留痕，或者由于依赖人工操作留痕导致的数据不准确问题。后续需要通过持续性的工作过程的在线化，以及流程自动化建设提升数据本身的丰富度和准确度，让数字化分析在更多场景发挥作用。
——END——
推荐阅读：
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/bb742ed3e1e40d6552d62df5f】。文章转载请联系作者。
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论