指标树中因果关系与支撑关系怎么梳理

指标树里，因果关系和支撑关系经常被混在一起画。判断方法可以简化为一句话：前者变化会通过一条可解释的路径带动后者变化，并能用数据检验，属于因果；前者为后者提供输入、资源或约束，但不必然引起后者变化，属于支撑。梳理时先把研发效能目标拆成结果层、驱动层和过程层，再逐对判断关系类型，标注方向与依据，最后用历史数据或小范围试点验证关键因果假设，删掉无法验证的连线。

要点总览（TL;DR）

• 判断一对指标属于因果还是支撑，看三点：前者变化是否带动后者、能否说清影响路径、能否用数据或试点检验；三点不全的连线降级为支撑或待验证。
• 建树按四步走：定结果层目标与口径、拆驱动层并写假设、落到过程层可采集指标、逐对连线标注类型与依据。
• 因果连线用实线并写机制解释与验证计划，支撑连线用虚线并写输入来源与责任角色，两类连线都要有责任人。
• 关键因果假设用历史数据回溯或小范围试点检验，被证伪的连线删除或降级，并补上真正起作用的中间指标。
• 上线前逐项检查：口径唯一可采集、无孤立指标与循环依赖、待验证连线有验证时间、变更与复审机制已确定。

先分清因果链与支撑链

指标树的价值在于解释“为什么这个指标变化会影响那个指标”，而不只是把指标按层级摆好。因果与支撑是两种不同的解释方式，判断标准、标注字段和后续验证要求都不一样。梳理时应对每一对上下级指标逐对判断，避免整棵树只用一种箭头草草连完。

因果关系的判定条件

两个指标构成因果连线，需要同时满足三个条件。方向明确：前者的变化会带动后者变化，反过来则不成立或明显减弱。机制解释：能说清楚通过什么路径影响，例如“需求评审一次通过率提升，减少返工，从而缩短需求交付周期”。可被数据检验：有历史数据可以回溯相关性，或者可以设计小范围试点观察变化。三个条件缺一，这条连线就应降级为待验证或改为支撑关系。

支撑关系的判定条件

支撑关系描述的是输入、资源或约束，不承诺变化传导。判定时看三点：前者是否为后者提供输入或数据来源，例如代码提交记录支撑代码评审覆盖率统计；前者是否构成后者的约束条件，例如环境稳定性约束自动化测试通过率；是否有明确的责任角色负责提供或维护这个输入。支撑连线不需要验证“带动效果”，但必须写清输入来源和责任人，否则指标树会变成无人认领的图。

两类关系在同一棵树上的表达方式

建议用不同箭头类型区分：因果连线用实线箭头，支撑连线用虚线箭头。每条连线至少标注四个字段：关系类型、判断依据（机制解释或输入说明）、验证方式（历史回溯、试点或暂不验证）、责任人。标注直接写在连线上或放在指标树的连线清单里，两者保持一一对应，方便评审时逐条核对。

常见误判

第一类是把统计相关当因果。两个指标同时上升，可能都受第三个因素影响，例如团队规模扩大同时带来交付量和缺陷数上升，二者之间并无因果。第二类是把并列指标当支撑。同一层的两个指标只是分类维度不同，不存在输入输出关系。第三类是把约束条件当驱动因素。约束决定指标能否达成，不推动指标变化，应画成支撑连线并注明约束属性。

判定问题	通过标准	标注写法
前者变化是否会带动后者变化，方向是否明确？	方向单一，反向传导不成立或明显减弱	因果；箭头由因指向果
能否说清影响路径？	有一句可复述的机制解释，涉及具体动作或环节	因果；依据：机制解释一句话
能否用数据或试点检验？	有历史数据可回溯，或可设计小范围试点	因果；验证方式：回溯/试点，责任人与时间
前者是否为后者提供输入、资源或约束？	能指出具体输入项或约束条件	支撑；输入来源：××数据/××资源
是否有角色对输入负责？	写明提供或维护该输入的角色	支撑；责任角色：××
两者是否只是同层并列或共同受第三因素影响？	无法给出方向与机制	不连线，或标注“相关，待验证”

从研发效能目标拆出指标树的四步操作

