MAN.6 度量，在 ASPICE的定义里，整个度量活动的起点是识别信息需要，度量项是用来响应信息需要的可衡量指标。很多团队把顺序搞反，先搜集一堆度量指标，再强行找这些指标可以回答什么问题。这样做出来的度量体系会出现指标繁多，但和业务关切脱节，一线人员填报负担很重，产出的报表却对项目决策几乎没有帮助。

在实际项目落地中，经常出现几类典型误区。直接复制别家企业的度量列表，没有梳理本组织、本项目真实的信息需要，照搬的指标并不适配自身业务场景。把度量等同于收集数字，只关注采集数据，没有对数据进行解读分析，也没有将分析结果反馈给利益相关方。度量项数量贪多求全，不管是否真的需要，把覆盖率、缺陷密度、工时、评审时长等全部纳入采集范围，增加工程师额外工作。混淆项目层面度量与组织层面度量，把组织级的度量要求强制下放到所有小体量项目，造成不必要的开销。采集完数据之后束之高阁，当项目出现风险时，度量结果没有用来支撑决策。

按照 ASPICE中 MAN.6 的基本实践，度量完整链路应当是：识别信息需要，定义度量项，数据采集，数据分析，沟通度量结果。信息需要来源于不同利益相关方的关切，项目经理关心项目进度与风险，QA 关心过程执行的偏差，管理层关心组织层面过程能力现状。度量项只是工具，目的是回答这些真实关切，而不是单纯产出数字报表。

开展 MAN.6 落地，第一步应当识别利益相关方的信息需要。区分项目级信息需要和组织级信息需要。项目维度，关注进度偏离情况、缺陷闭环情况、关键评审完成情况；组织维度，关注多项目共性风险、过程实践落地情况。不要上来就罗列一堆度量项，先梳理清楚，我们希望通过度量回答哪些实际业务问题。

第二步，基于信息需要，精简匹配对应的度量项。一条信息需要可以对应一个或者多个度量项，同时一个度量项不要试图去回答多个完全不同的问题。优先复用现有工作产物自动导出的数据，尽量减少人工填报类指标。完成度量定义之后，记录度量的采集来源、采集频率、分析方法、输出受众。

第三步，落实数据采集与分析。按照既定规则收集数据，重点保障数据来源可信。分析环节不是简单统计数字，而是对照信息需要解读数据背后的现象。例如追溯覆盖率数值偏低，要进一步分析，是需求粒度问题，还是变更之后追溯没有及时维护，而不是仅仅输出一个百分比数字。

第四步，沟通度量分析结果。把分析后的结论传递给对应的利益相关方，支撑项目管控或者组织过程改进。度量结果要讲清楚现状、潜在风险，而不是只抛出一张数字表格。

内部预评估核查 MAN.6 的时候，评估人员重点查看的不是度量报表数量多少，而是整套度量活动是否来源于明确的信息需要，数据如何分析，分析结果有没有用于决策。很多企业收集了大量数据，但缺少信息需要的来源记录、缺少分析解读，就会在 MAN.6 上产生弱项。

MAN.6 度量过程，核心是以问题为导向，而不是以指标为导向。从真实业务关切的信息需要出发，精简度量项，做好分析与结果沟通，才能够避免度量过度设计，让度量真正发挥支撑决策的作用，而不是变成应付评估的纸面工作。