DevData Talks | 张超：场景化度量实践案例

『没什么用』的效能度量，可能离场景太远

研发效能领域的常见问题：组织投入资源建设了效能度量，也抱以极高期望，但从一线研发团队得到的反馈却是『感觉没什么用』。

价值感受不明显的具体原因，可能是用户拿到的数据与其需求并不匹配，比如将来自各个环节的海量数据明细直接展示给高层技术管理者，信息冗余造成极高的理解成本，效能度量自然被打入冷宫；可能是组织还没有对度量目的达成共识，漫无目的地看数据，数据就仅仅是数字的组合，沦为鸡肋也不奇怪。

有价值的效能度量，应该是怎样的形态？考虑到一线研发团队的绝大部分精力都投入在业务上，一个还需要用户补习领域知识、自行筛选解读的半成品数据集，确实不如人意。明明想要提升效能，反而需要投入额外精力，无异于南辕北辙。

要使效能度量的价值最大化，我们提供给研发团队的应当是『效能产品』。如张乐老师先前的分享所说，数据→信息→知识，用户可以根据需求，低门槛地自助消费数据，主动进行分析和洞察。

场景化分析，设计效能度量的第一个环节

当我们用产品思维重新思考效能度量这件事，『场景化』就成为必要条件。可以从目标出发，借助场景化分析，明确以下四个要素，进而设计效能度量方案：

• 角色：度量数据使用者的在研发团队中的角色，决定了度量结构（组织、团队、项目、个人级）
• 背景：明确为什么做度量，这个需求可能来自业务方，或来自研发团队本身。上下文决定了度量对象（进度、质量、过程等）
• 目的：同一度量对象可能对应多个指标，因此需要拆成多个问题，进一步细化，这里不妨采用技巧：先抛出具体论点，然后思考要证实或证伪这个论点，需要哪些指标做支撑，哪些指标作为制衡保障度量有效性
• 度量：构建最小度量集合，并思考采用哪些分析方法来解读数据中的信息

案例：常见的『研发团队要加人』场景

接下来我们展开介绍直播分享中的第一个场景，作为场景化度量实践的案例。直播中另外两个场景可以在直播回看。 这个场景可以说是相当常见：研发团队向上反映人手不够，要加人。那么高管在这个场景下的需求是：

• 角色：高管
• 背景：需要客观评估研发资源紧张程度，指导后续招聘工作
• 目的：验证『要加人的 A 部门和 B 部门都存在人力缺口』是否成立

对于高管而言，度量对象是组织整体与某几个团队的产能与交付情况。 高管可以把代码当量、需求交付周期、需求吞吐量等指标作为数据抓手，从资源效率（价值输出方视角）与流动效率（价值输入方视角）两个视角，评估组织整体的产能情况，并通过与行业基线对比，评估是否存在组织级的产能紧张。

与行业基线的对比显示，大部分时间内组织的整体产能水平处于正常区间。 接下来，可以按照部门进行下钻分析，重点关注 A、B 两个部门的人均产能与组织均值的对比。 尽管不同部门可能在业务性质、阶段等方面存在差异，横向对比不一定适用。但这里部门级分析没有任何考核目的，仅是通过相对简单的数据抓手，识别需要高管额外关注的关键点。 下图显示，B 部门的人均产能偏低，继续下钻查看部门详情，显示 B 部门产能有显著降低的趋势。

基于这些洞见，『B 部门存在人力缺口』这一论点存疑，高管可能会要求 B 部门补充信息，来支持其人力需求的合理性。

现在问题回到了 B 部门内部。角色切换到 B 部门技术负责人，继续用场景化分析的思路梳理：

• 角色：技术负责人
• 背景：需要深入了解工作过饱和现象背后的根因，佐证人力需求确实存在，或采取针对性的效能改进措施
• 目的：验证『工作过饱和的原因是团队协作行为有待改善』（这是多个待验证设论中的一个）

对于技术负责人而言，度量的对象是本部门的效率，以及可能影响效率的诸多因素。 技术负责人通过观察人均产能趋势发现，尽管最近加班加点，人均产能连续上升，但也仅回升至去年同期平均水平。同时，由于相关业务处于平稳期，需求吞吐量也没有明显波动。从资源效率与流动效率两个视角看，都不存在需求激增超过团队负载的情况。

为了验证团队协作行为是否对效率产生了影响，技术负责人可以从资源效率出发，进一步下钻至个人级，使用帕累托图去分析开发者的产能分布；也可以从流动效率出发，观察需求交付周期趋势，以及各环节的时长分布。 分析发现，尽管需求吞吐量变化不大，但交付周期明显延长，流负载（在制品数量）也显著增加。任务积压导致团队成员需要同时处理多项工作，频繁切换上下文，进一步拖累团队效率。 在团队中，某一部分工作延期较频繁，经常成为项目关键路径上的活动。技术负责人对该部分的相关开发人员近期产能进行帕累托分析，发现 80 %的代码工作量由 22% 成员贡献，反映出该部分工作存在任务分配不合理、不均衡，少数成员承担过多任务的情况，这也呼应了上一段提到的任务积压现象。

基于以上洞见，技术负责人能够了解到，协作不合理确实是效率的影响因素之一。进一步，可以选择针对性的改进措施，如

• 与上游产品方沟通，控制需求流入，避免在制品数量继续上升，给关键环节以喘息调整的时机；
• 调整任务分配机制，避免多个任务同时依赖于少数成员；
• 定向组织培训，释放开发者潜能，使『单挑大梁』转变为『齐心协力』

通过场景化分析，使同一套数据面向不同角色、不同背景呈现出不同切面，在保障信息对齐的同时，使各角色从效能度量中各取所需。

本文由博客一文多发平台 OpenWrite 发布！