建树从目标开始，到连线标注结束，每一步都有明确输入和完成标志。四步可以在一到两次工作坊内完成初稿，验证环节放在连线之后单独安排。

第一步：确定顶层结果目标及其口径

输入是业务方或研发负责人对效能改进的期望，例如缩短交付周期、提升交付质量或改善资源效率。动作是把期望转成一到三个结果层指标，并写清口径：统计对象、时间窗口、计算公式、数据来源。输出是结果层指标卡，每张卡包含名称、口径、当前基线值和目标值。完成标志是所有干系人对口径无歧义，且每个指标都有可采集的数据来源。口径不唯一时先解决口径，不进入下一步。

第二步：拆出驱动层指标并写出假设

输入是结果层指标卡。动作是针对每个结果指标，提出“哪些因素变化会带动它”的假设，每个假设对应一个驱动层指标，并写出一句机制解释。例如“提高需求评审一次通过率，可以减少返工，从而缩短需求交付周期”。输出是驱动层指标清单和假设说明，每条假设标注初步判断是因果还是支撑。完成标志是每个结果指标至少有一条驱动假设，且每条假设都能被复述和质疑。

第三步：落到过程层可采集指标

输入是驱动层指标与假设。动作是把每个驱动指标进一步落到团队日常可采集的过程数据，例如评审记录、构建记录、缺陷记录、发布记录，并确认采集方式与更新频率。输出是过程层指标清单，标注数据来源、采集频率和责任人。完成标志是每个过程指标都能在现有工具或流程中取到数据，取不到的要明确补采集方案或从树中移除。

第四步：连线并标注因果或支撑

输入是三层指标清单。动作是按第一节的判定标准逐对连线，因果用实线、支撑用虚线，每条连线填写判断依据、验证方式和责任人。输出是一张带标注的指标树和一份连线清单。完成标志是所有连线都有类型和依据，没有无标注的连线，也没有孤立指标。此后安排验证：关键因果连线用历史数据回溯或小范围试点检验，无法验证的连线删除或标记为待验证。

指标树定稿后，目标、口径和验证任务需要有承载的地方。ONES 研发效能管理解决方案对交付效率、交付质量、进度情况、资源效率等效能数据进行展示，形成“量化—实施—分析—改进”的闭环；在梳理阶段，可以把结果层目标、指标口径说明和每条因果连线的验证任务分别落到目标、文档与工作项中，让验证责任人和完成时间可追踪。ONES Performance 能将业务数据统一展示，便于在验证阶段对照指标变化。具体能力范围以实际部署与套餐为准。

角色分工与各层交付物

指标树涉及定目标、定口径、供数据和做验证四类工作，角色不清会导致口径反复变更或连线无人验证。下表给出常见分工，团队规模较小时可由一人兼任多个角色，但职责边界仍需写清。

角色	职责边界	在指标树上的交付物
研发负责人	确定效能改进方向，确认结果层目标与优先级，对目标变更做最终决策	结果层指标卡、目标值与优先级说明
效能度量负责人	维护指标口径与指标树结构，组织连线评审，跟踪因果假设验证	指标口径字典、连线清单、验证计划与结论记录
团队负责人	提供过程层数据来源，确认过程指标在团队内可采集、可执行	过程指标清单、数据来源说明、试点反馈
数据负责人	保障数据采集质量与更新频率，提供历史数据支持回溯验证	数据质量说明、历史数据提取结果

评审与变更的触发点建议明确三类：新增或删除结果层指标时，由研发负责人发起评审；指标口径调整时，由效能度量负责人更新口径字典并通知所有使用方；因果连线验证结论出来后，由效能度量负责人组织复核，决定保留、降级或删除。触发点写进指标树文档首页，避免变更靠口头传递。

一个指标树的梳理示例

以下为演示情景，用于说明标注写法，数据为示意值。某研发团队希望缩短需求交付周期，按四步建树。

结果层指标为“需求交付周期（中位数）”，口径为需求从进入开发到上线的自然日中位数，数据来自需求工作项状态流转记录。驱动层拆出两个指标：“需求评审一次通过率”和“开发阶段返工率”。过程层对应落到“评审意见关闭时长”“构建失败次数”“缺陷 reopen 率”等可采集指标。

