项目延期后复盘，容易把原因笼统归为“估算不准”或“执行不力”。更可操作的区分方法是把偏差拆成两段验证：先检查估算时依据的假设（范围、人员、依赖、可用工时）在过程中是否被证伪，再检查执行中是否出现可观测的动作偏离（返工、等待、范围追加、投入不足）。本文按症状分类、假设验证、执行排查、交叉判定和处置复核的顺序，给出可填写的表格与判定标准，适用于以投入预估为对象的延期复盘。
要点总览（TL;DR）
- 复盘时先把延期拆成可观察症状，用同一口径的估算值、假设清单、计划投入与实际投入做比对，口径不一致会制造假偏差。
- 判定顺序建议先验证假设、再排查执行：假设被证伪时计划投入本身不成立，先查执行容易把假设问题误判为执行不力。
- 假设验证看实际值是否超出估算时允许的波动范围且未被预见；执行排查看返工、等待、范围追加、投入不足、交接延迟是否有对应证据。
- 两类原因可以共存，按影响工时量拆分权重，结论写成“总偏差由假设错误、执行偏差和证据不足部分各占多少”，找不到证据的保留为待查项。
- 处置分开做：假设错误修正假设清单与估算基线，执行偏差纠正动作与节奏，并在迭代中期和结束后各设一次复核检查点。
延期复盘先看症状：偏差出现在哪一段
复盘的第一步是把“延期”这个结果拆成可观察的症状，而不是直接讨论谁的责任。建议用同一口径的基线数据做比对：估算时记录的工作量、假设清单、计划投入人天、里程碑计划完成时间，对照实际投入人天、里程碑实际完成时间、过程中新增或变更的工作项。口径不一致的对比（例如估算按理想工时、实际按含会议的自然工时）会制造假偏差，比对前先统一单位与统计范围。
症状分类的作用是缩小排查范围。以下表格可作为复盘会议的第一张工作表，逐条填写现象与待验证证据，暂不下结论。
| 现象 | 可能归属 | 待验证证据 |
|---|---|---|
| 按原假设本应完成，实际未完成，且过程中无新增工作 | 偏向假设错误 | 假设清单原值、实际环境或人员情况 |
| 实际投入明显低于计划投入，任务推进缓慢 | 偏向执行偏差 | 工时登记明细、任务状态变更记录 |
| 过程中范围追加或需求变更频繁 | 需先判断：估算时是否已预见 | 变更记录时间点与估算基线时间点 |
| 关键依赖方交付晚于计划 | 需先判断：估算时是否把该依赖列为假设 | 依赖方承诺时间与实际交付时间 |
| 出现返工，同一任务多次打开 | 偏向执行偏差，也可能源于假设中的技能或环境判断 | 返工原因记录、评审意见 |
| 人员中途更换或可用性下降 | 偏向假设错误（若估算时按满员计算） | 人员投入记录、请假或调配记录 |
这张表的价值在于把“延期”转化为若干条可取证的具体问题。每条现象至少对应一份证据来源，没有证据的现象只作为待查项，不进入归因结论。
列出估算假设并逐条验证是否被证伪
估算假设错误的表现是：按原假设本应完成，但假设本身不成立。因此验证的对象是假设，而不是结果。复盘时先把估算时的隐含前提显性化，常见类型包括范围（包含哪些功能、不含哪些）、人员技能与可用性（谁做、投入比例、是否熟悉该模块）、依赖方交付（接口、设计稿、第三方服务的时间承诺）、环境与工具（测试环境、构建链路是否就绪）、可用工时（扣除会议、支持、休假后的有效工时）。
每条假设需要记录原值、实际值和证据来源，判断标准是：实际值与原值出现足以改变工作量结论的差异，且该差异在估算时未被预见，即视为假设被证伪；实际值在原值允许的波动范围内，或差异已被估算时的缓冲覆盖，则假设仍成立。以下清单可直接用于复盘填写。
| 假设类型 | 原值（估算时） | 实际值 | 是否证伪 | 证据来源 |
|---|---|---|---|---|
| 范围 | 如：包含A、B两个模块 | 实际交付范围 | 是/否 | 需求文档版本、变更记录 |
| 人员技能 | 如：由熟悉该模块的2人承担 | 实际参与人员与熟练度 | 是/否 | 任务分配记录、评审返工情况 |
| 人员可用性 | 如：每人每周投入4天 | 实际投入比例 | 是/否 | 工时登记、排班与请假记录 |
| 依赖方交付 | 如：接口在第2周提供 | 实际提供时间 | 是/否 | 依赖方交付记录、沟通记录 |
| 环境与工具 | 如：测试环境已就绪 | 实际就绪时间与稳定性 | 是/否 | 环境故障记录、构建日志 |
| 可用工时 | 如：按每人每天6小时有效工时 | 实际有效工时 | 是/否 | 工时登记明细、会议与支持记录 |
取证时注意时间点：假设是否成立，要看它在估算时是否合理、在过程中是否被打破，而不是用最终结果反推。例如“人员不熟悉该模块”如果估算时已知并计入，就不构成假设错误；如果估算时按熟练人员计算、实际由新人承担，则属于假设被证伪。逐条验证完成后，被证伪的假设及其影响工时量，构成估算侧归因的证据基础。
排查执行过程偏差：动作与节奏是否偏离计划
执行偏差的表现是：假设仍成立，但实际投入或推进节奏偏离计划。排查应在假设验证之后进行，因为假设被证伪时，执行数据本身会失真，先查执行容易把假设问题误判为执行不力。执行偏差的典型表现包括返工、等待依赖、范围追加、投入不足和交接延迟，每一类都需要对应的证据，而不是印象判断。
用实际投入与计划投入对比是核心方法：按任务或里程碑粒度，把计划人天与实际人天并列，同时看任务状态变更的时间分布。如果实际投入接近计划投入但完成时间明显延后，重点查等待与阻塞；如果实际投入显著低于计划投入，重点查投入不足与优先级挤占；如果实际投入显著高于计划投入且伴随多次返工，重点查返工原因与交接质量。
| 偏差类型 | 证据 | 影响工时量（估算） |
|---|---|---|
| 返工 | 任务多次打开记录、评审退回意见 | 返工轮次×单轮工时 |
| 等待依赖 | 阻塞状态持续时长、依赖方交付时间 | 阻塞天数×可用人力 |
| 范围追加 | 变更记录与新增工作项 | 新增工作项估算之和 |
| 投入不足 | 工时登记与计划投入的差额 | 计划投入减实际投入 |
| 交接延迟 | 上下游任务之间的空闲间隔 | 间隔时长×受影响人力 |
同样需要排除证据：如果工时登记显示实际投入与计划投入基本一致、任务状态按计划推进、阻塞时长在计划缓冲内、变更均已在估算时计入，则执行侧未出现可观测偏离，归因应回到假设侧继续查找。排除证据与确认证据同等重要，它防止复盘把“没有查到的执行问题”默认成“执行没问题”。
交叉判定：假设错误与执行偏差如何区分与共存
判定顺序建议先验证假设、再排查执行。理由有两点：假设决定工作量的计算基础，假设被证伪时，计划投入本身就不成立，执行数据失去比较基准；先查执行容易受结果影响，把延期直接归因为“推进不力”，形成结果倒推原因的误判。常见误判还包括：把范围追加一律算作执行问题（若估算时未预见范围变化，它同时是假设问题）、把人员不足一律算作估算错误（若估算时已按实际可用人力计算，则属于执行侧投入不足）、把返工一律归为技能问题（也可能是环境或依赖假设不成立导致）。
两类原因共存时，按影响工时量拆分权重，而不是二选一。可按下述流程形成结论：第一步，列出全部被证伪的假设，估算每条假设单独造成的工时增量；第二步，在剩余偏差中列出执行侧可观测偏离，估算每条偏离的工时影响；第三步，检查两部分之和是否接近总偏差，差距部分标注为“证据不足，待补充”；第四步，按影响量排序，取占比最高的两项作为主要归因，其余列为次要因素。结论模板可写成：“总偏差X人天，其中假设错误贡献A人天（主要来自某假设被证伪），执行偏差贡献B人天（主要来自某类偏离），剩余C人天证据不足。”
这个拆分不追求精确到个位，重点是让每条归因都有对应证据，并让复盘结论可以被后续数据检验。若某条归因找不到证据支撑，应保留为待查项，而不是用经验判断补齐。
处置与验证：修正估算与纠正执行后的复核
归因不同，处置动作也不同。假设错误的处置重点是修正假设清单与估算基线：把本次被证伪的假设补入团队的标准假设清单，明确每类假设的默认值与确认责任人；对同类项目重新估算时，先核对假设再给工作量；在估算文档中保留假设版本，便于下次复盘对照。执行偏差的处置重点是纠正动作与节奏：针对返工设置评审前置检查点，针对等待依赖设置阻塞升级时限，针对投入不足与优先级挤占明确任务承诺与调配规则，针对交接延迟约定交接完成的定义。
处置后需要复核，验证恢复并防止复发。复核指标建议包括：下一个迭代或同类任务的实际投入与计划投入偏差率、阻塞平均时长、返工次数、变更占比。检查点设置在迭代中期和结束后各一次，中期看节奏是否回到计划，结束后看偏差是否收敛。若偏差率持续偏高且假设清单已覆盖主要类型，说明问题可能出在估算方法本身，需要调整估算口径；若偏差集中在某一类执行偏离，则继续收紧对应的检查点。
复盘记录、假设清单与实际投入的对照，如果分散在个人表格和聊天记录里，复核时很难保持同一口径。ONES 资源和工时管理解决方案支持多维度统计项目和成员的资源投入情况，并可查询和导出工时登记日志明细，便于把计划投入与实际投入放在同一视图中比对；资源规划视图和成员工作量、可用性、饱和情况的查看，也能帮助在估算阶段核对人员可用性假设是否合理。具体功能范围与套餐、版本相关，以实际开通情况为准。把假设清单作为项目文档维护、把工时登记作为工作项数据积累，复盘时的取证和交叉判定就有了稳定的数据来源。
常见问题
估算时已经预留了缓冲，实际仍超支，这算假设错误还是执行偏差？
先看超支部分是否落在缓冲覆盖范围内。若实际偏差在缓冲之内，说明估算时的假设仍成立，不需要归因；若超出缓冲，再逐条核对假设清单：实际值是否超出估算时允许的波动范围，且该差异在估算时未被预见。满足这两条才计入假设错误。缓冲之外仍有剩余偏差的，再查执行侧是否有返工、等待、投入不足等可观测偏离。缓冲本身不应成为吸收所有偏差的默认项，否则复盘会失去诊断价值。
范围在项目中途追加，应该算估算假设错误还是执行偏差？
判断依据是追加发生在估算基线之前还是之后，以及估算时是否已预见。若变更记录的时间点晚于估算基线、且估算时的范围假设未包含这部分工作，它同时构成假设被证伪；若估算时已把该类变更列为假设或计入缓冲，则属于执行侧的范围控制问题。复盘时把变更记录与估算基线的时间点并列对照，再估算新增工作项的工时量，归入对应一侧。
假设验证和执行排查都需要工时数据，但团队填报不完整，复盘还能做吗？
可以做，但要调整结论的确定性。工时登记不完整时，优先使用任务状态变更记录、阻塞持续时长、评审退回意见等过程数据作为替代证据，并在结论中标注哪些归因证据不足。把证据不足的部分单列为待查项，不用经验判断补齐。若同类偏差反复出现，再考虑统一工时登记口径，让下一次复盘有可比的基线数据。
两类原因都找到了，结论里要不要只写一个主要原因？
建议按影响工时量排序，写出占比最高的两项作为主要归因，其余列为次要因素，并注明剩余部分证据不足。只写一个原因会掩盖另一类问题的处置需求：假设错误需要修正估算基线，执行偏差需要纠正动作与节奏，两者的后续动作不同。拆分不必精确到个位，重点是每条归因都有对应证据，能被后续数据检验。
复盘结论形成后，怎么确认处置真的有效？
在下一个迭代或同类任务上设两个检查点：中期看节奏是否回到计划，结束后看实际投入与计划投入的偏差率、阻塞平均时长、返工次数、变更占比是否收敛。若偏差率持续偏高且假设清单已覆盖主要类型，说明问题可能出在估算方法本身，需要调整估算口径；若偏差集中在某一类执行偏离，则继续收紧对应的检查点。把假设清单作为项目文档维护、工时登记作为工作项数据积累，复核时才能保持同一口径。
