01.引言
在之前的一系列文章中，我们已经深入地探讨了研发效能洞察的重要性，并介绍了几种常用的度量分析方法。然而在度量实践的过程中，仅仅依靠理论框架是不够的，我们还需要将这些理论与企业的实际情况相结合。在这个过程中，企业常常面临着各种问题：比如，难以采集分散在多个系统中的关键数据；难以满足业务发展中频繁调整指标的需求以及难以对不同部门的数据权限进行隔离等。
因此，我们需要一个度量平台，它能够自动采集多个系统的数据，可以通过配置的方式快速修改指标，并且能够实现精细化的权限控制等。在本章中，我们将详细地描述效能洞察的建设过程，并进一步讨论在实施效能度量中常见的问题，以帮助大家更好地了解一个良好的度量平台所需具备的关键能力及其背后的原因，为企业提供一个全面了解和合理运用效能度量平台的指南。
02.度量建设的常见步骤
首先，我们来详细了解一下度量建设的常见步骤。
1）需求调研阶段
在这一阶段，我们需要了解用户的原始度量诉求以及度量目标，并与客户沟通是否已有所需度量的指标清单。若客户对度量需求的概念较为模糊，暂不清楚如何开始度量体系的建设，我们可以按照指标拆解方法进行梳理和引导。最终，需要输出一份详细的指标清单文档。该指标清单通常应包含以下关键内容：
- 主题（仪表板）：用于展示一组目标一致的指标。它通常旨在解决某一类角色面临的一个或多个具体问题。
- 指标分类：帮助了解指标的度量类型，可以按域进行分类（如需求域、测试域、代码度量域、集成域、跨领域），也可以按其他类型进行分类。
- 指标名称：用于区分不同的指标。一个简明扼要的标题能够清晰地介绍指标内容，便于用户一目了然了解指标的用途。
- 指标口径：详细介绍指标的统计逻辑，便于用户能够清晰了解指标结果的计算方式。指通常，指标口径会通过指标备注进行展示。
- 数据来源：根据指标口径，确定数据来源的系统、数据库表、接口和字段。这些数据将被用于获取、处理和关联，最终构建出指标所需的数据模型。
- 图表类型：根据指标的维度、度量和过滤条件来确定使用何种图表类型进行展示，以便更有效地传达数据信息。
- 查询条件：帮助我们在大量数据中筛选出最关注的数。例如，我们可以按项目或优先级来查询缺陷数据。
- 关联指标：对于需要进行联动、下钻的指标，列出与之相关的指标，并按照指标清单的所需内容进行拆解和关联。
- 指标意义：介绍指标所解决的问题，或在指标数据出现异常时，应如何查找问题原因及解决路径。
- 阈值设置：用于定义指标结果的正常范围，当数据超过这个范围时，就需要引起我们的关注，以便及时采取措施。
2）数据处理阶段
在需求调研阶段输出的指标清单中，已明确说明了每个指标的数据来源系统、取数逻辑以及必要字段等。我们将根据这些信息，对需要度量的相关数据进行清洗和加工，最终形成数据模型，并将这些模型统一存放在数据仓库中。
3）数据展示阶段
不同图表类型有着不同的表达侧重点，选择合适的图表类型能够更为精确地传达数据信息。我们需要确定每个指标的展示方式，并最终将这些指标分组展示在仪表盘中。
- 柱状图：适用于对比多个分类间的数据大小和数值。
- 折线图：用于展示连续数值（如时间）或者有序分类的变化趋势。
- 条形图：与柱状图使用场景类似，但当数据类别名称较长时，条形图更为合适。
- 饼图：用于展示分类之间的占比情况，适用于展示整体与各部分的相对比例。
- 散点图：用于展示两个连续变量之间的关系或相关性，便于观察变量之间的分布和趋势。
- 排行榜：通过数据高低排序，直观体现数据排名情况。
- 雷达图：能够直观呈现多个维度上的数据，便于一目了然地比较和分析数据的差异。
4）权限控制阶段
数据是重要的资产，对其进行权限控制可以防止敏感数据泄露或滥用。此外，通过权限控制，可以对数据进行分组管理，让不同用户聚焦自己关注的数据。
03.企业度量建设可能会遇到的痛点和解决方案
下面介绍度量建设步骤中，企业可能会遇到的痛点以及解决办法。
1）数据获取阶段的痛点
例子：某企业设有大数据部门，该部门主要负责存储和处理数据，数据存放在Hive大数据仓库中。随后，该企业建立了DevOps平台来支持研发过程。由于DevOps平台产生的数据业务特性较强，因此由专门的业务部门自行存放，并将此部分研发过程数据存放在了Doris大数据仓库中。同时，该企业还使用了多个自建的第三方系统，如测试管理平台和代码仓库等，数据分散存储在不同系统中。
该企业面临的痛点：
- 拥有多个自建系统，业务数据分散存储在这些不同的系统中，导致数据采集困难。
- 已经存在Hive数据仓库，担心重复建设，且不希望进行大规模的数据迁移。
- 不同业务系统使用的数据库类型不统一，数据存储格式也存在差异。
对度量系统提出的需求：
- 能够方便接入多个系统的数据，自动采集这些系统的数据，并进行统一度量。
- 能够直接利用现有数据仓库的数据，无需做大批量数据迁移。
- 能够统一数据格式，并使用相同语言对数据进行处理。
为解决企业在度量数据获取方面的潜在痛点，度量系统需要具备以下能力：
- 具备快速接入第三方系统数据的能力，支持拓展外部数据源。
- 拥有直连不同数据源并直接取数的能力。
- 平台具备一定的数据处理和建模的能力。
2）数据处理阶段的痛点
例子：某企业基于原始业务数据库数据（MySQL）进行取数和建模，由于缺乏建模思维，仅仅对原始库表数据进行原样存储。这导致一旦新功能上线并改动库表结构，就容易引发指标展示异常。同时，由于数据存储在MySQL中，受限于其数据读取性能，指标展示速度缓慢。当有多个用户同时访问指标时，页面经常卡顿，导致无法正常打开。此外，使用原始库表提供数据，受限于业务，模型的通用性很差，大部分指标都需要生成新的数据表再提供数据。
该企业面临的痛点：
- 原始数据结构变更后，指标需要频繁同步调整。
- 普通数据库读取数据的效率低下。
- 多表关联关系复杂，数据处理难度大。
对度量系统提出的要求：
- 业务数据库表字段发生变更时，不应影响现有指标的展示。
- 数据读取与展示需要顺畅，避免数据卡顿和计算慢的问题。
- 系统能够在平台上处理多表关联关系，实现简单的数据表关联操作。
为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：
- 建模层次结构遵循一定的建模思维，需要具备通用性。顶层模型应能够屏蔽底层数据表的字段差异，并具备不同层级的模型的管理能力。
- 系统需要自带部署大数据仓库，该仓库需具备强大的数据读取能力和处理能力。
- 系统需要具备对模型进行拓展的能力，包括连表能力、SQL处理能力等。
3）权限管控阶段的痛点
例子：某大型拥有众多企业部门和人员，其中包括部分外包人。集团希望对部分敏感数据进行权限管控，确保这些数据仅对关键岗位开放。然而，受限于当前系统的功能，权限只能控制到菜单级别。这导致不同部门间数据可以互通，A部门能够看到B部门的关键数据。此外，由于部门人员众多，每次发生人员部门变更，都需要重新调整权限设置，这不仅耗时费力，而且配置的权限还容易出错。
该企业面临的痛点：
- 无法实现不同部门人员仅能查看本部门的数据。
- 权限配置操作流程复杂繁琐，授权过程耗时费力。
- 当用户所属组织发生变更后，需要重新更改权限配置，耗费人力。
对度量系统提出的要求：
- 鉴于该企业人员较多，数据被视为重要资产，因此需要实现权限的精细化控制。
- 简化权限配置的操作流程，以提高工作效率。
- 用户更换部门或职级时，系统应能自动调整或继承相应的权限，从而避免重新配置权限。
为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：
- 提供多种权限配置能力，涵盖但不限于菜单级别、功能级别、仪表板级别、数据级别的权限控制能力
- 权限配置操作简洁明了，具备良好的交互体验，便于用户操作。
- 支持动态权限的读取与自动配置功能，确保在用户部门发生变化时，其数据权限能够实时、自动地同步更新。
4）数据呈现阶段的痛点
例子：某企业通过定开方式产出指标，需要耗费大量的研发资源做定开，大量度量需求堆积，业务数据得不到及时验证，导致业务部门对长交付周期感到不满，而研发则常感排期紧张，时间不够用。此外，业务需求频繁调整，每次调整后都需要重新处理数据处理并修改接口。代码修改完成后，还需等待发布窗口进行部署，无法实现无感更新，导致上线出错率高，且错误内容难以及时修正。
该企业面临的痛点：
- 数据图表依赖定期开发实现，导致开发周期长，研发产能难以满足需求。
- 业务逻辑频繁调整，数据统计口径变化迅速，使得业务需求难以及时得到验证。
- 图表表现形式需求多样，需要能够灵活满足各种数据的展示需求。
对度量系统提出的要求：
- 能够解决资源卡点问题，减少投入研发资源。
- 指标能够快速上线，帮助业务快速验证度量需求。
- 图表能力能够满足使用，样式丰富。
为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：
- 具备可视化的在线指标配置能力，降低使用门槛，使得非开发人员也能轻松上手，降低使用难度。
- 能够突破发布窗口的限制，实现即时保存与即时生效，实现无感上线。
- 支持多种常用且高级的图表的配置，能够配置指标间的联动下钻，并具备多种样式的配置能力。
04.总结
通过上述说明，我们了解到优秀的度量平台需要具备以下核心能力，这些能力也可作为企业在选择度量平台时的参考依据。
- 数据拓展性强，支持快速对接第三方数据源，实现跨领域的数据度量。
- 数据处理能力强，能够高效处理大量数据的读写请求，确保查询与展示数据时流畅无阻。
- 权限精细化管控，能够实现数据行级别的权限控制，实现跨部门数据隔离。
- 指标可视化配置灵活便捷，配置操作简单易懂，能够迅速响应业务指标的快速迭代需求。