连线标注示例：需求评审一次通过率 →（实线，因果）需求交付周期，依据是“评审返工减少，需求在开发前澄清充分，减少中途变更”；验证方式为回溯近两个季度数据，责任人为效能度量负责人。构建失败次数 →（虚线，支撑）开发阶段返工率，输入来源为持续集成构建记录，责任角色为团队负责人。评审意见关闭时长 →（虚线，支撑）需求评审一次通过率，输入来源为评审工作项记录，责任角色为团队负责人。

被证伪的连线：初稿曾画“代码提交频率 →（因果）需求交付周期”，机制解释为提交越频繁交付越快。回溯数据显示两者相关性很弱，提交频率高的需求同样存在长时间等待评审的情况，说明中间环节才是主要影响因素。该连线被删除，改为在驱动层补充“等待评审时长”指标，并重新建立因果假设。这个例子说明，连线被证伪不是失败，而是指标树变得更可信的过程。

上线前的完成检查

指标树定稿后，按以下清单逐项核对，全部通过再作为正式版本发布。检查由效能度量负责人组织，研发负责人和数据负责人参与确认。

• 每条因果连线都有机制解释和验证计划，验证责任人与时间已写明。
• 每条支撑连线都写明输入来源和责任角色，没有只画线不写来源的情况。
• 每个指标的口径唯一，统计对象、时间窗口、计算公式、数据来源四项齐全，且当前可采集。
• 不存在孤立指标，每个指标至少有一条连线；不存在循环依赖，沿箭头方向无法回到起点。
• 结果层指标数量控制在三个以内，驱动层与过程层指标与结果目标有可追溯的对应关系。
• 变更与复审机制已确定：谁发起、谁评审、多久复审一次、验证结论如何记录。
• 待验证连线单独列出，标注计划验证时间，避免长期停留在“待验证”状态。

检查中发现的问题按类型处理：口径问题回到第一步修正，连线缺依据的补写或删除，孤立指标确认是否遗漏上级目标，循环依赖则重新判断方向并拆分指标。完成检查后，指标树进入运行阶段，验证结论和口径变更持续回写到连线清单与口径字典中。

常见问题

指标树里两个指标同时上升，能不能直接画成因果连线？

不能直接画。同时上升可能来自共同的外部因素，例如团队规模扩大同时带来交付量和缺陷数上升，两者之间并没有传导路径。要画因果连线，需要先写出机制解释，说明前者通过哪个具体环节影响后者，再用历史数据回溯或小范围试点观察变化。写不出机制、也检验不了的，先标注为“相关，待验证”，不进入正式因果链。

支撑连线和因果连线在维护上有什么不同？

因果连线需要持续验证，验证结论会决定它保留、降级还是删除；支撑连线主要维护输入来源和责任角色，输入项变了或责任人换了就要更新标注。两类连线都应进入连线清单，与图上的箭头一一对应。评审时先核对支撑连线的输入是否仍然有效，再复核因果连线的验证结论，避免把资源投入在已经失效的输入上。

团队规模小、没有专职效能度量角色时，指标树怎么分工？

可以由一人兼任多个角色，但四类职责仍要写清：谁定结果目标、谁维护口径与连线清单、谁提供过程数据、谁保障数据质量。兼任时建议把口径字典和连线清单放在同一份文档里，变更时同步更新，并在文档首页写明触发评审的条件。角色合并不会改变检查要求，上线前的口径唯一性、连线依据和验证计划仍需逐项确认。

因果假设验证失败后，指标树要怎么调整？

先看失败原因。如果是中间环节缺失，补充真正起作用的驱动指标并重建假设，例如把“代码提交频率”换成“等待评审时长”；如果是口径问题，回到第一步修正统计对象或时间窗口；如果方向判断错误，调整箭头方向或改为支撑关系。调整后更新连线清单，记录证伪依据和调整时间，让后续评审能看到这段判断过程。

指标树定稿后多久复审一次比较合适？

复审频率取决于业务变化速度和待验证连线的数量。建议在指标树发布时确定固定复审周期，并在三类情况下触发临时复审：结果层目标调整、指标口径变更、关键因果连线验证结论出来。复审时重点看口径是否仍可采集、连线依据是否仍成立、待验证连线是否已超期。复审结论回写到连线清单和口径字典，保持文档与图上标注一致。