DevData Talks | 张乐：研发数字化的四个层次和效能度量的五项精进

上周四，我们很荣幸邀请到腾讯技术工程事业群的资深 DevOps 与研发效能技术专家张乐老师参与 DevData Talks 直播活动。活动中，张乐老师做了《研发数字化的四个层次和效能度量的五项精进》主题分享。

以下是干货内容整理：

效能度量的不同关注点

近两年研发效能度量的话题特别火，但同时也出现一个关键问题：看似大家都在讨论研发效能，实际上不同身份可能讨论的是研发效能不同层次，对效能有着不同的诉求。

从中高层管理者的视角，可能主要希望站在全局视角下清晰定义研发效能，有一个简洁、易理解、数字化的方法来反映效能整体情况，说明全局性的问题和可提升方向。面对这类管理者，研发效能的作用是把复杂问题抽象化，也许是精炼成几个指数，来辅助整体决策。

这么宏观的视角，对于基层管理者来说可能就太虚了。基层管理者期待的是研发过程全盘数字化，能够看到细致的、覆盖各维度的效能数据，能够从宏观到微观逐层下钻，基于数据排查出根本问题，并能将数据作为抓手，指导改进行动。

一线工程师也需要研发效能数据吗？数据一方面可以成为工程师的镜子，用趣味性的方式提供客观量化参照；另一方面，在绩效评审的场景下，效能数据也能为开发者的优秀工作提供佐证。

理想情况是，同一套效能数据能够根据不同角色的不同需求，用不同展现逻辑来提供个性化价值。因此，大家在讨论研发效能度量前，需要先明确效能的服务对象是谁？需求是什么？在这一点上需要先取得共识。

研发数字化的四个层次

如何理解数字化？数字化是从物理世界中，开采出数据，粗炼出信息，精炼出知识，聚合出智慧，最终提高生产率，因此可以把数字化拆解为四个层次。

第一层的数据是对物理世界的原始刻画，在软件研发的场景下，可能是代码提交日志、需求流转记录、代码本身等。

并非所有数据都是有价值的。经过识别筛选去芜存菁，留下的是第二层的信息。需求前置交付时间、代码提交习惯、代码重复度等度量指标，都落在这一层。

多种信息聚合加工之后，辅以分析判断，就成为第三层知识。比如交付需求的数量和时长、研发团队的负载、需求交付周期中等待的时间比例，多个指标聚合为交付价值流的分析，反映研发团队是否正在顺畅、高质量地交付价值，这对于就是很有价值的知识。

在多个知识积累的基础上，结合专业领域的专家经验，推荐解决方案，这是第四层的智慧，也是数字化希望最终达到的目标。

研发效能度量也应按照这四个层次，不停留在数据本身，而是逐层向上聚合提炼，加工成可落地的改进方案。

研发效能度量的五项精进

去年写的这篇文章中，提出了“效能度量五项精进”这个实践框架。这里不再一一阐述，只做简单概括：

1. 自动化采集效能数据，减少人工投入，提高数据置信度

2. 建立度量指标体系，涵盖用于整体评估的结果指标和用于细节分析改进的过程指标、反映研发过程全过程的全局指标和反映单点情况的局部指标、用于事前干预的先导性指标和用于事后复盘的滞后性指标等多种类型，让各有侧重的不同指标协同发挥作用

3. 度量分析模型，对客观事物的规律进行抽象归纳，发现不同变量之间的关系，达到客观分析改进的目的

4. 度量产品建设，将复杂逻辑内化，对外展现简单清晰的效能数据，让用户可以自行消费数据，是研发效能规模化推进的基础

5.把度量引导到正确的轨道上，用数据驱动持续学习与改进，带着实验思维用一线真实故事核实结论

接下来我们会举些例子，深入讲讲指标体系、分析模型与数据驱动三方面。

度量指标体系

需求交付周期是相当常见的北极星指标。这一指标的价值在于它是端到端的全局性、结果性指标，反映了业务+产研团队对客户问题或业务机会的响应速度。要改善这一指标，需要整个组织各职能部门的协调一致，紧密协作，作为整体去交付价值。

然而，对于这样重要的指标，我们也未必完全清晰其定义和使用方法。这些模糊的部分会导致指标失真乃至失效。

首先，需求前置时间中的『需求』是什么？如果不对颗粒度做一定限制，花了三个月时间的业务需求和花了一小时的页面配置需求，必然是没有可比性的。我们将需求定义为『最小业务需求』，其特征是以业务为出发点，可上线运行，且完成了用户体验闭环。这些限定条件会让指标更加具象，也更加可用。

