建立数据指标体系，推动 DevOps 全链路度量闭环

前言：

上一篇文章《苏宁消费金融在DevOps阶段度量设计的落地》中，我们提到金融行业的信息化和数字化的进程不断加快，促使IT部门的敏捷交付和精益运行的能力急需提高，因此 DevOps 的全链路度量体系也应运而生，建立健全的度量体系的需求在 DevOps 领域具有普遍性，有助于在更大范围内快速实现可度量的价值交付，拓展了业界的 DevOps 适用范围，有助于更好提升组织级的质量和效率。

通过度量完成科技侧的数据化，利用数据和相应的指标反馈进行过程管理和优化现有流程，有四个步骤，分别为：1、归集度量数据指标；2、度量数据指标拆解；3、确定度量数据维度；4、构建度量指标模型；5、打造 DevOps 全链路度量体系。本文中，我们针对指标体系进行展开。

一、指标体系的作用

在我们的度量体系中，指标体系主要承接的是主观事件客观呈现的效果，主要有两个原则，一是我们为什么需要指标，二是从这些指标中，我们能够获得什么。在实际的场景中，我们进行工程效率管理，一般会有两个误区同学们一定不会陌生。无论在需求分解成任务，任务挂靠研发团队的环节，大家都会进行研发资源的工时预评估，还有项目实际开发过程中，进行人员能效的实际评估都会出现各种因为数据指标覆盖率不全，或者度量方式不一致、价值输出口径不同、虚荣性指标过于凸显的问题产生困惑。因此会衍生出如下疑问，你说的数据，我每天都在统计，可这些数据怎么就成体系了？做成了体系又能怎样？为什么我不觉得基于我的团队或者个人指标不成体系？下面我们先从数据指标讲起。

二、数据指标是什么

在需求面临大面积加塞的情况下，我们经常听到：5天后正常按计划上线应该可以，大概还有300个人天可用，这部分需求上线感觉不能达到预期的效果，感觉这个版本可能会出一些技术上的问题。因此在没有数据指标的情况下，我们在评估和度量环节，存在不确定、不具体、不准确的情况。

为啥需要数据指标，根据度量的三位一体方法，点、线、面。度量的点，管理者需要帮助个体和团队提升交付能力，推进既定的时间点完成目标达成的任务；度量的面，管理者需要控制风险，在度量数据的配合下，形成数据趋势性的结果和目标达成的里程碑的高度契合；度量的面，管理者需要根据度量结果来进行资源的动态调配，梳理标杆，帮扶落后，同时进行团队和组织的横向考评和调整。

通过度量的三位一体方法，最终达到优化的目的。从上述的方法中，我们可以得出一个结论，数据指标是度量体系最直接的支撑，也是数字化的底层结构，数据指标存在的意义就是对抗不确定。

回到我们面临的上述问题，可以这么回答，5天后正常按计划上线没有问题，有20%的需求优先级较低可以延后，可以调剂出300人天的资源配给，这部分需求已提供准确的运营测算，上线后可以达到预期的效果，这个版本有时间进行二轮回归，能够覆盖95%的问题，能够保证投产质量。如果我们这么说是不是觉得很爽快，这就是数据指标的直接用途。

三、数据指标体系是什么

在工程效率的管理中，尤其侧重于团队和个人的能效饱和度，想准确说清楚其实是一件很麻烦的事情。比如我们想说，交易中台研发团队在0610版本中研发效能很高，人均日产出代码量达到500行。如果评估想较真的话，可以挑出一堆刺出来。

一个问题，往往有很多方面，只有一个指标不能充分说明问题，这就需要一组有逻辑的数据指标来描述，这就是数据指标体系。

四、数据指标体系五大关键要素

1、全局指标

在 DevOps 交付流水线中，涵盖了很多关键节点，如项目管理、资源管理、研发管理、测试管理，还是基于交付后的交付管理、项目后评价，每个关键节点都有一个或几个全局指标来进行度量，这些全局指标可以进行过程管理也可以进行结果回溯，因此全局指标也是主指标，同样也是一级指标。这类指标的显著特征为通俗易懂，可以是实时的，也可以是滞后的。

2、细分指标

相对于全局指标，构成全局指标计算公式的是细分指标，也叫子指标。细分指标的覆盖范围较小，只针对某一聚焦的点，相对于主指标的综合评价，细分指标更侧重于综合评价之下的二/三级指标。

以 DevOps 交付流水线为例，项目经理负责管控整个交付流程，所以项目经理除了把控项目进度和项目风险外，相应的全局指标应该包括交付效率、交付质量、交付能力，交付效率为了端到端的快速的交付，交付质量为了端到端的质量交付，交付能力为了提高工程效率达到高效的持续交付能力。

