需求交付跟踪的检查指标可以归为实现进展、开发状态、延期反馈三类，分别回答“需求有没有往前走”“开发有没有卡住”“偏差有没有被及时说出来”。要让这些数字可用，每项指标都要固定统计对象、时间窗、分母和状态口径；本文给出指标清单、取数来源、计算公式、一个迭代的演算示例，以及解读时的限制。
要点总览（TL;DR）
- 需求交付跟踪的检查指标分三类：实现进展（需求状态分布、已进入开发比例、在途需求数）、开发状态（开发中停留时长、阻塞需求数、提测或合并进度）、延期反馈（按期交付率、延期需求占比、平均计划偏差天数、延期原因分布）。
- 每项指标在定义时固定统计对象（需求条目）、时间窗（按周或按迭代）、分母（当期应交付需求数）和状态口径，否则跨期数字不可比。
- 核心公式：按期交付率 = 按期交付需求数 ÷ 应交付需求数 × 100%；平均计划偏差天数 = Σ(实际完成日期 − 计划完成日期) ÷ 已交付需求数；开发中停留时长取中位数或均值。
- 无计划完成时间的需求单列、不并入按期交付率分母；分母为零时标注“本期无应交付需求”，不输出百分比。
- 指标用于发现偏差、触发沟通，不设通用达标线，也不宜直接作为个人绩效结论。
跟踪检查要回答哪三个问题
需求交付跟踪的检查指标服务于三个判断动作，指标设计围绕这三个问题展开，避免收集了一堆数字却不知道该看什么。
| 检查目标 | 要回答的问题 | 主要使用者 | 触发的判断动作 |
|---|---|---|---|
| 实现进展 | 需求是否按计划向前推进，有多少还停在排队状态 | 需求负责人、项目管理者 | 判断排期是否被消化，识别长期未启动的需求并确认优先级 |
| 开发状态 | 进入开发的需求是否卡住，卡在哪个环节 | 开发负责人、需求负责人 | 发现停留时间异常或阻塞的需求，安排澄清、拆解或资源调整 |
| 延期反馈 | 偏差是否被及时暴露，延期集中在哪些原因 | 项目管理者、需求负责人 | 核对计划变更记录，与相关角色沟通延期原因和补救安排 |
三类目标之间存在递进关系：进展指标说明需求在流动，开发状态指标说明流动是否顺畅，延期反馈指标说明偏差是否被记录和暴露。只看其中一类容易得出片面结论，例如在途需求数正常但开发中停留时长普遍偏长，说明需求在开发环节积压；按期交付率尚可但延期原因长期空白，说明反馈机制没有真正运转。
这些指标的使用边界需要在开始统计前说清楚：它们用于发现偏差并触发沟通，帮助团队定位需要介入的需求和环节。把单期指标直接对应到个人评价，会诱导填报行为变形，例如提前修改计划完成时间、拆分需求以改变分母，最终让数据失去参考价值。
指标清单与统计范围怎么定
指标清单按三类组织，每项指标在定义时就写清分子、分母、时间窗和单位，形成一张可以直接对照取数的表。统计对象统一为需求条目，时间窗按周或按迭代取数，同一篇文章内不混用两种时间窗做趋势比较。
| 类别 | 指标 | 定义 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|---|
| 实现进展 | 需求状态分布 | 期末各状态的需求条目数量及占比 | 各状态需求数 | 统计范围内需求总数 | 期末快照 | 条、% |
| 实现进展 | 已进入开发比例 | 已进入开发及之后状态的需求占比 | 状态为开发中及之后的需求数 | 当期应交付需求数 | 按周或按迭代 | % |
| 实现进展 | 在途需求数 | 期末处于开发中、待提测等未完成状态的需求数 | 未完成状态需求数 | 不适用 | 期末快照 | 条 |
| 开发状态 | 开发中停留时长 | 需求在开发中状态停留的天数，取中位数或均值 | 离开开发中日期减进入开发中日期 | 本期离开开发中状态的需求数 | 按周或按迭代 | 天 |
| 开发状态 | 阻塞需求数 | 期末带有阻塞标记的需求条目数 | 阻塞标记为真的需求数 | 不适用 | 期末快照 | 条 |
| 开发状态 | 提测或合并进度 | 已提测或代码已合并的需求占比 | 已提测或已合并的需求数 | 当期进入开发的需求数 | 按周或按迭代 | % |
| 延期反馈 | 计划偏差天数 | 实际完成日期与计划完成日期的差值 | 实际完成日期减计划完成日期 | 逐条计算，汇总取平均 | 按周或按迭代 | 天 |
| 延期反馈 | 按期交付率 | 按计划完成时间交付的需求占比 | 按期交付需求数 | 当期应交付需求数 | 按周或按迭代 | % |
| 延期反馈 | 延期需求占比 | 延期交付的需求占比 | 延期需求数 | 当期应交付需求数 | 按周或按迭代 | % |
| 延期反馈 | 延期原因分布 | 按原因分类统计的延期需求数 | 各原因类别的延期需求数 | 延期需求总数 | 按周或按迭代 | 条、% |
状态定义表是指标可比的前提。团队需要事先约定每个状态的进入和退出条件，例如“待排期”指已进入需求池但尚未确定计划完成时间，“开发中”指开发人员已开始编码，“待提测”指开发自测完成等待测试介入，“已交付”指通过验收并上线或交付使用。状态边界写清楚后，同一需求在不同周期的归类才一致，跨期对比才有意义。
分母的选择直接影响百分比的含义。按期交付率和延期需求占比都以“当期应交付需求数”为分母，即计划完成时间落在本期时间窗内的需求条目，包括本期实际完成的和本期未完成的。用“本期完成的需求数”作分母会掩盖未完成部分，让按期交付率虚高。
数据从哪里取、怎样保证可核验
指标能否被复核，取决于原始记录是否完整。取数来源应覆盖四类记录：需求工作项的状态变更记录、计划完成时间字段及其修改历史、阻塞标记、提测或代码合并记录。每类记录对应一组证据要求。
- 状态变更留痕：每次状态流转记录操作时间和操作人，指标计算时以记录时间为准，不依赖人工回忆。
- 计划时间有版本：计划完成时间字段保留修改历史，按期交付率按“当时有效的计划时间”判断，事后调整计划的需求在变更记录中可查。
- 延期原因有填写人：延期需求在关闭或交付时填写原因分类和说明，原因分布才能追溯到具体条目。
- 阻塞标记可追溯：阻塞标记记录设置时间和解除时间，阻塞需求数取期末快照，同时可统计本期发生过的阻塞次数。
缺失值需要单独处理。没有计划完成时间的需求不并入按期交付率分母，而是单列为“未排期需求”并在报告中注明数量。这类需求如果数量较大，说明排期环节本身存在缺口，应作为进展问题单独讨论，而不是混入交付率计算。
有两种情形会让前后期数据不可直接比较：一是状态定义中途变更，例如把“待提测”并入“开发中”，状态分布和停留时长都会跳变；二是需求拆分或合并导致条目数变化，分母随之改变。遇到这两种情况，应在报告中标注口径变更时间点，变更前后的数据分段呈现，不做连续趋势解读。
在工具层面，需求工作项的状态流转、计划完成时间、阻塞标记和提测合并记录需要落在同一套工作项体系中，指标才能按条目复算。ONES 通过统一的需求池、工单与任务看板同步状态与信息，便于追溯需求与问题；系统会记录和统计工作项滞留时间等过程数据，可作为开发中停留时长的取数基础。按期交付率、延期原因分布等具体报表是否已有现成形态，需要按团队实际配置确认，取数时以工作项明细为准。
指标怎么算：公式与步骤
以下公式均以需求条目为统计单位，时间窗为周或迭代，计算时先取明细再汇总，保留原始明细以便复核。
按期交付率 = 时间窗内按计划完成时间交付的需求数 ÷ 时间窗内应交付需求数 × 100%。判断“按期”的标准是实际完成日期不晚于当时有效的计划完成日期。
延期需求占比 = 延期需求数 ÷ 应交付需求数 × 100%。延期需求指实际完成日期晚于计划完成日期的需求，以及时间窗结束时仍未完成且计划完成时间已过的需求。
平均计划偏差天数 = Σ（实际完成日期 − 计划完成日期）÷ 已交付需求数，单位：天。该公式对按期和延期需求一并计算，按期需求产生负值或零值，结果反映整体偏差方向；如果只想看延期幅度，可单独对延期需求求平均。
开发中停留时长 = 需求离开开发中状态的日期 − 进入开发中状态的日期，单位：天。逐条计算后取中位数或均值，中位数受个别长期停留需求的影响较小，适合作为常规观察值；均值可用于评估总体投入。
计算步骤建议固定为四步：第一步，按时间窗筛出应交付需求清单，锁定分母；第二步，逐条读取状态变更记录和计划时间版本，判定按期、延期或未完成；第三步，按公式计算各项指标，同时保留每条需求的判定结果；第四步，对分母为零的情况标注“本期无应交付需求”，不输出百分比，避免出现无意义的 0% 或空值。
按周或按迭代滚动计算时，同一需求可能跨期出现。处理规则是：分母按计划完成时间归属期次，不按实际完成时间归属，这样每期分母稳定，跨期比较才有基础。跨期未完成的需求在后续期次继续计入应交付需求，直到完成或被取消。
一个迭代的计算示例
以下为演示情景，用于说明取数和计算过程，数字为假设值。
某迭代应交付需求 20 条，其中按期交付 15 条，延期 3 条，取消 2 条。按期交付率 = 15 ÷ 20 = 75%；延期需求占比 = 3 ÷ 20 = 15%。取消的 2 条需求在分母中的处理需要事先约定：若取消发生在计划完成时间之前且经确认，可从分母中剔除并在报告中注明，剔除后按期交付率为 15 ÷ 18 ≈ 83.3%；若保留在分母中，则维持 75%。两种口径都可以用，关键是同一报告内保持一致。
3 条延期需求的计划偏差分别为 2 天、5 天、9 天，平均计划偏差 = （2 + 5 + 9）÷ 3 ≈ 5.3 天。若把 15 条按期需求一并计入，按期需求偏差为 0 或负值，平均偏差会被拉低，因此报告中应分别给出“延期需求平均偏差”和“全部已交付需求平均偏差”两个数，避免读者误解。
开发中停留时长方面，假设本期离开开发中状态的需求有 18 条，停留天数排序后中位数为 4 天，均值为 6.5 天。中位数与均值差距较大，说明存在个别长期停留的需求，应回到明细中定位这些条目，查看是否带有阻塞标记或长期未提测。
示例结论：延期集中在少数需求，延期占比 15% 但平均偏差超过 5 天，说明问题不在普遍性拖延，而在个别需求的计划或执行出现较大偏离。下一步应查看延期原因分布，确认是需求变更、依赖等待还是估算偏差，再决定是否调整排期或补充资源。
结果怎么解读、有哪些限制
按期交付率是最容易被误读的指标。需求拆分会让条目数增加，计划完成时间调整会改变“按期”的判定基准，两者都能在不改善实际交付的情况下改变比率。解读时应同时查看计划时间变更记录和需求条目数变化，确认比率变化来自交付改善还是口径变化。
延期反馈类指标反映的是偏差是否被及时记录和暴露，不直接说明延期的原因。延期原因分布填得完整，才能进一步分析；如果原因字段大量为空，延期占比再精确也只能说明“有延期”，无法支撑改进动作。此时应先补反馈机制，再谈指标优化。
三类指标需要合看。实现进展指标显示需求在流动，开发状态指标显示流动是否顺畅，延期反馈指标显示偏差是否被捕捉。单看按期交付率可能漏掉在途积压，单看停留时长可能漏掉计划本身不合理的问题。建议每期报告固定呈现三类指标各至少一项，并附明细入口。
达标线应结合团队历史基线确定，不设通用数值。一个新组建的团队和一个稳定运行多年的团队，按期交付率的合理区间不同；同一团队在需求高峰期和常规期的表现也不同。比较有意义的做法是与自身前几个周期的基线对比，观察趋势和异常点，而不是套用外部标准。
指标用于触发沟通与改进，不用于简单排名。当指标与个人评价挂钩时，填报行为容易偏向有利于数字的方向，例如提前标记完成、频繁调整计划时间、把需求拆小以降低单条偏差。保持指标的过程属性，把讨论重点放在具体需求和具体阻塞上，数据才能持续可信。ONES 支持通过敏捷看板管理任务状态、在站立会议中对齐迭代进度与风险，并提供燃尽图等工具辅助观察进度，这些能力可以帮助团队把指标讨论落到具体工作项上，而不是停留在汇总数字层面。
常见问题
需求在统计期内被取消，分母要不要调整？
两种口径都可以用，关键是同一份报告内保持一致。若取消发生在计划完成时间之前且经过确认，可以从应交付需求分母中剔除，并在报告中注明剔除条数；若保留在分母中，按期交付率会因取消需求而偏低。建议在指标定义阶段就写明取消需求的处理规则，并在每期报告中保持同一做法，避免因口径切换造成比率跳变。
计划完成时间被中途修改过，按期交付率按哪个时间判断？
按“当时有效的计划完成时间”判断，即需求交付时生效的那一版计划时间，同时保留修改历史。这样判定结果可追溯到具体版本，也能在解读时看到计划调整对指标的影响。如果团队希望观察计划稳定性，可以另外统计本期计划完成时间发生变更的需求条数，作为按期交付率的辅助信息，而不是直接否定按期交付率本身。
开发中停留时长用中位数还是均值？
常规观察建议用中位数，个别长期停留的需求对中位数影响小，能更稳定地反映多数需求的开发节奏；均值适合评估总体投入和识别长尾。两者差距明显时，说明存在少数停留时间异常的需求，应回到明细中定位这些条目，查看是否带有阻塞标记或长期未提测，再决定是否需要介入。
延期原因字段大量为空，指标还能用吗？
延期占比、平均偏差天数仍可计算，但只能说明“有延期”，无法支撑原因分析和改进动作。这种情况下应先把反馈机制补起来：约定延期需求在关闭或交付时填写原因分类和说明，明确填写人，再逐步积累可分析的数据。在原因数据完整之前，解读报告时应注明原因分布不完整，避免把空白字段当作“无原因”。
跨期未完成的需求在后续周期怎么计入？
分母按计划完成时间归属期次，不按实际完成时间归属。计划完成时间落在本期但期末仍未完成的需求，计入本期应交付需求，同时判定为延期；在后续期次中，该需求继续按原计划完成时间归属，直到完成或被取消。这样每期分母稳定，跨期比较才有基础。如果需求在跨期过程中被拆分或合并，条目数发生变化，应在报告中标注口径变更时间点，变更前后分段呈现。
