瀑布项目按阶段串行推进时，返工和等待频繁出现，问题可能来自阶段定义，也可能来自阶段衔接。判断的核心口径是：同一类问题总在某个阶段入口或出口固定复现，换执行人也一样，优先查阶段定义；问题随交接对象、评审安排和信息传递方式变化，而阶段内部工作本身顺畅，优先查阶段衔接。本文限于单项目方法层面，组织级流程制度和敏捷框架不展开。
要点总览（TL;DR）
- 判断口径：同一类等待或返工总在某个阶段入口或出口固定复现、换执行人也一样，优先查阶段定义；阶段内部工作顺畅、问题随交接对象或评审安排变化，优先查阶段衔接。
- 排查前先排除资源与能力因素，再按“交付物与完成标准—准入准出条件—交接清单与评审时点—状态与文档连续性”的顺序检查，一次只改一类。
- 归因结论只是假设，需用最近三次以上实例支撑，并选一到两个阶段做小范围试点，前后对比等待时长、返工次数和验收争议数量。
- 验证有效后把交付物清单、完成标准、交接清单和评审时点写入阶段说明或项目检查表，并定期抽查执行情况，防止问题复发。
- 流程细化程度应与项目复杂度、人员流动性和交付风险匹配，周期短、团队稳定的项目可只保留交付物清单和一次出口评审。
症状与范围：先分清等待、返工和验收争议各自出现在哪里
“衔接不畅”是一个笼统感受，直接拿它讨论归因，很容易变成各角色互相解释。有效的做法是先把感受拆成可观察的症状，并记录症状发生的位置。位置决定了后续排查方向：阶段内部的问题通常指向执行方法或资源，阶段入口和出口的问题才与定义和衔接直接相关。
串行推进的项目中，典型症状有三类。第一类是等待：上游阶段尚未交付，下游阶段人员已经就位却无法开工，或者下游提出问题时上游无人响应。第二类是返工重做：下游按自己的理解完成了工作，上游或客户验收时发现与预期不符，需要退回修改。第三类是验收争议：双方对“是否完成”各执一词，争议集中在交付物范围、质量口径或签字确认环节。
记录症状时，位置要写到具体边界。例如“需求阶段出口到设计阶段入口之间等待5个工作日”，比“需求到设计衔接不畅”更有诊断价值。同时要区分偶发与重复出现：一次因关键人员请假造成的等待，与连续三个迭代都在同一位置等待，原因判断完全不同。建议以最近一个季度或最近三个交付周期为观察窗口，至少收集三次同类实例，样本太少时先继续观察，不急于归因。
可以用下面的表格做第一轮记录，每行对应一次实例，避免把不同位置的问题混在一起统计。
| 症状类型 | 发生位置 | 出现频次 | 涉及角色 | 最近三次实例 |
|---|---|---|---|---|
| 串行等待 | 阶段入口／阶段出口／阶段内部 | 观察周期内次数与累计时长 | 等待方与未交付方 | 日期、工作项、等待天数 |
| 返工重做 | 阶段入口／阶段出口／阶段内部 | 返工次数与返工工作量 | 执行方与验收方 | 日期、返工原因、修改范围 |
| 验收争议 | 阶段出口 | 争议次数与解决耗时 | 交付方与评审方 | 日期、争议焦点、最终结论 |
这张表的作用是建立事实基础。记录完成后再看分布：如果三类症状集中出现在某几个固定边界，后续重点查定义；如果同一阶段内部也频繁返工，说明执行层面的资源或能力因素需要先排除。
原因假设与排除证据：阶段定义问题和衔接问题怎么区分
症状记录完成后，可以提出两组原因假设。阶段定义问题指阶段本身没有被说清楚：这个阶段要产出什么、做到什么程度算完成、谁负责、什么条件下可以进入下一阶段。阶段衔接问题指阶段本身清楚，但两个阶段之间的传递机制缺失：交接什么、何时评审、责任如何移交、状态在哪里更新。
两组假设有各自的可观察表现。阶段定义问题的常见表现包括：交付物清单缺失或只有名称没有内容要求；完成标准停留在“符合要求”“质量达标”这类无法验收的表述；相邻阶段的职责边界重叠，同一件事两个角色都认为归对方；阶段准入准出条件没有写下来，或者写了但从未被引用。阶段衔接问题的常见表现包括：交接时没有清单，下游靠口头询问获取上下文；评审时点与阶段边界错位，评审安排在交付之后很久；责任人移交只发生在组织架构上，实际对接人未同步；状态更新滞后，下游看到的状态与真实进度不一致；关键信息在交接处丢失，下游需要重新向上游索取。
区分两者的关键证据是变化测试。固定复现看定义：同一类返工总在某个阶段出口出现，换一个执行人、换一个下游团队仍然出现，说明问题跟着边界走，与具体人员无关，优先怀疑定义。随人随流程波动看衔接：同一阶段内部工作顺畅，但换一个交接对象、调整一次评审安排，等待明显减少或增加，说明问题跟着传递方式走，优先怀疑衔接。
排查前要先排除资源与能力因素。人员不足、技能不匹配、关键角色同时承担多个项目，也会造成等待和返工，这类问题的表现是随负载波动，与阶段边界没有固定关系。排除顺序建议为：先确认资源投入与能力是否满足阶段工作要求，再判断定义是否完整，最后判断衔接机制是否落地。跳过前两步直接改流程文件，容易把资源问题误写成定义问题。
| 原因假设 | 可观察证据 | 排除方法 | 当前判断 |
|---|---|---|---|
| 阶段定义不清 | 交付物清单缺失、完成标准模糊、职责重叠、准入准出条件未书面化 | 换执行人后同类问题仍在同一阶段边界复现 | 待实例证据支撑 |
| 阶段衔接不畅 | 交接清单缺失、评审时点错位、责任移交不清、状态更新滞后 | 调整交接方式或评审安排后等待与返工明显变化 | 待实例证据支撑 |
| 资源与能力因素 | 问题随人员负载波动，与阶段边界无固定关系 | 补齐资源或调整分工后症状缓解 | 优先排除 |
需要强调，表中的“当前判断”只是假设，不能直接当成结论。每个假设至少要对应两到三条实例证据，证据来自症状记录表，而不是来自会议上的印象。证据不足时，宁可标注“待验证”，也不要为了推进改进而先下结论。
按症状走排查路径：从定义到衔接的顺序检查
归因排查按固定顺序进行，先查定义再查衔接，避免两头同时改导致无法判断哪项改动起了作用。每一步都有明确的判断口径和停止点，通过则进入下一步，不通过则先处理当前问题并记录，不继续往下叠加改动。
第一步，核对阶段交付物与完成标准是否书面化、可验收。判断口径是：任取一个阶段，能否在不询问原作者的情况下，从文档中列出该阶段的交付物清单，并逐项说明验收方式。通过的标准是清单存在、每项有内容要求、验收方式可操作。不通过时停止排查，先补齐交付物与完成标准，因为后续的交接清单和评审安排都建立在这份清单之上。
第二步，核对阶段准入准出条件是否明确且被实际执行。判断口径是：调取最近三次阶段评审记录，看是否引用了准入准出条件，是否有明确的通过或不通过结论。条件写在文件里但评审时从未使用，等同于没有条件。不通过时先修订条件并约定使用方式，再继续。
第三步，核对交接清单、评审时点、责任人移交是否有约定。判断口径是：阶段边界处是否有书面的交接内容、交接对象和确认方式；评审时点是否安排在阶段出口附近而非交付后很久；责任人移交是否包含实际对接人、决策人和问题升级路径。这一层检查的是衔接机制是否存在，与第一步的定义检查分开记录。
第四步，核对状态与文档在交接处是否连续可查。判断口径是：下游能否从项目记录中直接看到上游的交付状态、变更记录和遗留问题，而不需要重新向上游索取。状态更新滞后、文档散落在个人目录、变更没有通知下游，都属于衔接层面的缺口。
四步走完后，通常会得到一份混合结论：某些阶段定义完整但交接缺失，某些阶段定义本身就模糊。此时按阶段分别处置，不要用一次全局流程改版覆盖所有问题。涉及修改流程文件或调整评审安排时，先在一到两个阶段小范围试行，保留原版本和试行记录，确认有效后再推广。
排查过程中产生的交付物清单、完成标准、交接记录和验证结论需要有稳定的承载位置。ONES 支持瀑布项目全生命周期管理，可用项目计划按阶段维度分解工作并设置任务前后置依赖，用里程碑标记阶段边界上的评审与决策点；阶段说明、交接清单和验证记录可以放在与工作项关联的文档中，使下游在项目内直接查到上游交付状态与变更记录。这样做的目的是让定义和衔接的约定有据可查，减少口头传递造成的信息丢失。
验证与复发预防：用小范围试点确认归因并固化改进
归因结论需要用一次小范围验证确认。选择一到两个症状最集中的阶段作为试点对象，只改与当前假设对应的一项内容：判断为定义问题，就补齐该阶段的交付物清单、完成标准和准入准出条件；判断为衔接问题，就固化交接清单、评审时点和责任移交规则。一次只改一类，才能看出效果来自哪里。
验证指标沿用症状记录表的口径：阶段边界的平均等待时长、单位周期内的返工次数、验收争议数量。试点前后各取相同长度的观察窗口，保留对照数据。同时记录外部因素，例如同期人员变动、需求变更数量、客户评审节奏变化，避免把外部波动算成改进效果。如果试点后指标没有改善，说明归因可能有误，回到症状记录重新检查，而不是继续加大流程约束。
验证有效后，把结论写入阶段说明或项目检查表，形成复发预防。具体做法包括：在阶段说明中固定交付物清单与完成标准；在阶段边界处固定交接清单模板和评审时点；在项目检查表中加入“准入准出条件是否被引用”“交接记录是否完整”两项例行核对。规则写入后要有人定期抽查执行情况，否则容易回到文件存在但无人使用的状态。
改进需要付出代价，适用前提要说清楚。补齐定义和交接清单会增加阶段边界的工作量，评审时点前移可能压缩上游的准备时间。对于周期短、交付物简单、团队长期固定协作的项目，过度细化清单和评审节点反而增加负担，可以只保留交付物清单和一次出口评审。流程细化的程度应与项目复杂度、人员流动性和交付风险相匹配，以能支撑验收和交接为限。
| 验证对象 | 前后对比数据 | 结论 | 写入的规则或检查表 |
|---|---|---|---|
| 试点阶段及边界 | 等待时长、返工次数、验收争议数量的前后值 | 归因成立／不成立／受外部因素干扰 | 阶段说明、交接清单模板、项目检查表条目 |
把这张表随项目归档，下一次出现类似症状时可以直接对照，判断是旧问题复发还是新问题出现。阶段定义与阶段衔接的判断不是一次性的，项目阶段推进过程中交付物和参与角色会变化，定期用症状记录表复核，比等到返工集中爆发再排查更省成本。
常见问题
如果等待和返工同时出现在多个阶段边界，怎么确定先改哪一处？
先按症状记录表统计每个边界的累计等待时长和返工工作量，选影响最大的一处作为试点对象，而不是同时改所有边界。判断依据可以看两个指标：该边界问题出现的频次，以及每次问题造成的返工或等待规模。选频次高且单次影响大的边界先处理，改完观察一个完整周期，再决定下一处。同时改多处会让效果无法归因，也容易在流程文件里留下互相冲突的约定。
阶段定义和衔接问题同时存在时，改进顺序应该怎么安排？
建议先补定义、再修衔接。交付物清单和完成标准是交接清单、评审安排的基础，定义不清时先做交接模板，下游拿到的仍是一份模糊的交付物，问题会换个形式重现。实际操作中可以先完成定义补齐，再在阶段边界处加交接清单和评审时点。如果资源有限，优先处理返工最集中的那个阶段的定义问题，衔接改进放在下一轮。
小范围试点后指标没有改善，下一步该做什么？
先回到症状记录核对归因是否成立，重点看三点：试点期间是否有人员变动、需求变更或客户评审节奏变化等外部因素；改动是否真的落地执行，例如交接清单是否被实际填写；问题位置是否与最初记录一致。如果归因有误，重新走一遍从定义到衔接的排查顺序；如果改动未落地，先解决执行问题再评估效果。此时继续加大流程约束通常不会改善结果。
团队规模小、阶段划分简单的项目，也需要完整的交接清单和评审节点吗？
不必照搬完整清单。对于周期短、交付物简单、成员长期固定协作的项目，可以只保留交付物清单和一次阶段出口评审，交接内容用简短记录代替模板。判断标准是能否支撑验收和交接：出现验收争议或下游需要反复向上游索取信息时，再补充相应约定。流程细化的程度应与项目复杂度、人员流动性和交付风险匹配，过度细化会增加阶段边界的工作量。
阶段说明、交接清单和验证记录放在哪里，才能让下游直接查到？
关键是让这些内容与阶段工作项关联，而不是散落在个人目录或聊天记录里。ONES 支持按阶段维度分解项目计划并设置任务前后置依赖，用里程碑标记阶段边界上的评审与决策点；阶段说明、交接清单和验证记录可以放在与工作项关联的文档中，下游在项目内即可查看上游交付状态与变更记录。具体承载方式可结合团队现有模板调整，目的是减少口头传递造成的信息丢失。