项目经理和产品经理、开发技术经理、测试技术经理、运维技术经理形成矩阵式管理，因此整个交付阶段的全局指标应该分解到需求、开发、测试、发布、运维各个关键节点中。每个关键节点又有各自的全局指标，如需求交付周期、开发交付周期、需求交付吞吐量。下面列举在DevOps的全链路交付流水线中，全局指标和细节指标的一些对照关系。

选择主指标不同，拆解细分指标也不同，如上图的逻辑，如果选择个人能效作为二级指标，往下拆解的细分指标一般为代码提交量、代码重复率、代码注释率，相对于的还有承接需求数，承接任务数等细分指标作为关联。如果选择个人代码质量，往下拆解的还有代码评审通过率、代码提测成功率、bug解决数等指标。

但有些指标并非越大越好，在细分指标领域，存在较多的虚荣性指标，如研发阶段的人天代码量指标，需要跟代码注释率、代码重复率、冒烟通过率、bug数等指标相结合，属于颗粒度较细的过程指标，在度量上需要更为审慎。

3、过程指标

在DevOps的度量体系中，过程指标承担了80%的指标占比，过程管理的侧重点是用来帮助团队快速的达成指标度量的有效行为，认清并改进团队。

相对于主指标，更关注的阶段性的结果，比如基于项目的主指标，除了以上所述，还可以根据关注维度不同，可以分为项目成本、项目风险等指标。在过程管控中，项目的风险可以依据需求加塞、需求优先级提升、研发资源的变化、测试阶段的质量管控、各能力子域的任务停留时长进行评估风险，最终判断交付周期是否有明显的变化。

在这个过程中，光看一个能力子域结果是无法监督和改进过程，如果想更进一步进行管理，就要看了更细一些，因此在DevOps的交付流水线中，在各关键节点中进行过程管理，添加二/三级指标进行统筹管理。

4、分类维度

对于一个大的版本来说，关联的维度有很多，基于产品经理来说，更多的关注需求吞吐率、需求覆盖率、需求的交付能力，因此基于需求的分类维度就较为丰富，一般为需求文档的定稿、需求的任务分解、需求的系统分解、需求的交付周期、开发的交付周期、测试的交付周期，以及研发团队的需求评审。对于研发leader来说，多个研发团队和个人的能效管理是重中之重，承接的需求越多，质量越高是终极目的，因此更加关注每个团队每个人完成了多少，完成的质量如何，在分类维度中，将主指标切成若干块，这样可以避免平均数陷阱和团队的虚荣指标，把整体和局部看的更加清楚。下图为各能力子域的平均停留时长的相关过程指标。

在分类维度中，要注意一点，根据实际的管理方式和方法进行维度的切分，分类维度没有一成不变的，也没有好用不好用之分，能提升管理能力的分类维度是好的维度。

5、判断标准

即使有了以上四点，我们还不能说，这个项目交付完成的好，交付的质量高，因为好和差是相对的。所以判断标准一般有两种方式，一种和过往的指标相比，提升了多少。还有一种是和行业内的头部企业相比，处在什么水平。参照物的选择本身就是个复杂的分析过程，需要进行深入的分析。构建指标体系的时候，往往这些判断标准是和当前数据一起呈现的，也是为了后期的度量，因此一个好的判断标准能够给你带来最直接的管理提升。

五、结语

在《苏宁消费金融在DevOps阶段度量设计的落地》一章节中，我们讲到，通过DevOps交付全链路的度量，不断的优化交付链路过程中的问题和缺陷，从而确保度量设计的价值输出。对于软件交付来说，提高软件交付的质量和效率不是根本目标，而通过提升软件的价值交付，来促进产品达到商业目标才是最终的目标。因此构建数据指标体系也是为了构建 DevOps 度量体系，数据指标体系是度量体系的前置条件，所以在度量体系的范畴内，我们也遵循相应的准则。

1、明确工作目标

明确工作目标，应具备主指标清晰的效果。在此之前，我们需要了解做指标为了什么，指标能够赋予我们什么，先把主指标的管理和优化的定位考虑清楚，后续的判断标准才能确定目标，相应的细分指标对应哪些管理流程。

2、清晰的判断标准

在做工程效率领域，总有一个参照物，而这个参照物能够返回你一个明确的结果，好或者是待改进。因此一个清晰的判断标准很重要，决定了你所看到的分析结果是一堆有用的数字还是一堆花花绿绿的数字。在 DevOps 度量体系内，涉及到项目后评价，一方面能够完成成本的复盘，另一方面也能对过程管理中的判断标准进行结果的回溯，因此判断标准是不断演进和优化的。