跨版本依赖满足率和版本按期率都按“版本内已承诺的条目”计算：前者看统计期内到期的跨版本依赖有多少按约定日期被承接，后者看计划发布的版本有多少按计划基线发布。两个指标要能复算，前提是先统一依赖登记字段、版本计划基线和完成判定标准。下文给出公式、取数步骤、季度算例和解读边界，并说明如何用工作项与文档把口径固定下来，ONES 可作为承载依赖与版本计划记录的协作工具。
要点总览（TL;DR）
- 跨版本依赖满足率=统计期内按约定交付日期满足的跨版本依赖条数÷统计期内到期应满足的跨版本依赖总条数，按季度或版本波次统计。
- 版本按期率=按计划发布日期基线发布的版本数÷统计期内计划发布的版本总数；按期判定以基线日期为准，基线调整与执行延期分开记录。
- 统计前先统一依赖登记字段、版本计划基线和完成判定标准；分母为零时记为“不适用”，不写0%。
- 结果需结合资源冲突次数、依赖变更次数等过程指标解读，样本量小或口径不一致时只做趋势描述，不下排名结论。
- 依赖以工作项登记并关联提出方与承接方版本，版本计划基线以文档留存变更记录，统计视图按状态与日期字段汇总。
统计这两个指标要回答什么判断
这两个指标服务于两个具体判断：多版本并行时，前置版本对后置版本的依赖是否被按时承接；版本对外承诺的发布日期是否被兑现。前者衡量依赖承接的可靠性，后者衡量版本承诺的兑现度。两者合起来，能帮助规划者发现协同断点出现在哪里——是依赖没有按期交付，还是版本范围与日期基线频繁变化。
评估对象是版本计划与跨版本依赖本身。发布执行、发布准入和回滚流程属于另一类度量，不在本文范围内。指标结果用于改进规划协同，例如调整依赖约定日期、提前识别资源冲突、收紧范围变更审批；单看一个季度的满足率或按期率，不能证明某个团队能力强或弱，样本量小、依赖数量少时尤其如此。
指标定义、统计范围与分母口径
两个指标都采用“分子÷分母”的比率形式，分母限定为统计期内已承诺且到期的条目，避免把尚未到期的依赖或未进入发布窗口的版本提前计入。下表给出完整定义。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 跨版本依赖满足率 | 满足条数 ÷ 到期应满足依赖总条数 | 统计期内按约定交付日期满足的跨版本依赖条数 | 统计期内到期应满足的跨版本依赖总条数 | 按季度或版本波次 | 条 |
| 版本按期率 | 按期发布版本数 ÷ 计划发布版本总数 | 按计划发布日期（或计划里程碑日期）发布的版本数 | 统计期内计划发布的版本总数 | 按季度或版本波次 | 个 |
纳入规则：依赖须在统计期内到达约定交付日期，且提出方与承接方版本均已登记；版本须在统计期内处于计划发布状态，并有明确的计划基线日期。排除规则：统计期开始前已满足的依赖、统计期结束后才到期的依赖、统计期内被正式取消且留有变更记录的版本，均不进入分母。
分母为零时，该指标记为“不适用”，不写 0%。统计期内没有到期依赖，说明该季度不存在可评估的依赖承接行为；写成 0% 会被误读为承接全部失败。报告中注明“不适用”及原因，并与真实低值区分。跨季度比较时，若两个季度的版本范围、依赖登记粒度或完成判定标准不同，结果不可直接比较，应先说明口径差异。
依赖与版本计划需要登记哪些字段
统计数据来自两张基础台账：依赖台账和版本计划基线。字段不全时，指标无法复算，也无法解释波动原因。下表列出最低必填字段。
| 台账 | 字段 | 用途 |
|---|---|---|
| 依赖台账 | 提出方版本、承接方版本 | 确定依赖方向，支持按方向拆分 |
| 依赖台账 | 依赖内容 | 说明交付物，便于评审时核对 |
| 依赖台账 | 约定交付日期 | 判定是否到期、是否按期满足 |
| 依赖台账 | 实际满足日期 | 计算是否满足及提前/延迟天数 |
| 依赖台账 | 状态 | 区分未开始、进行中、已满足、已取消 |
| 依赖台账 | 变更记录 | 记录约定日期调整及原因 |
| 版本计划 | 计划发布日期基线 | 按期判定的基准 |
| 版本计划 | 实际发布日期 | 计算延期天数 |
| 版本计划 | 范围变更记录 | 区分计划变更与执行延期 |
完成判定标准要事先写清：依赖状态为“已满足”且实际满足日期不晚于约定交付日期，才算按期满足；版本实际发布日期不晚于计划基线日期，才算按期发布。状态不明或实际日期缺失的条目，单独列入“待核实”清单，不计入分子，但在报告中披露条数，避免分子被低估却无人知晓。字段缺失的依赖不直接删除，保留在台账中并标注缺失原因，便于后续补录和口径复盘。
按什么步骤计算与核对
计算流程分五步，每步都有明确产物，便于交接和复核。
- 锁定统计期与版本清单。确定季度或版本波次的起止日期，导出该期间计划发布的版本清单和到期依赖清单，形成统计底表。
- 逐条判定依赖是否到期、是否满足。对每条依赖核对约定交付日期是否落在统计期内，再核对实际满足日期与状态，标记“按期满足”“延迟满足”“未满足”“待核实”。
- 判定版本是否按期并记录延期天数。以计划发布日期基线为准，比较实际发布日期，记录延期天数；因基线调整导致的日期变化单独标注为计划变更。
- 汇总计算并做抽样复核。按公式计算两个比率，随机抽取一定比例条目回查原始记录，核对日期、状态与变更记录是否一致。
- 按版本、依赖方向、承接团队拆分。输出分组结果，定位满足率偏低或延期集中的环节，作为规划改进的输入。
复核环节重点检查三类问题：到期判定是否把未到期依赖计入分母；按期判定是否误用了调整后的日期而非基线日期；待核实条目是否被静默剔除。复核记录与统计底表一并留存，下一周期沿用同一口径。
一个季度统计的算例
以下为演示情景，数字仅用于说明计算过程。某季度统计期内，依赖台账共有 12 条跨版本依赖到期，其中 9 条按约定日期满足，2 条延迟满足，1 条状态待核实。满足率分子为 9，分母为 12，满足率为 75%。待核实条目不计入分子，但在报告中注明 1 条待核实。
同期计划发布版本 5 个，其中 4 个按计划基线日期发布，1 个延期 6 天发布。按期率为 4÷5＝80%。延期版本若因范围变更调整过基线，则需在报告中单列：基线调整后的日期不作为按期判定依据，但调整次数计入过程指标。
若另一团队该季度没有到期依赖，其依赖满足率记为“不适用”，不参与横向排名。按承接团队拆分后，可能看到 A 团队承接 7 条、满足 6 条，B 团队承接 5 条、满足 3 条，结合依赖变更次数和资源冲突记录，判断差异来自承接能力还是约定日期本身偏紧。
结果怎么解读，哪些限制要说明
满足率高但依赖数量少时，结论只能作为参考。3 条依赖满足 3 条是 100%，与 30 条满足 27 条的 90% 含义不同，前者样本太小，不足以说明承接稳定。报告中应同时给出分子分母，避免只报比率。
按期率受范围变更影响明显。计划基线调整导致的日期后移属于计划变更，执行过程中未按基线完成属于执行延期，两者要分开统计。把计划变更混入执行延期，会高估执行问题；把执行延期归因于计划调整，会掩盖真实风险。解读时配合资源冲突次数、依赖变更次数、依赖平均承接周期等过程指标，判断指标波动来自协同断点还是口径变化。
数据口径不一致时结论不可比。依赖登记粒度不同、完成判定标准不同、统计期起止不同，都会让两个季度的数字失去可比性。跨团队比较前先对齐口径，无法对齐时只做趋势描述，不下排名结论。指标反映依赖承接与版本承诺的兑现情况，不能单独作为团队绩效结论。
用工作项和文档把统计口径固定下来
口径要长期可复算，需要把登记动作落到日常协作载体上。依赖以工作项登记，每条依赖关联提出方版本与承接方版本，约定交付日期、实际满足日期和状态作为工作项字段维护，日期调整时更新变更记录。版本计划基线以文档或版本对象留存，计划发布日期、实际发布日期和范围变更记录在同一处维护，评审时对照基线核对。
统计视图按状态与日期字段汇总，按版本、依赖方向和承接团队分组输出，避免每次统计临时手工整理。版本规划评审和跨团队交接时，把依赖台账与版本基线作为核对材料，确认到期依赖是否已登记、基线变更是否留痕。ONES 的工作项与文档可以承载这类依赖登记和版本计划记录，使统计所需字段在协作过程中自然沉淀，减少事后补录带来的口径偏差。
常见问题
统计期内没有到期依赖，满足率应该写0%还是空着？
记为“不适用”，并在报告中注明原因，例如“本季度无到期跨版本依赖”。写成0%会被读成承接全部失败，与实际情况不符。同理，统计期内没有计划发布的版本时，版本按期率也记为“不适用”。跨季度比较时，把“不适用”的季度单独标注，不参与比率趋势计算。
计划发布日期调整过，版本按期率该按哪个日期判定？
按期判定以计划发布日期基线为准，调整后的日期不作为按期依据。因基线调整导致的日期后移属于计划变更，需在报告中单列调整次数和原因；执行过程中未按基线完成属于执行延期。两类情况分开记录，才能避免把计划变更混入执行问题，或把执行延期归因于计划调整。
依赖状态显示已满足但实际日期缺失，算不算满足？
不算入分子，单独列入“待核实”清单，并在报告中披露条数。这类条目保留在台账中，标注缺失原因，安排补录后再纳入下一周期统计。直接删除会让分母缩水、比率虚高；静默剔除则让读者无法判断数据质量。
两个季度的满足率能直接比较吗？
先对齐口径再比较：依赖登记粒度、完成判定标准、统计期起止日期是否一致。口径一致时可以做趋势描述；口径不一致时只说明差异来源，不下“变好”或“变差”的结论。跨团队横向比较同理，承接依赖条数少的团队，比率波动天然更大，应同时给出分子分母。
这两个指标能直接用于团队绩效考核吗？
不建议单独使用。指标反映依赖承接与版本承诺的兑现情况，受依赖数量、范围变更频率和登记质量影响。样本量小、口径未对齐时，比率容易被误读。更合适的用法是作为规划评审的输入，配合资源冲突次数、依赖变更次数等过程指标，定位协同断点后再讨论改进动作。
