识别需求交付预期偏差，先要统一两个日期口径：每条需求的承诺交付日和实际交付日。有了这两个日期，才能计算偏差天数、偏差率和按期交付率，判断预期准不准；再通过复盘回溯偏差产生的时间点和原因，把结论落到承诺规则与过程检查点上。下文给出可复算的指标定义、取数规则、识别与复盘步骤，并用一个迭代的示例演示完整计算。
要点总览（TL;DR）
- 识别需求交付预期偏差，先统一两个日期口径：每条需求的首次承诺交付日、当前承诺交付日和实际交付日，避免只留最后一次承诺掩盖延期。
- 核心指标包括偏差天数（实际交付日−承诺交付日，正为延期、负为提前）、偏差率（偏差天数÷承诺周期天数，分母为零时单独标记）和按期交付率（按期交付需求数÷统计期内应交付需求数，明确取消与合并需求处理）。
- 识别偏差按时间窗导出清单并计算指标，再按偏差幅度分层，显著偏差逐条复盘，轻微偏差批量归因。
- 复盘时回溯偏差产生的时间点（承诺时、执行中、交付前），按估算偏差、范围变更、依赖阻塞、资源冲突归类，形成承诺规则与检查点调整项并指定责任人。
- 偏差率反映承诺准确性而非交付能力，样本量小或需求粒度不一致时数据不可比，提前交付过多也可能说明承诺保守，不设通用达标线。
评估目标：判断预期准不准，而不只是看有没有延期
需求交付预期偏差评估的对象是单条需求的承诺交付日与实际交付日之间的差距。评估关注承诺是否兑现、承诺本身是否可靠，延期只是其中一种表现。提前交付同样属于偏差，也需要记录和分析。
这项评估要回答三个问题。第一，偏差多大：单条需求差几天，整体偏差率和按期交付率是多少。第二，偏差集中在哪：是集中在某类需求、某个团队、某个时间段，还是集中在承诺周期的某个长度区间。第三，偏差由什么造成：是估算不准、范围变更、依赖阻塞，还是资源冲突。三个问题层层递进，只回答第一个，评估就停留在统计层面。
评估的产出是两份材料：一份需求偏差台账，逐条记录承诺日、实际交付日、偏差天数和原因类别；一份复盘结论，说明偏差的主要来源和对应的承诺规则、检查点调整项。台账用于持续积累数据，复盘结论用于下一轮排期时修正承诺方式。评估周期建议与迭代节奏对齐，每个迭代或每月汇总一次，避免周期过长导致原因回溯失真。
指标与范围：偏差天数、偏差率与按期交付率怎么定义
三个核心指标分别回答“差多少天”“差的比例多大”“有多少条按期交付”。定义时需要把公式、单位、分子分母写清楚，保证不同人用同一份数据能算出同一结果。
| 指标 | 公式 | 单位 | 分母口径与处理规则 |
|---|---|---|---|
| 偏差天数 | 实际交付日 − 承诺交付日 | 天 | 正数为延期，负数为提前，零为按期；按自然日计算，跨节假日时需在口径说明中注明是否扣除 |
| 偏差率 | 偏差天数 ÷ 承诺周期天数 | 百分比 | 承诺周期天数 = 承诺交付日 − 承诺起始日；分母为零（承诺当日交付）时单独标记，不参与比率汇总，只计入偏差天数统计 |
| 按期交付率 | 按期交付需求数 ÷ 统计期内应交付需求数 | 百分比 | 分子为偏差天数等于零的需求数；分母为统计时间窗内承诺交付日落入该窗口的全部需求，含延期后仍未交付的需求 |
统计范围需要事先约定三件事。需求层级上，明确统计到哪一层，例如只统计产品需求，子任务不计入，避免同一件事被重复计算。统计时间窗上，按期交付率按承诺交付日落入窗口来取数，偏差率按实际交付日落入窗口来取数，两者口径不同，报表中要分别标注。需求状态上，明确取消和合并的需求如何处理：取消的需求从分母中剔除并单独记录数量；合并的需求以合并后的主需求为准，被合并需求标注去向，不重复计入。
建议同时统计偏差方向分布，即延期需求数、按期需求数、提前需求数各占多少。只看平均偏差天数会被正负抵消，一个平均偏差接近零的团队，可能一半需求延期一个月、一半提前一个月，承诺准确性并不好。
数据口径与证据：承诺日期取哪一次、状态以什么为准
偏差数据是否可比，取决于承诺日期和交付日期的取值规则是否稳定。最常见的口径问题是只保留最后一次承诺日期：需求延期后把承诺日往后改，台账上就看不出曾经延期。因此每条需求至少要保留两个字段：首次承诺交付日和当前承诺交付日。首次承诺反映最初判断的准确性，当前承诺反映调整后的判断，两者之差本身就是一条有价值的信息，说明需求在过程中发生过预期变化。
实际交付日以需求进入“已交付”状态的时间为准。状态定义要写进口径说明，例如“已交付”指需求通过验收并发布上线，而非开发完成或提测。状态定义一旦确定，统计期内不随意调整，否则前后数据不可比。若团队使用多个交付状态（如已上线、已验收），需指定其中一个作为判定依据。
需求发生范围变更、拆分或合并时，记录方式要统一。范围变更导致承诺日期调整的，保留变更前后的承诺日和变更原因；需求拆分的，子需求继承原需求的首次承诺日，并标注拆分时间；需求合并的，以主需求记录偏差，被合并需求在台账中标注合并去向。缺失承诺日或实际交付日的需求单独列出，不进入指标计算，同时统计缺失数量，缺失比例过高说明记录流程本身需要整改。
这些字段和状态流转需要有稳定的承载位置。在 ONES 中，需求可以进入统一的需求池，按优先级规划到迭代，并通过看板管理任务状态；迭代结束后可结合燃尽图、工时日志等报表回顾进度偏差。承诺日期字段、历史留痕和交付偏差类报表的具体配置方式，需按团队实际使用的字段与流程确认后再固定取数规则。
识别与复盘步骤：从偏差清单到原因归类
识别偏差是把数据算出来，复盘是把数据变成改进动作。两步分开做，避免在算数阶段就急着下结论。
第一步，导出偏差清单并计算指标。按约定时间窗导出需求列表，字段包括需求编号、首次承诺日、当前承诺日、实际交付日、承诺周期天数、状态。逐条计算偏差天数和偏差率，汇总按期交付率和偏差方向分布。输出一张可筛选的台账，作为后续复盘的基础数据。
第二步，按偏差幅度分层。把需求分为按期、轻微偏差（如偏差率在正负一定比例内）、显著偏差（超出该比例）三层。轻微偏差可以批量归因，显著偏差逐条复盘。分层阈值由团队根据自身需求粒度设定，不设统一标准；阈值一旦确定，连续几个周期保持一致，才能观察趋势。
第三步，回溯偏差发生的时间点。对每条显著偏差需求，判断偏差是在哪个环节产生的：承诺时就估错（首次承诺日与合理工期明显不符）、执行中发生范围变更或依赖阻塞、交付前测试或验收环节拉长。时间点判断依据是需求的状态流转记录和变更记录，而非事后回忆。
第四步，按原因类别归类。常用类别包括估算偏差、范围变更、依赖阻塞、资源冲突四类，可再细分。归类时一条需求只选一个主因，避免原因分散导致无法统计。归类完成后统计各类原因的占比，判断偏差是偶发还是结构性的。
第五步，形成调整项并指定责任人。针对占比最高的原因类别，提出具体调整：估算偏差集中的，调整估算方法和评审方式；范围变更频繁的，收紧变更准入条件；依赖阻塞多的，在承诺前增加依赖确认检查点。每项调整写明负责人和验证周期，下一轮统计时检查对应类别的偏差是否下降。
例子：一个迭代内需求交付预期偏差的完整计算
以下为演示数据，用于说明计算过程，不代表任何真实团队的表现。某迭代统计期内承诺交付的需求共 6 条，承诺起始日统一为迭代首日。
| 需求 | 承诺周期（天） | 承诺交付日 | 实际交付日 | 偏差天数 | 偏差率 | 主因 |
|---|---|---|---|---|---|---|
| A | 10 | 第10天 | 第10天 | 0 | 0% | — |
| B | 10 | 第10天 | 第13天 | +3 | +30% | 依赖阻塞 |
| C | 8 | 第8天 | 第6天 | −2 | −25% | 估算偏保守 |
| D | 12 | 第12天 | 第18天 | +6 | +50% | 范围变更 |
| E | 0 | 第0天 | 第2天 | +2 | 分母为零，不计算 | 资源冲突 |
| F | 10 | 第10天 | 未交付（已取消） | 不计入 | 不计入 | — |
计算过程如下。偏差天数逐条按实际交付日减承诺交付日得出，B 为 +3 天，C 为 −2 天，D 为 +6 天，E 为 +2 天。偏差率用偏差天数除以承诺周期天数：B 为 3÷10=30%，C 为 −2÷8=−25%，D 为 6÷12=50%；E 的承诺周期为零，单独标记，不参与比率汇总。按期交付率的分母为统计期内应交付需求数，F 已取消，从分母中剔除，分母为 5 条；分子为偏差天数为零的 A，共 1 条，按期交付率为 1÷5=20%。偏差方向分布为：延期 3 条（B、D、E），提前 1 条（C），按期 1 条（A）。
从示例数据可以读出两点。第一，偏差集中在延期方向，且 D 的偏差率达到 50%，属于显著偏差，需要逐条复盘；B 和 E 偏差幅度较小，可批量归因。第二，原因分布中范围变更、依赖阻塞、资源冲突各占一条延期需求，估算偏保守对应唯一的提前需求。改进方向相应明确：对范围变更收紧准入，对依赖阻塞在承诺前增加依赖确认，对资源冲突在排期时核对投入。C 的提前交付提示承诺可能偏保守，下一轮估算时可参考其实际用时。
解读与限制：指标能说明什么、不能说明什么
偏差率和按期交付率反映的是承诺的准确性，即团队对交付时间的判断与实际结果的吻合程度。它们不直接等于交付能力：一个团队可能交付能力很强，但承诺时习惯留足余量，指标表现很好；另一个团队交付量大，但承诺激进，指标表现差。把偏差率直接当作绩效结论，会诱导团队把承诺日期往后放，指标好看了，排期的参考价值反而下降。
样本量小或需求粒度不一致时，数据不可比。一个迭代只有五六条需求，一条需求的偏差就能让按期交付率变化二十个百分点；需求粒度差异大，大需求和小需求混在一起算平均偏差率，结论会被大需求主导。跨团队、跨周期比较前，先确认需求粒度、统计时间窗和状态定义一致。
提前交付过多同样值得关注。大量需求显著提前，可能说明承诺过于保守，排期失去了对业务预期的指导作用；也可能说明需求被拆得过细，单条需求的承诺周期短、波动大。解读时要结合偏差方向分布，而不是只看平均值。
复盘结论需要结合具体需求上下文判断。同样是延期三天，一条依赖外部供应商的需求和一条内部估算失误的需求，改进动作完全不同。本文不设通用达标线，团队可根据自身历史数据设定观察区间，用于发现异常波动，而非考核排名。指标的作用是引出问题、定位原因，最终改进仍要落到承诺规则和过程检查点的具体调整上。
常见问题
需求承诺交付日被修改过多次，复盘时应该用哪个日期？
建议同时保留首次承诺交付日和当前承诺交付日。首次承诺反映最初判断的准确性，当前承诺反映调整后的判断，两者之差本身就能说明需求在过程中发生过预期变化。如果只保留最后一次承诺日期，延期后把日期往后改，台账上就看不出曾经延期，偏差会被掩盖。复盘时可以用首次承诺日计算原始偏差，用当前承诺日观察调整后的兑现情况，两个口径结合分析。
统计按期交付率时，取消和合并的需求怎么处理？
取消的需求从分母中剔除，并单独记录数量，避免拉低按期交付率；合并的需求以合并后的主需求为准，被合并需求在台账中标注去向，不重复计入。这些规则需要在统计前写进口径说明，并在连续几个周期内保持一致，否则前后数据不可比。如果缺失承诺日或实际交付日的需求比例过高，说明记录流程本身需要整改，应单独统计缺失数量。
偏差率很低的团队，是否说明交付预期管理做得好？
不一定。偏差率低可能说明承诺准确，也可能说明承诺时留了过多余量，导致大量需求提前交付。提前交付过多同样值得关注：可能说明承诺过于保守，排期失去了对业务预期的指导作用；也可能说明需求被拆得过细，单条需求承诺周期短、波动大。解读时要结合偏差方向分布，看延期、按期、提前各占多少，而不是只看平均值或偏差率一个数。
复盘时一条需求有多个原因，应该怎么归类？
建议一条需求只选一个主因，避免原因分散导致无法统计。主因的判断依据是需求的状态流转记录和变更记录，而不是事后回忆。如果确实存在多个原因交织，可以在台账中记录主因和次要原因，但统计占比时只按主因计算。归类完成后统计各类原因的占比，判断偏差是偶发还是结构性的，再针对占比最高的类别提出调整项。
团队刚开始记录偏差数据，样本量很少，指标还有参考价值吗？
样本量少时，单条需求的偏差就能让按期交付率大幅波动，指标更适合用于发现具体问题，而不是做跨团队比较或考核。建议先积累几个周期的数据，保持统计口径一致，观察趋势变化。同时结合具体需求上下文判断，同样是延期三天，依赖外部供应商和内部估算失误的改进动作完全不同。指标的作用是引出问题、定位原因，改进仍要落到承诺规则和过程检查点的具体调整上。
