依赖按期闭环率与超期时长都建立在同一份跨项目依赖清单上：先固定承诺闭环日期、实际闭环日期和统计时间窗，再分别计算“按期闭环数÷应闭环总数”和“实际与承诺的日期差”。两个指标解决的是不同问题，闭环率看结果比例，超期时长看拖延程度，需要配合升级次数和超期分布一起解读，才能判断跨项目依赖跟踪是否真正有效。
要点总览（TL;DR）
- 依赖按期闭环率 = 统计期内按承诺闭环日期完成闭环的跨项目依赖数 ÷ 承诺日期落在统计窗口内的应闭环依赖总数 × 100%，分子分母必须来自同一集合。
- 超期时长按依赖逐条计算：已闭环取实际闭环日期减承诺闭环日期，未闭环取统计截止日减承诺闭环日期，负值按0计入或单独标注提前量，计时单位全周期统一。
- 超期时长建议同时给出平均值和中位数：平均值反映总体超期负担，中位数反映典型依赖的超期水平，两者差距大说明超期集中在少数依赖上。
- 升级次数按依赖维度统计升级记录条数，同一依赖多次升级分别计数，需结合超期分布判断是协同压力增大还是登记口径变化。
- 指标要组合解读并先建立2至3个周期的基线，分母为零时闭环率标注为不适用，口径调整需在报表中注明影响。
评估目标：跨项目依赖跟踪要回答什么
跨项目依赖跟踪的度量对象是项目与项目之间的依赖关系，例如A项目的接口交付是B项目上线的前置条件。单项目内部的任务先后顺序属于排期管理，不在本文的计算范围内。把对象限定清楚，才能避免把普通任务延误混入跨项目协同指标。
这套指标主要回答三个问题：依赖是否在约定时间内完成闭环，超期依赖拖延了多久，协同过程中升级机制被触发了多少次。它服务于发现闭环效率和超期风险，为项目集经理或PMO提供调整协同方式的依据，不用于评价某个人的绩效。依赖能否按期闭环，往往取决于双方排期、资源到位情况和接口确认速度，把结果直接归因到个人会扭曲登记行为。
评估周期建议与项目集的节奏对齐，按月或按迭代统计，并保持周期长度稳定。责任角色上，项目集经理负责确认依赖清单和承诺日期，PMO负责汇总计算与趋势对比，承接方负责更新实际闭环状态。角色分工明确，数据才有稳定的来源。
指标与范围：闭环率、超期时长与升级次数
三个核心指标各有分工，定义和单位需要在统计前写清楚，避免不同周期之间口径漂移。
| 指标 | 定义 | 单位 | 回答的问题 |
|---|---|---|---|
| 依赖按期闭环率 | 统计期内按承诺闭环日期完成闭环的跨项目依赖数 ÷ 统计期内应闭环的跨项目依赖总数 × 100% | 百分比 | 约定时间内完成的依赖占多大比例 |
| 超期时长 | 依赖实际闭环日期与承诺闭环日期的差值；未闭环依赖取统计截止日与承诺日期的差值 | 工作日或自然日，全周期统一 | 超期依赖平均或典型拖延了多久 |
| 升级次数 | 统计期内依赖维度升级记录的总条数，同一依赖多次升级分别计数 | 次 | 协同压力有多大，升级机制是否被使用 |
统计范围要同时界定项目范围和依赖状态。项目范围通常取纳入项目集管理的全部项目，跨项目集依赖若纳入统计需单独标注。依赖状态方面，建议纳入“已登记且承诺日期落在统计窗口内”的依赖，包括已闭环和未闭环两类；已取消或经变更后承诺日期移出窗口的依赖，按变更留痕规则处理，不计入当期分母。
数据口径：依赖登记字段与取数规则
指标能否复算，取决于依赖登记是否完整。每条跨项目依赖至少需要以下字段，并明确来源。
| 字段 | 说明 | 取数规则 |
|---|---|---|
| 提出方 | 依赖的需求方项目 | 登记时选择，变更需留痕 |
| 承接方 | 负责交付或响应的一方 | 登记时选择，跨项目必填 |
| 承诺闭环日期 | 双方约定的完成时间 | 登记时确定；变更需记录变更前后日期与原因 |
| 实际闭环日期 | 依赖实际完成闭环的日期 | 状态流转为已闭环时自动或手工写入 |
| 状态 | 待响应、进行中、已闭环、已取消等 | 按统一状态集维护 |
| 升级记录 | 升级时间、触发原因、升级对象 | 每次升级单独记录，便于计数 |
承诺日期是计算的分母基准，必须在登记时约定，后续变更保留历史记录。若直接用最新承诺日期重算历史周期，会导致已超期的依赖“变回按期”，指标失去可比性。分母口径建议固定为：承诺闭环日期落在统计窗口内的跨项目依赖，无论当前是否已闭环。这样分子分母来自同一集合，闭环率才有意义。
缺失值处理需要事先约定。实际闭环日期为空且状态为已闭环的，视为数据异常，退回承接方补录，不参与当期计算并单独列出异常清单。承诺日期为空的依赖不进入分母。日期变更的依赖，以变更后的承诺日期判断是否落在窗口内，同时保留原日期用于分析变更频率。
计算步骤：公式、分母与时间窗
计算按以下顺序执行，每一步的中间结果都应可追溯。
- 确定统计窗口，例如某月1日至月末，并统一计时单位与基准时区。
- 筛选承诺闭环日期落在窗口内的跨项目依赖，形成应闭环集合，即分母。
- 在应闭环集合中，筛出实际闭环日期不晚于承诺闭环日期的依赖，形成按期闭环集合，即分子。
- 按期闭环率 = 按期闭环数 ÷ 应闭环总数 × 100%。
- 逐条计算超期时长：已闭环依赖取实际闭环日期减承诺闭环日期；未闭环依赖取统计截止日减承诺闭环日期。差值为负表示提前闭环，可按0计入或单独标注提前量。
- 对超期时长求平均值与中位数，并统计升级次数。
平均值和中位数的选择取决于分布形态。平均值反映总体超期负担，适合观察资源投入总量；中位数反映典型依赖的超期水平，在存在个别严重超期时更稳健。建议两者同时给出，当两者差距明显时，说明超期集中在少数依赖上，需要单独查看长尾清单。
边界情况需要明确处理。分母为零时，闭环率不输出百分比，标注为“不适用”，避免用0%或100%造成误读。跨时区团队先统一换算到同一基准时区再计算日期差。工作日与自然日口径必须全周期一致，若承诺日期按工作日约定，超期时长也按工作日计算，并在报表中注明。
依赖登记、状态流转和升级记录需要有稳定的承载方式，否则每次统计都要重新核对来源。在ONES中，跨项目依赖可以作为工作项登记提出方、承接方、承诺日期和状态，状态流转到已闭环时记录实际完成时间，升级动作留下记录，项目集经理据此按统一口径导出当期清单并计算上述指标。具体字段配置需结合团队实际的项目集管理方式确定。
算例：一个统计周期的完整计算
假设某项目集统计窗口为某月1日至月末，计时单位为自然日，共登记8条承诺日期落在窗口内的跨项目依赖，其中6条已闭环、2条未闭环。
| 依赖 | 承诺闭环日期 | 实际闭环日期 | 是否按期 | 超期天数 | 升级次数 |
|---|---|---|---|---|---|
| D1 | 5日 | 4日 | 是 | -1（提前） | 0 |
| D2 | 8日 | 8日 | 是 | 0 | 0 |
| D3 | 10日 | 15日 | 否 | 5 | 1 |
| D4 | 12日 | 12日 | 是 | 0 | 0 |
| D5 | 18日 | 30日 | 否 | 12 | 2 |
| D6 | 20日 | 19日 | 是 | -1（提前） | 0 |
| D7 | 25日 | 未闭环 | 否 | 6（截至月末） | 1 |
| D8 | 28日 | 未闭环 | 否 | 3（截至月末） | 0 |
按期闭环率为4 ÷ 8 × 100% = 50%。超期时长按逐条计算后，超期依赖的取值为5、12、6、3天，平均值 = (5+12+6+3) ÷ 4 = 6.5天；中位数取排序后3、5、6、12的中间两值平均，为5.5天。若把提前闭环按0计入全部8条，平均值会变为3.25天，两种口径需在报表中说明，建议超期分析只针对超期依赖计算。
升级次数合计为1+2+1 = 4次，集中在D3、D5、D7三条依赖上。结合数据看，闭环率50%说明一半依赖未在承诺时间内完成，超期中位数5.5天说明典型超期接近一周，D5超期12天且升级2次，是当期最需要复盘的依赖。这组结果可以支撑“协同压力集中在少数依赖上”的判断，但不足以说明跟踪机制本身是否有效，需要与上期数据对比。
解读与限制：如何据此评估跟踪效果
闭环率和超期时长要组合解读。闭环率高但超期中位数偏大，说明多数依赖是勉强按期或少量严重超期拉高了均值；闭环率低但超期时长普遍较短，说明问题更多出在承诺日期设定过紧，而非执行拖延。两种情形对应的改进动作不同，前者要关注长尾依赖，后者要复核承诺日期的合理性。
升级次数反映协同压力，不宜简单视为负面信号。升级次数上升可能是依赖确实受阻、需要更高层级协调，也可能是登记口径变化或团队更愿意主动暴露风险。判断时需要结合超期分布：升级集中在超期依赖上，说明升级机制在发挥作用；升级分散且超期未改善，则要检查升级后的处理是否闭环。
这些指标不能单独作为绩效结论，也不能证明跟踪机制带来了改善。依赖按期完成还受资源、需求变更等外部因素影响，指标只能描述结果分布。建议先积累2至3个统计周期的数据建立基线，再做趋势对比；对比时保持分母口径、计时单位和统计窗口一致，口径调整需在报表中注明并单独说明影响。
常见问题
承诺闭环日期中途变更了，历史周期要不要按新日期重算？
不建议按新日期重算历史周期。承诺日期变更时应保留变更前后日期和原因，历史统计仍以当期登记的承诺日期为准，否则已超期的依赖会被“改回按期”，跨周期数据失去可比性。变更后的日期用于判断该依赖是否落入后续统计窗口，同时可以单独统计变更频率，作为承诺日期设定是否合理的参考。
分母为零的统计周期，闭环率应该写0%还是100%？
两者都不合适，应标注为“不适用”。分母为零意味着当期没有承诺日期落在窗口内的跨项目依赖，闭环率在数学上无定义，写0%会被误读为全部未完成，写100%会被误读为全部按期。报表中保留该周期记录并注明原因，便于解释趋势曲线上的空缺。
提前闭环的依赖，超期时长按负数还是0计入平均值？
两种口径都可以，关键是全周期保持一致并在报表中说明。若目标是衡量超期负担，建议只对超期依赖计算平均值和中位数，提前闭环单独统计提前量；若把提前量按0计入全部依赖，平均值会被稀释，例如算例中仅对超期依赖计算为6.5天，按全部8条计入则为3.25天，两种结果解读含义不同。
升级次数多，是不是说明依赖跟踪做得不好？
不能直接这样判断。升级次数上升可能是依赖确实受阻、需要更高层级协调，也可能是团队更愿意主动暴露风险，或登记口径发生了变化。判断时要看升级是否集中在超期依赖上：集中说明升级机制在发挥作用；分散且超期没有改善，则要检查升级之后的处理是否真正闭环。跨周期对比时还需确认升级的判定标准没有改变。
跨时区团队和工作日口径混用，计算时怎么处理？
先统一再计算。跨时区团队把承诺日期和实际闭环日期换算到同一基准时区，再求日期差；工作日与自然日的选择在统计前固定，若承诺日期按工作日约定，超期时长也按工作日计算，并在报表中注明。同一统计周期内不要混用两种单位，否则平均值和中位数都不可比。
