瀑布项目的阶段延期和阶段间返工经常同时出现，但两者的成因和处置方向并不相同。诊断时可以先定位症状：延期发生在哪个阶段、返工集中在哪个交接点；再围绕需求不清、评审不充分、依赖管理、变更控制失效四类原因提出假设，用需求版本、评审记录、依赖清单、变更单和阶段交付物逐项取证；最后按证据强度排序处置，并用返工率、阶段偏差和变更回退情况验证恢复效果。
要点总览（TL;DR）
- 先拆症状：阶段内进度偏差看估算与资源投入，阶段间返工看交接质量，两者排查入口不同。
- 四类原因假设要同时找支持证据和反向证据：需求版本变动、评审意见闭环、依赖到位偏差、变更单与计划同步情况。
- 排查按交接物、时间线、评审、依赖的顺序推进，每步设停止点，证据足以解释主要问题就转入处置。
- 处置针对已确认原因取最小动作，计划或范围调整需明确确认点，用返工率、阶段偏差、变更回退次数验证恢复。
- 诊断结论要回写到阶段评审清单、依赖清单维护和变更影响评估中，否则同类问题会在后续阶段重复出现。
先分清是阶段内延期还是阶段间返工
“项目延期”是一个笼统结论，无法直接指向原因。诊断的第一步是把它拆成两类可观察对象：阶段内进度偏差，指某阶段的实际完成时间晚于计划，但交付物仍由本阶段团队完成；阶段间返工，指下游阶段已经接收或使用上游交付物后，发现需要退回修改、补充或重做。前者通常与估算、资源投入和执行效率相关，后者更多暴露在交接质量上。两类问题可能并存，但排查入口不同。
区分二者需要收集四类最小记录：阶段计划与实际完成时间、各阶段交接的交付物清单、返工内容及其发生位置、交接双方对象。把每个阶段的计划完成日、实际完成日、偏差天数并列，再标注返工发生在哪个阶段、返工对象来自哪个上游交付物，就能看出问题分布。
| 阶段 | 计划完成时间 | 实际完成时间 | 偏差 | 返工内容 | 返工来源（上游交付物） | 交接对象 |
|---|---|---|---|---|---|---|
| 需求定义 | 3月10日 | 3月18日 | +8天 | 需求规格补充接口说明 | 需求文档 v1.2 | 设计组 |
| 系统设计 | 3月25日 | 3月25日 | 0天 | 设计返工：接口定义与需求不一致 | 需求文档 v1.2 | 开发组 |
| 开发实现 | 4月30日 | 5月12日 | +12天 | 模块重做：设计遗漏异常流程 | 设计说明书 v2.0 | 测试组 |
这张表的作用是定位问题集中区。如果偏差只出现在单个阶段，且该阶段内部返工为主，排查重点应放在该阶段的估算依据、人员投入和任务拆分粒度上。如果返工反复出现在同一交接点，例如需求到设计、设计到开发，说明问题更可能出在交接标准或上游交付物质量上，而非某个团队执行不力。判断时以返工来源列和交接对象列的重复模式为准，不以单次事件下结论。
四类常见原因与各自的排除证据
症状定位后，可以围绕四类原因提出假设。每类假设都需要同时寻找支持证据和反向证据：支持证据指向该原因成立，反向证据用于排除或降低其可能性。只有支持证据充分且反向证据不足时，才把假设升级为诊断结论。
需求不清
需求不清的典型表现是开发或设计阶段频繁澄清、需求文档版本在阶段内多次变动、存在未写入文档的口头补充。验证时查看需求文档的版本记录与变更时间点，统计开发期澄清次数及其来源，核对澄清内容是否已回写到需求文档。支持证据包括：需求版本在评审通过后仍有实质性修改、澄清记录集中在开发中后期、口头补充未形成文档。反向证据包括：需求版本稳定、澄清次数少且集中在评审前、下游返工与需求条目无对应关系。若需求变更均有记录且经过评估，则需求不清的解释力下降。
评审不充分
评审不充分的信号是评审通过后仍出现本应在评审阶段发现的问题。取证时查看评审参与角色是否覆盖下游使用方、评审意见是否逐条闭环、评审后缺陷的来源分布。支持证据包括：评审记录中缺少关键角色、评审意见未闭环即进入下一阶段、返工点对应的问题在评审记录中曾被提出但未处理。反向证据包括：评审角色齐全、意见闭环率高、返工问题属于评审后新增信息导致而非遗漏。需要注意，评审记录完整不等于评审有效，还要看意见是否真正影响了交付物。
依赖管理
依赖问题常见于外部交付、跨团队接口和资源到位三类场景。验证方法是把依赖清单中的计划到位时间与实际到位时间逐项对比，标注偏差及其对后续任务的影响。支持证据包括：关键依赖实际到位晚于计划、依赖未列入清单导致无人跟踪、资源到位时间与阶段启动时间不匹配。反向证据包括：依赖均按计划到位、延期阶段内无外部依赖、返工内容与依赖项无关联。依赖清单本身缺失或长期未更新，也是一种支持证据，说明依赖管理机制未运转。
变更控制失效
变更控制失效表现为变更发生但未走单、变更未评估对进度和返工的影响、变更后计划与交付物未同步更新。取证时核对变更单是否存在、变更单是否包含影响评估、变更后的计划基线是否调整。支持证据包括：存在无变更单的范围调整、变更单缺少对下游阶段的影响说明、变更后计划仍按原基线执行。反向证据包括：所有变更均有记录和评估、变更后计划已同步、返工与已批准变更无直接关系。变更记录完整但影响评估流于形式，同样属于控制失效的一种形态。
| 原因假设 | 支持证据 | 反向证据 |
|---|---|---|
| 需求不清 | 需求版本在评审后实质修改；开发期澄清频繁；口头补充未回写文档 | 需求版本稳定；澄清集中在评审前；返工与需求条目无对应 |
| 评审不充分 | 评审缺少下游角色；意见未闭环；返工问题曾在评审中被提出未处理 | 角色齐全；意见闭环率高；返工由评审后新增信息引起 |
| 依赖管理 | 关键依赖晚于计划到位；依赖未入清单；资源到位与阶段启动不匹配 | 依赖按计划到位；阶段内无外部依赖；返工与依赖项无关 |
| 变更控制失效 | 存在无单变更；变更单缺影响评估；变更后计划未同步 | 变更均有记录评估；计划已同步；返工与已批准变更无关 |
按证据强度排序的排查顺序
四类假设不宜同时铺开，否则取证工作量大且容易混淆。建议按“交接物—时间线—评审—依赖”的顺序推进，每一步都有明确的停止点：一旦某类证据足以解释主要返工或延期，就停止扩大排查范围，转入处置；若证据不足，再进入下一步。
第一步：核对交接交付物与下游返工点的对应关系。把每个返工点追溯到具体的上游交付物和版本，统计返工是否集中在少数交付物上。如果返工高度集中，说明问题出在特定交付物的质量或交接标准上，可直接进入针对该交付物的原因分析。停止点：返工来源清晰且集中，无需继续全面排查。需要留存的证据：返工清单、交付物版本号、交接记录。
第二步：比对需求与变更记录的时间线。把需求版本变动、变更单、阶段计划调整放在同一时间轴上，观察返工发生前是否有未记录或未评估的变更。如果返工时间点紧跟在某次需求修改之后，且该修改缺少影响评估，变更控制或需求不清的解释力较强。停止点：时间线能对应主要返工事件。留存证据：需求版本历史、变更单、计划基线调整记录。
第三步：检查评审记录与缺陷来源。针对未被前两步解释的返工，查看对应阶段的评审记录，核对参与角色、意见闭环情况和返工问题的首次发现时间。如果问题在评审中已被提出但未闭环，评审不充分的证据成立。停止点：评审记录能解释剩余返工的主要部分。留存证据：评审签到或参与记录、意见清单及关闭状态、缺陷来源标注。
第四步：核查依赖清单与实际到位情况。对仍未解释的延期，逐项比对依赖计划与实际到位时间，确认是否存在未列入清单的隐性依赖。停止点：依赖偏差能覆盖剩余延期。留存证据：依赖清单、实际到位记录、资源投入记录。
四步完成后，把每类原因的支持证据和反向证据汇总，按证据强度排序。证据强度取决于记录的直接性、时间上的因果接近程度和覆盖的返工比例，不取决于提出假设的人数或主观感受。
处置动作与恢复验证
诊断结论确定后，处置应针对已确认原因采取最小动作，避免同时调整计划、范围和流程造成新的混乱。需求不清导致的返工，优先补齐需求文档并建立变更回写规则；评审不充分导致的返工，优先补充评审角色和意见闭环要求；依赖问题导致的延期，优先更新依赖清单并明确跟踪责任人；变更控制失效导致的偏差，优先补建变更记录和影响评估环节。
涉及计划调整或返工范围变更时，需要明确风险边界与确认点。计划基线调整应说明调整依据、影响的下游阶段和新的完成时间，并由阶段负责人和下游接收方共同确认。返工范围变更应界定哪些交付物需要重做、哪些只需补充说明，避免返工范围扩大化。确认点建议设在返工完成并重新交接时，由接收方验证交付物是否满足进入下一阶段的条件。
恢复效果用三个指标验证：返工率，即返工工作量占阶段总工作量的比例，观察其是否随处置下降；阶段偏差，即实际完成时间与计划基线的差距，观察是否收敛；变更回退次数，即已批准变更被撤销或重新调整的次数，观察变更控制是否稳定。验证周期建议覆盖处置后的至少一个完整阶段，单次数据不足以判断恢复。
| 诊断结论 | 最小处置动作 | 风险边界与确认点 | 验证指标 |
|---|---|---|---|
| 需求不清 | 补齐需求文档，建立澄清回写规则 | 需求冻结前由下游确认；范围变更需走变更单 | 返工率、澄清次数 |
| 评审不充分 | 补充评审角色，要求意见逐条闭环 | 评审通过作为阶段门禁；未闭环不得交接 | 评审后缺陷数、返工率 |
| 依赖管理 | 更新依赖清单，指定跟踪责任人 | 关键依赖到位作为阶段启动条件 | 阶段偏差、依赖到位偏差 |
| 变更控制失效 | 补建变更记录与影响评估 | 变更后计划同步更新并重新确认基线 | 变更回退次数、阶段偏差 |
验证结论需要回写到管理机制中，否则同类问题会在后续阶段重复出现。具体做法是：在阶段评审中增加对返工原因和处置结果的回顾，把确认有效的检查项纳入下一阶段的评审清单；把依赖清单的更新责任固定到阶段负责人，并在每次计划调整时同步核对；把变更影响评估作为变更单的必填内容，变更后计划基线的调整记录与变更单关联保存。这样，诊断结论转化为可重复执行的检查动作，而不是一次性的事件复盘。
在记录留存与追溯方面，ONES 的项目计划支持按阶段分解 WBS 并设置任务前后置依赖和里程碑，计划与里程碑基线可用于对比计划与执行偏差；需求可编写并维护状态与属性，版本细节对比可用于追溯变更；ONES Wiki 支持文档关联任务，便于把需求文档、评审材料与对应工作项放在一起查阅。评审意见闭环统计、变更单影响评估流程和返工率报表是否以专门功能提供，需以实际版本和配置为准，选型时可重点核验。
常见问题
阶段延期和阶段间返工同时出现时，应该先查哪一个？
先查返工，再查延期。返工点通常能追溯到具体的上游交付物和版本，证据更直接；把返工来源列出来之后，往往能解释相当一部分延期。如果先查延期，容易陷入估算、资源等宽泛因素，排查范围难以收敛。
实际操作中，可以先做返工来源与交接对象的对应表，看返工是否集中在少数交付物或固定交接点。返工集中时，针对该交付物的原因分析就能同时解释延期；返工分散且延期独立存在时，再按依赖和资源投入方向排查。
评审记录齐全，是否就能排除评审不充分？
不能。评审记录齐全只说明评审动作发生过，不代表评审有效。判断评审是否充分，要看三个更具体的信号：参与角色是否覆盖下游使用方、评审意见是否逐条闭环、返工问题是否曾在评审中被提出但未处理。
如果返工点对应的问题在评审记录里出现过、却没有关闭就进入下一阶段，评审不充分的证据就成立。反过来，如果返工问题源于评审之后才出现的新信息，评审环节的解释力就下降，应转向需求变更或依赖方向排查。
需求变更都有变更单，为什么还可能是变更控制失效？
变更单存在只说明记录环节在运转，控制是否有效还要看两件事：变更单是否包含对下游阶段的影响评估，变更后计划基线是否同步调整。
常见的情况是变更单只登记了变更内容，没有说明对设计、开发、测试的影响，计划仍按原基线执行，结果下游阶段在不知情的情况下按旧交付物工作，产生返工。这类情况属于控制失效的一种形态。取证时把变更单、影响评估和计划基线调整记录放在一起核对，就能区分记录完整与控制有效。
排查做到一半，证据指向多个原因并存，怎么处理？
按证据强度和覆盖比例排序，先处置解释返工或延期比例最大的那个原因，不必等所有原因都查清。证据强度取决于记录的直接性、时间上的因果接近程度和覆盖的问题比例，不取决于提出假设的人数或主观判断。
处置一个原因后，观察返工率和阶段偏差是否下降。如果下降明显，剩余问题可以留到下一阶段继续观察；如果下降有限，再启动对第二原因的处理。同时铺开多个处置动作，会让效果难以归因，也容易造成计划和范围的反复调整。
恢复验证需要观察多长时间，单次数据够不够？
建议覆盖处置后的至少一个完整阶段，单次数据不足以判断恢复。返工率、阶段偏差、变更回退次数这三个指标都受阶段工作量和外部条件影响，一个时间点的数值波动可能来自偶发因素。
验证时把处置前后的数据按同一口径对比，并记录同期是否发生计划调整或范围变更，避免把外部变化误判为处置效果。如果连续一个阶段以上指标稳定收敛，再把处置动作固化到阶段评审清单和依赖清单维护机制中。
