瀑布项目的阶段衔接遗漏，常表现为下一阶段等人、返工补做或交接内容丢失。本文按评审、输入输出、责任交接三类根因给出定位方法：先看遗漏在哪个阶段边界暴露，再用交付物清单、评审记录和交接确认三类证据逐项排除，最后给出处置与恢复验证动作。
要点总览（TL;DR）
- 阶段衔接遗漏通常以等待、返工和交接遗漏三类信号暴露，先确认问题是否集中在阶段边界，再进入根因排查。
- 评审、输入输出、责任交接是三个待验证的根因假设：评审看结论与检查点，输入输出看交付物清单与验收标准，责任交接看接收人确认与工作项归属。
- 推荐排查顺序为输入输出、评审、责任交接：交付物定义不清时，评审和交接都难以有效执行。
- 判断主次看哪一环的缺失直接导致本次遗漏，三类根因常叠加，处置应针对首要缺口。
- 处置后需在下一个阶段边界验证同类问题是否消失，并把检查点、交付物清单和交接确认固化到阶段模板。
衔接遗漏的典型信号与影响范围
阶段衔接遗漏在项目中很少以“衔接有问题”的形式直接出现，它通常伪装成进度延误、质量返工或人员等待。要定位根因，第一步是把这些模糊现象还原成可观察的信号，并确认问题确实集中在某个阶段边界，而非整体进度失控。
三类可观察信号
等待类信号表现为：下一阶段人员已到位却无法开工，需要反复询问上一阶段“东西什么时候能给”；上游任务标记完成后，下游任务仍处于未启动状态；关键路径上的任务因缺少前置输入而空转。这类信号说明信息或物料在边界处停滞。
返工类信号表现为：下游按自己的理解完成了部分工作，评审或测试时发现与上游设计不一致，需要推翻重做；同一份需求在设计与开发阶段出现两种解释；测试用例与需求条目对不上，需要回头补。返工往往说明阶段之间的输入输出标准没有对齐。
交接遗漏类信号表现为：上一阶段明确要求的事项在下一阶段无人跟进；某份关键文档只存在于个人手中，团队其他人不知道；任务在系统中显示“已完成”，但接收方从未确认收到。这类信号指向责任主体在边界处断档。
如何判断问题集中在阶段边界
判断方法是对比问题出现的位置与阶段划分。如果延误、返工或遗漏集中发生在两个阶段的交界处，且同一阶段内部的工作推进相对正常，问题大概率出在衔接环节。反之，如果某个阶段内部就持续出现质量波动、任务大面积延期，则应先排查该阶段自身的执行问题，衔接只是表象。
另一个判断依据是问题的重复性。阶段边界的问题往往具有模式化特征：每次从设计转开发、从开发转测试，都会出现类似的等待或返工。这种重复出现的边界问题，比偶发的个体失误更值得作为衔接问题来诊断。
范围界定
本文讨论的范围限定在单个项目的阶段衔接：一个具体项目在评审、交付物传递和责任交接上的遗漏如何定位与处置。组织级的流程制度设计、跨项目的资源调配机制、敏捷框架的适用性，不在本文展开。明确这个边界，是为了让排查聚焦在可操作的项目证据上，避免把个案问题上升为制度讨论而迟迟无法落地。
三类根因假设：评审、输入输出、责任交接
把衔接遗漏直接归因为“沟通不畅”或“责任心不强”，往往导致处置动作落空。更有效的做法是先建立三个可验证的根因假设，再用证据逐一检验。三类假设各有典型特征，也经常叠加出现，需要按一定原则区分主次。
评审类假设
评审类假设认为，阶段衔接遗漏源于评审环节没有发挥把关作用。典型特征包括：评审会开了但没有形成明确结论，记录里只有“基本通过”之类的模糊表述；关键检查点缺失，比如设计评审没有覆盖接口定义，导致开发阶段才发现对接方式未定；评审发现的问题没有整改项和责任人，问题记录后无人跟踪关闭。当评审记录无法回答“这个阶段到底能不能进入下一阶段”时，评审类根因的可能性较高。
输入输出类假设
输入输出类假设认为，问题出在阶段交付物本身没有定义清楚。典型特征包括：阶段之间应该传递哪些文档、数据或成果没有清单；交付物的格式、颗粒度和验收标准没有约定，上游认为“给过了”，下游认为“不能用”；交付物清单存在但长期未更新，与实际工作脱节。这类问题的隐蔽性在于，双方都认为自己完成了工作，分歧发生在对“完成”的定义上。
责任交接类假设
责任交接类假设认为，遗漏发生在责任主体转移的瞬间。典型特征包括：交接没有明确的接收人，任务在系统中转了一圈却无人认领；上下游职责边界模糊，出现“都以为对方会做”的空白地带；工作项停留在上一阶段负责人名下，没有正式转移给下一阶段。这类问题的证据通常藏在任务归属和确认记录里，而不是文档内容里。
三类假设的对照与叠加判断
| 根因假设 | 典型特征 | 初步判断依据 |
|---|---|---|
| 评审类 | 评审走过场、检查点缺失、结论未记录 | 评审记录是否覆盖关键检查点，是否有明确结论和整改项 |
| 输入输出类 | 交付物未定义、格式或验收标准不清 | 阶段交付物清单是否存在，验收标准是否可核对 |
| 责任交接类 | 交接无接收人、职责边界模糊、工作项未转移 | 交接是否有接收人确认，工作项归属是否已变更 |
三类假设经常叠加。例如，交付物定义不清会削弱评审的有效性，评审结论缺失又会让交接失去依据。判断主次的原则是看哪一环的缺失直接导致了本次遗漏：如果下游拿到的输入本身就不完整，输入输出定义是首要问题；如果输入完整但无人确认接收，责任交接是首要问题；如果输入和交接都正常，但评审放行了不该放行的状态，评审是首要问题。这个原则决定了后续排查的起点和处置的重点。
按证据排查：从输入输出到评审再到责任交接
排查的价值在于用事实替代印象。推荐顺序是先核对输入输出定义，再检查评审执行，最后核对责任交接。这个顺序的理由是：输入输出是衔接的基础，定义不清时评审和交接都难以有效；评审是对输入输出的把关，交接是责任落地的最后一环。每一步都需要具体证据，并设定排除条件，避免在同一环节反复纠缠。
第一步：核对阶段交付物清单与验收标准
需要的证据包括：当前阶段的交付物清单是否存在、是否列明了每项交付物的格式和验收标准、清单是否与项目计划中的工作分解对应。核对方法是拿本次遗漏涉及的具体交付物，逐项对照清单，看它是否被定义、标准是否可操作。
排除条件：如果交付物清单完整、验收标准明确，且下游确认收到的内容符合标准，则输入输出类根因可以基本排除，进入下一步。如果清单缺失或标准模糊，且本次遗漏正好发生在这些未定义的交付物上，则输入输出类根因成立的可能性很高，应优先处置。
第二步：检查评审记录是否覆盖关键检查点
需要的证据包括：阶段评审的记录、评审覆盖的检查项、评审结论以及整改项的跟踪状态。核对重点是本次遗漏所涉及的内容，是否在评审检查点范围内；如果在范围内，评审是否给出了明确结论；如果评审提出了问题，整改项是否被关闭。
排除条件：如果评审记录显示关键检查点被覆盖、结论明确、整改项已闭环，则评审类根因可以排除。如果评审记录缺失、结论模糊，或遗漏内容根本不在检查点范围内，则评审类根因成立。需要注意的是，评审记录存在不等于评审有效，要区分“有记录”和“有结论”。
第三步：核对交接记录、接收人确认和工作项归属
需要的证据包括：阶段交接的记录或确认动作、下一阶段接收人是否明确、相关工作项在系统中的归属是否已从上一阶段转移到下一阶段。核对方法是追踪本次遗漏事项的责任链条，看它在哪个节点失去了明确的责任人。
排除条件：如果交接有接收人确认、工作项归属清晰，则责任交接类根因可以排除。如果交接无确认、接收人不明或工作项仍挂在上一阶段名下，则责任交接类根因成立。这一步的证据通常比前两步更容易被忽略，因为交接动作往往发生在会议或口头沟通中，缺少留痕。
在实际项目中，阶段交付物、评审记录和交接确认如果分散在文档、邮件和口头沟通里，排查会变得困难。ONES 的项目计划支持按阶段或交付物维度分解工作，并用里程碑标记决策点；ONES Wiki 支持文档关联任务，便于把交付物说明与具体工作项放在一起。把交付物清单、评审结论和交接确认沉淀到同一套项目数据中，排查时就能按阶段边界直接调取证据，而不必依赖个人回忆。具体配置方式以实际版本为准。
处置动作与恢复验证
定位根因后，处置动作要针对具体缺口，而不是笼统地“加强管理”。每类根因对应不同的修复动作，修复完成后还需要在下一个阶段边界验证衔接是否恢复，并把有效做法固化下来防止复发。
按根因对应的处置动作
评审类问题的处置：补齐缺失的检查点，把本次遗漏涉及的内容纳入评审范围；明确评审结论的要求，结论必须回答“通过、有条件通过或不通过”，有条件通过需列出整改项、责任人和关闭时间；对已放行但存在隐患的阶段，安排补充评审。
输入输出类问题的处置：补齐阶段交付物定义，明确每项交付物的内容、格式和验收标准；把验收标准写成下游可以逐项核对的形式，而不是“符合要求”这类无法验证的表述；对本次遗漏涉及的交付物，与下游共同确认补交内容。
责任交接类问题的处置：为每个阶段边界指定明确的接收人；建立交接确认动作，接收人确认后才视为交接完成；把相关工作项在系统中正式转移归属，避免任务停留在上一阶段负责人名下。
恢复验证
处置是否有效，要看下一个阶段边界是否还出现同类问题。验证方法是：在下一个阶段交接完成后，检查是否出现新的等待、返工或交接遗漏；对照本次处置补齐的检查点、交付物清单和交接确认，确认它们在实际交接中被使用，而不只是停留在文档里。如果同类问题再次出现，说明处置没有触及真正的根因，需要回到排查步骤重新检验假设。
复发预防
把本次排查中确认有效的做法固化到阶段模板中：检查点清单进入评审模板，交付物定义和验收标准进入阶段交付模板，交接确认动作进入阶段关闭条件。ONES Project 提供瀑布等多种项目模板，ONES 瀑布解决方案支持设置计划和里程碑基线、对比计划与执行的偏差，可用于在后续阶段持续观察衔接状态。模板化的意义在于让下一次阶段衔接有据可依，减少对个人经验的依赖。模板内容和可配置项以实际版本为准。
需要说明的是，三类根因的处置并非一次完成。阶段衔接的改善是一个逐边界验证的过程，每修复一个边界，观察一个周期，再决定是否需要调整模板或补充检查点。这种渐进方式比一次性重写流程更容易落地，也更容易看出哪项处置真正起了作用。
常见问题
如果交付物清单和评审记录都齐全，交接也有确认，但衔接还是出问题，该往哪里查？
这种情况下，先检查这些记录是否真正被使用，而不是只看是否存在。可以抽取本次遗漏涉及的具体事项，核对三件事：交付物清单里是否包含它、评审检查点是否覆盖它、交接确认是否针对它。如果三项记录都齐全但都不涉及该事项，说明清单和检查点本身存在覆盖盲区，需要补充定义；如果记录涉及但执行时被跳过，问题更可能出在执行环节而非定义环节。
另一个方向是检查阶段边界的时序：交付物是否在评审前完成、评审结论是否在交接前给出。顺序错位会让看似齐全的记录失去把关作用。
三类根因同时存在时，处置应该一次全做还是分步进行？
建议分步进行，先处置直接导致本次遗漏的那一环，再处理被牵连的环节。例如交付物定义不清导致评审无法有效判断，就先补齐交付物和验收标准，再回头检查评审检查点是否需要调整。一次全做的问题在于，多项动作同时上线后，无法判断哪项起了作用，下一个阶段边界再出问题时也难以归因。
分步的节奏可以按阶段边界安排：每修复一个边界，观察一个交接周期，确认同类等待或返工不再出现，再推进下一项。如果项目周期紧张，至少把处置动作和对应的观察指标记录下来，便于后续回溯。
阶段评审已经开了会、留了记录，为什么仍可能被判定为评审类根因？
评审记录存在与评审有效是两件事。判定评审类根因，关键看三点：记录中是否有明确的通过、有条件通过或不通过结论；结论是否覆盖了本次遗漏涉及的内容；评审提出的问题是否有整改项、责任人和关闭状态。如果记录只有“基本认可”之类的表述，或者遗漏内容根本不在检查点范围内，评审就没有起到把关作用。
排查时可以拿本次遗漏事项反向对照评审记录：它是否被检查过、当时给出了什么结论、后续是否跟踪。三个问题有一个答不上来，评审环节就存在缺口。
责任交接类问题在缺少书面交接记录的项目里怎么定位？
书面记录缺失时，可以改用工作项归属和沟通痕迹作为证据。核对本次遗漏事项在任务系统中的负责人是否已从上一阶段转移到下一阶段、转移时间是否在阶段边界附近、接收人是否对任务状态做过操作。再结合会议纪要、邮件或即时消息，确认是否有人明确表示接收。
如果工作项仍挂在上一阶段负责人名下，或接收人从未对任务做出任何动作，责任交接断档的可能性较高。这类排查的结论应写成具体事实，例如“某任务在阶段关闭后仍归属上游负责人”，便于后续处置时直接对应到交接确认动作的补建。
恢复验证需要观察多久，观察哪些指标？
观察周期通常覆盖下一个完整的阶段边界，即从本次处置完成到下一次阶段交接结束。观察指标与三类信号对应：下一阶段是否出现等人开工的等待、是否出现因输入不一致导致的返工、是否有事项在交接后无人跟进。指标不需要复杂，能按事项逐条核对即可。
验证时还要确认处置补齐的检查点、交付物清单和交接确认在实际交接中被使用。如果同类问题再次出现，说明处置没有触及真正根因，应回到排查步骤重新检验假设，而不是继续叠加新的管理动作。