其次，这个指标应该怎么看？如果简单取平均完事，不理解统计背后的逻辑，可能又会掉入陷阱 —— 研究显示，需求前置时间这一指标并不呈正态分布，而是呈韦伯分布，因此85分位数这样的指标更能反映出真实、普遍的交付效率。另外，指标的趋势比绝对值更有参考价值。

再次，指标看过了，该怎么改善？找老板要求加人可能是加快交付的一个路径，但关键是要加在刀刃上。基于数据的下钻分析，找到交付周期中的瓶颈，进行针对性改善。

最后，如何保障指标是有效的？这就要求持续监控指标的健康度，通过规范乃至自动化流程，保障指标能够反映研发的真实情况。

以上围绕一个单点指标讲了这么多，主要想陈述的是，搭建效能度量体系的确实不能人云亦云，需要研发团队投入时间和精力去钻研和思考指标背后的逻辑，避免度量成为实际无人使用的面子工程。

效能度量分析模型

我从2019年开始搭建需求价值流的模型，研究过程中逐渐发现，研发效能的每个细分领域都值得深入分析，并针对性地抽象为模型来解决特定问题。这个过程包含了定位关键问题和关键变量、找出变量间的逻辑关系、引导这些变量不断改善。建立这套完整的体系是效能度量更加深入的必经之路。

这里用需求价值流模型来举例。在上图中可以看到价值流的五个关键要素：需求交付周期、需求吞吐量（单位时间交付需求个数）、流分布（交付需求的类型分布情况）、流负载（同一时间的在制品数量）、流效率（有效工作时间占总时间的比例）。基于这五个要素，我们能够相对完整地展现需求价值流动的情况，并从中找到瓶颈，针对性地制定干预措施。

在使用模型过程中，则涉及到不同分析方法。

例如宏观到微观逐层下钻分析：针对需求交付周期这个指标，可以先在时间维度上看趋势，判断是否需要干预；接下来可以按照阶段下钻，看看哪个环节耗时最长；进一步还可以按照组织层级继续下钻，从部门、团队、个人到单个需求粒度，逐步拆解找到问题。

例如关联性分析：尽管研发流程受到复杂的多因素影响，依然可以从历史数据中找到变化趋势的关联性，摸索实验，找到可用的抓手。举个例子，流负载可以作为交付周期的先导性指标，那么在实践中，我们会使用Aging Report这样的工具，分析在制品在哪个环节卡住，卡了多长时间，与过去三十天这一环节的平均停留时间的基线对比是否超过正常范围，这样基于关联性的实践能帮助我们提前感知问题，尽早解决瓶颈。

需求交付周期与相关性指标的因果回路图（理论）和相关性热力图（实际数据验证+针对性挖掘）

数据驱动的效能改进

之前写过一篇《研发效能度量的难点与反模式拆解》，这里简单展开阐述几点：

尽管硅谷的一些效能度量方法并不适合被直接套用到国内，但我很认同谷歌的GSM（目标/信号/指标）框架。首先，做研发效能度量，最重要不是指标，而是度量的目标。如果目标不明确，不理解为何做度量，度量定然是没有价值的；第二，度量后如果无法对结果做任何事情，那么度量也是不值得做的。效能度量需要以可感知的改善为终点，再去设计抵达终点的路径，牵引指标设计。

另外，毕竟研发团队中都是知识工作者，效能度量也不能仅仅服务于老板。我们需要多关注工程师的感受，了解工程师对工作环境、工作模式、工作负载、研发基础设施、项目协作、团队发展、个人提升等是否感到满意，是否有阻碍工程师发挥更大创造性和产生更大生产力的因素存在。

需要再次强调的一点是，尽管效能度量与数字紧密相关，但关在小黑屋里仅盯着数字是很糟糕的。建议大家多到研发现场去，把数字与现场观察进行比对。

研发效能度量的行业发展方向

最后分享我对研发效能度量行业发展方向的几点认知。

首先，行业对于效能度量的认知是越来越落地的，也在踩坑和反思的过程中逐渐摆脱了一些反模式，相信大家会逐渐走到效能度量的正轨上来。

其次，指标只是度量的第一步，度量工具也会逐渐向智能诊断分析的方向走。

最后，从使用方法上，大家也会从堆砌指标向效能提升闭环靠近，反思数据+进行实验，找到在具体场景下行之有效的方法，将改进落实到实处。下图来自阿里云效能产品负责人张燎原老师。

来自阿里云研发效能产品负责人张燎原老师的分享《研发效能度量背后的系统洞察》

> 关注【思码逸研发效能】公众号，获取研发效能最新资讯。