3.3 度量和改进实践
业务是BizDevOps的起点，是贯穿价值交付链路的核心要素，也是衡量BizDevOps实施成功的终极标准。同样BizDevOps的度量体系，也必须以业务为核心，服务业务的成功。
BizDevOps度量的目标和指标体系
BizDevOps度量的目标是：指导团队针对性地改善能力和行为，从而提高交付效能，最终带来期望的业务结果。基于这一目标，我们把度量指标分为三类。如下图所示，它们分别是：业务结果指标、交付效能指标，以及能力和行为指标。区分这三类指标并明确它们的关系是有效度量的基础。
业务结果指标：右边的业务结果指标反映业务的成效，如：收入、利润、用户数、转化率、留存率、服务成本、用户口碑、社会价值等。它们是组织的最终目标，但对产品研发而言，这些是既成事实的结果，无法用来直接指导改进行为。
图3-16：BizDevOps的本质目的和指标分类
交付效能指标：中间的交付效能指标用以衡量产品研发的对外（业务）交付效能，如：响应周期、吞吐率、质量和有效性等。交付效能指标是产品研发侧关于业务结果的代理，我们也称其为"代理指标"。作为代理指标，它与被代理的业务结果之间的转化函数是有损的。我们应该选取并关注那些对业务结果转化效用高的指标，把它们作为核心的效能指标，并持续检验它们与业务结果的关联度。尽管交付效能指标反映了研发的对外交付效能，但还是不能用来直接改进。
行为和能力指标：左侧的行为和能力指标，包括团队和个人的行为，如：工程习惯、协作方式、需求并行度、代码评审质量等；也包括技术和工程能力，如：代码质量、架构耦合、测试覆盖率、发布成功率等。它们与交付效能之间转化函数同样是有损的。尽管，理论上行为和能力决定交付的效能；但，我们需要系统分析哪些能力和行为影响了交付效能，才能针对性的改进，而改进效果必须依靠交付效能的变化来验证。行为和能力指标的好处在于，它直接指向需要改进的地方，是可以被控制的，所以也被称之为控制指标。
上面的三类指标中，越靠右边的是越外部的，接近想要的结果；越靠左边的是越内部的，指向需要改进的行动。效能度量中常见的误区是：把内部指标作为衡量和考核要求。它带来的问题是：内部数据提升了，交付效能和业务结果却没有改变，甚至因为局部的优化，而变得更差。这个误区非常常见。
有效的度量应该区分外部度量和内部度量。其中，内部度量用以授权和赋能⸺授权给一线的团队，赋能它们分析哪里需要改进，怎么改进；而外部度量用作导向和要求⸺确保改进走在正确的方向上，并切实起到作用。
BizDevOps度量的目标是：
1 ）赋 能 组 织 或 团 队 掌 握 效 能 状况，分析效能问题，并针对性地改善 能 力 和 行 为，从 而 提 高 交 付 效能，带来期望的业务结果；
2）度量为改进行动的结果提供有 效反馈。
在以上三个类指标中。业务指标因业务类型而异；行为和能力指标，需要基于具体的度量改进场景，选择和定制。本白皮书将只提供交付效能指标的参考建议。
上表的交付效能指标分为需求交付效率和工程效率两个部分。需求交付效率体现组织顺畅和高质量交付价值的能力。工程方面参考了DORA的度量模型，反映组织的持续部署能力。光有指标，度量和改进还无法落地。一个完整可落地的度量体系需要包含：数据的采集、信息的获取、组织和呈现，以及如何应用度量来改进组织的运作和效能。接下来的一节，将涵盖这几个方面的内容。
BizDevOps 的度量和改进体系
BizDevOps实施也是组织内部数字化转型过程，而度量则是数字化转型中的数据应用。我们可以从各类数据应用的案例中借鉴被一再验证的理念和实践。
在数据（尤其是大数据）应用中，DIKW是被最广泛采用的模型。我们也将基于它来设计BizDevOps度量体系。DIKW模型由数据（Data）、信息（Information）、知识（Knowledge）、智慧（Wisdom）这四个层次构成，它们的首字母合在一起便是DIKW：
• 数据：数据是在运作过程中产生的可以被采集的原始事实；
• 信息：信息是基于数据生成的，并被赋予特定的意义或解释。信息可以表达为指标，也可以表现为图形和表格等其他形式；
• 知识：知识是被有效组织的信息。有效组织的依据是，能够被用来系统回答重要的问题；
• 智慧：智慧是应用知识指导有效的行动。从数据到信息再到知识，这些只能用来解释过去，只有智慧是改变未来的。
度量本身不是目的，度量的真正目的在于改变未来，也就是DIKW中“W”（智慧，Wisdom），但是智慧无法凭空产生，它需要数据、信息和知识的逐层支持。对应DIKW模型，有效的度量体系应该是：基于可靠的基础数据，组织有意义的信息，回答具体场景下的核心问题，指导有效行动并达成改进目标。
有效的度量和改进体系应该是：
基 于 可 靠 的 基 础 数 据，组 织 有 意义 的 信 息，回 答 具 体 场 景 下 的 核心 问 题，指 导 有 效 行 动 并 达 成 改进目标。
可靠的数据、有意义的信息、回答核心问题的知识、带来有效行动的智慧，这是成功的度量和改进体系的4个要素，也是度量和改进产生的顺序。不过，在应用度量进行改进时，顺序正好相反。为了应用度量进行改进：
第一，要弄清楚，我们期望带来的改变⸺需要怎样的智慧；
第二，为了指导有效的行动，我们需要回答怎样的核心问题⸺建立什么知识；
第三，应该怎样系统回答这个问题⸺如何组织信息；
第四，怎样产生这些信息⸺采集哪些数据，如何保证有这些数据，并且数据是可靠的。
图3-18：应用度量指导改进的例子
上图给出两个应用度量进行改进的场景化案例，分别是质量保障场景和质量改进场景。两个场景目标不同，期望带来的行为不同，对应的由知识、信息和数据构成的度量体系也不同。
1.智慧：BizDevOps度量和改进的目标
度量不是目的，度量的真正目的在于改变未来。BizDevOps度量期望改变包括近期的未来和远期的未来。改变近期的未来，靠的是透明现状和问题，保障更好的规划和执行。上例中，质量保障场景就属于此类。改变远期的未来，需要了解当前的效能水平，并分析深层次的问题。上例中，质量改进场景就属于此类。
2.知识：为了支持目标的达成，需要回答的问题
明确度量的场景目标，接下来要确定的是，为了支持这个场景目标，我们希望通过度量回答什么问题。比如：为了保障执行过程的质量，我们需要回答，质量状况及趋势怎么样？质量活动是否在有效进行？有什么风险和问题？是否需要干预调整？为了改进长期的质量，我们要回答的问题是，当前组织或团队的各方面质量水平怎样？造成质量问题的根本原因是什么，怎样改进？
3.信息：为了回答这些问题，可以应用的指标和图表等内容
确定了要回答的问题，接下来就是要组织信息来回答这些问题。比如：为了回答上述质量保障场景中的问题，我们需要的信息有：缺陷的密度、趋势、存量、响应和分布，以及质量活动（评审和测试等）的计划、进度和结果等。
4.数据：产生需要信息的原始数据
离开可靠的数据，一切度量和改进都是空中楼阁。可靠的数据具备3个特征：
1）全量：记录数字化运作过程中所有的行为；
2）全要素：数据能体现各个需要的维度，并产生正确的关联，如缺陷与对应的代码关联，工程行为与需求关联；
3）实时：数据应该在行为产生的第一时间（如：需求分配，代码提交，部署发生等）作为副产物被自然记录，而不是后续专门补充。后补的数据既容易缺失，也会失真，更无法支持实时的应用
如 何 才 能 保 障 数 据 是 全 量 、全 要素 和 实 时 的 呢 ？数 据 不 是 一 个 独立 的 体 系，它 依 赖 于 数 字 化 的 实施 。在 第 二 章 中 ，我 们 介 绍 了BizDevOps的概念模型，它在其抽象层次上囊括了主要的概念，建 立 了 这 些 概 念 的 关 联，并 识 别了核心作业对象。基于它扩展、定义 和 落 地 数 字 化 体 系，实 时 记 录作 业 对 象 的 操 作 记 录，并 关 联 相关 对 象 的 数 据，可 以 保 障 数 据 的全量、全要素和实时。BizDevOps概念模型的一个应用场景就是指导数据体系的设计。
基于DIKW模型从场景目标出发，设计和应用度量体系，并落地具体的改进行动，前面介绍的其他BizDevOps实践为改进行动提供了参考，改进的结果最终应该在交付效能或业务结果中被检验。如此，就形成了持续改进和反馈的闭环，通过它进化组织的BizDevOps实践体系，从而加速数字业务发展和引领数字业务创新。
