瀑布项目上阶段未完成时，下阶段能否启动，取决于“未完成”的具体性质。若关键交付物缺失或评审未通过，下阶段主体工作应暂缓；若只剩非关键收尾事项，可以在明确风险、责任人和关闭期限的前提下有条件启动，并设置停止点。本文给出一套从情形分类、阻断项排查到有条件启动和事后验证的判断路径。
要点总览（TL;DR）
- 瀑布项目上阶段未完成时能否启动下阶段，先要分清未完成属于关键交付物缺失、评审未通过，还是仅剩非关键收尾项。
- 关键交付物缺失或评审问题未关闭时，下阶段主体工作应暂缓，先补齐输入并完成复评。
- 仅剩非关键收尾项时，可在书面风险评估、责任人确认和关闭期限明确的前提下有条件启动，并限定并行范围。
- 启动后按周期复核遗留项关闭情况，在下阶段关键节点做回归验证，触发停止条件时暂停相关并行工作。
- 把本次遗留项类型纳入阶段出口检查清单，可减少同类问题在后续阶段反复出现。
先判断“未完成”属于哪种情况
“上阶段未完成”是一个笼统描述，直接据此决定启动或暂缓，容易把可控的收尾问题当成阻断性风险，也可能把真正的交付缺口放过去。第一步应把未完成拆成可核对的情形，再判断严重程度。
常见情形有三类。第一类是关键交付物缺失，例如需求规格说明未定稿、设计文档缺少关键接口定义、开发代码未完成提测版本。第二类是评审未通过，交付物形式上存在，但评审结论为不通过或带条件通过，问题尚未关闭。第三类是仅剩非关键收尾项，例如部分辅助文档待补充、非关键缺陷待修复、格式与归档事项未完成。
判断依据应来自三份材料：阶段出口标准，说明本阶段必须满足哪些条件才能关闭；交付物清单，列明应交付什么、当前状态如何；评审记录，记录评审结论、遗留问题和关闭情况。三者对照，才能把“未完成”落到具体条目上。
| 未完成情形 | 典型表现 | 对下阶段的影响 | 处理方向 |
|---|---|---|---|
| 关键交付物缺失 | 需求未定稿、设计缺少关键定义、提测版本不完整 | 下阶段缺少必要输入，返工风险高 | 暂缓下阶段主体工作，先补齐交付物 |
| 评审未通过 | 评审结论为不通过或带条件通过，问题未关闭 | 输入质量未确认，后续工作可能建立在错误假设上 | 先关闭评审问题并复评，再决定启动范围 |
| 仅剩非关键收尾项 | 辅助文档待补、非关键缺陷待修、归档未完成 | 对下阶段主体工作影响有限 | 可评估有条件启动，限期关闭遗留项 |
三类情形的处理方向差异明显：前两类指向暂缓或缩小启动范围，第三类才具备有条件启动的空间。分类完成后，还需理解阶段之间为什么存在顺序要求，才能判断哪些依赖可以协商。
为什么瀑布阶段通常要求顺序衔接
瀑布模式按阶段推进，后续阶段的工作输入主要来自前阶段的交付物。需求阶段产出经过确认的需求基线，设计阶段据此形成架构与详细设计，开发阶段依据设计实现，测试阶段依据需求与设计验证结果。每一环的输入质量，直接决定下一环的工作是否建立在可靠基础上。
顺序衔接的作用机制在于减少返工与范围蔓延。若需求尚未定稿就进入设计，设计人员只能基于假设推进，需求变更后设计需要重做；若设计关键定义缺失就进入开发，开发人员各自理解不同，集成时才发现接口不一致，修复成本随阶段推进不断放大。阶段出口评审的作用，就是在成本较低的时点确认输入可用，避免问题向下游传递。
阶段依赖的约束强度并不相同，需要区分硬约束与可协商约束。硬约束指后续工作离开前阶段交付物就无法开展，例如没有接口定义就无法进行接口开发，没有测试环境就无法执行系统测试。可协商约束指前阶段成果已基本可用，剩余部分不影响下阶段主体工作，例如部分辅助文档待补、非关键缺陷待修。判断约束强度，应看下阶段的具体任务是否直接消费该交付物。
实践中存在两种常见误解。一种把阶段顺序当成绝对禁令，任何遗留项都要求全部关闭才允许启动，导致项目为少量收尾事项整体停摆。另一种把阶段顺序当成可以随意跳过的形式，在关键输入缺失时强行推进，把风险留到集成和测试阶段集中爆发。合理做法是回到依赖关系本身：关键输入是否具备，决定能否启动；非关键遗留是否可控，决定启动的条件和范围。
逐项排查：哪些遗留项会阻断下阶段
排查的目标是把“能不能启动”转化为“哪些条目阻断、哪些条目不阻断”的具体结论。排查应按交付物清单逐项核对，先看关键路径交付物，再看支撑性文档，避免在次要事项上耗费判断精力。
排查顺序建议如下：
- 核对关键路径交付物。列出下阶段任务直接依赖的输入，逐项确认是否存在、是否达到可用状态、是否经过确认。这一层出现缺口，通常构成阻断。
- 核对评审结论与问题关闭情况。查看评审记录中的遗留问题清单，确认高优先级问题是否关闭，带条件通过的结论是否已满足条件。
- 核对支撑性文档与辅助事项。确认非关键文档、归档、格式类事项的剩余工作量，评估是否影响下阶段开展。
- 汇总形成阻断项清单与非阻断项清单，分别标注责任人和预计关闭时间。
区分阻断项与非阻断项，可参考三条标准：下阶段任务是否直接消费该交付物；缺失是否会导致下阶段产生不可逆的返工；是否存在可接受的替代输入或临时方案。三条中前两条成立，一般应视为阻断项；仅第三条成立且影响范围有限，可列为非阻断项并纳入跟踪。
排查过程需要留存证据，便于后续复核和升级决策。应保留的材料包括：评审结论与签到记录、遗留问题与缺陷记录及其状态、关键交付物的确认或签字记录、阻断项清单及责任人确认。证据的作用是让“已具备启动条件”这一判断可追溯，避免口头确认后责任不清。
有条件启动下阶段的处置步骤
确认遗留项属于非阻断性质后，可以有条件启动下阶段。有条件启动的核心是把遗留项的风险显性化，限定并行推进的范围，并预设停止点，防止遗留问题在下阶段扩散。
启动前应完成三项准备。第一，形成书面风险评估，说明遗留项内容、可能影响的下阶段任务、发生概率与应对预案，由阶段负责人和下阶段负责人共同确认。第二，为每个遗留项指定责任人和关闭期限，期限应与下阶段关键节点对齐，避免遗留项无限期挂账。第三，明确并行推进的范围限制，例如下阶段可以先开展不依赖遗留项的部分工作，依赖部分待遗留项关闭后再启动。
启动后需要设置停止条件。常见停止条件包括：遗留项超过约定期限未关闭；遗留项影响范围扩大，波及下阶段关键路径；下阶段出现与遗留项相关的质量问题。触发停止条件时，应暂停相关并行工作，回到阶段衔接判断，而不是继续带病推进。
以下情形需要升级决策，由项目负责人或更高层级管理者裁定：遗留项涉及关键交付物的核心内容；遗留项关闭期限无法与下阶段节点对齐；责任人对风险评估结论存在分歧；停止条件已被触发但相关方对是否暂停意见不一致。升级时应携带阻断项清单、风险评估和证据材料，便于快速决策。
在协作工具中承载这一过程，可以把阶段交付物清单、评审记录和遗留项跟踪放在同一处：交付物按阶段列出并标注状态，评审结论与遗留问题关联到对应条目，遗留项设定责任人与关闭期限并定期更新。ONES 的项目管理能力可用于承载工作项状态与评审记录，让阻断项清单和下阶段任务在同一视图中对照，减少口头确认带来的信息遗漏。工具承载的是记录与跟踪，启动与否的判断仍应依据阶段出口标准和依赖关系。
如何验证恢复并防止再次发生
有条件启动后，需要验证遗留项确实在关闭、下阶段工作未受实质影响，并把本次判断经验固化到阶段出口标准中，形成闭环。
遗留项关闭情况应定期复核。按约定周期检查每个遗留项的状态、责任人和剩余工作量，对临近期限仍未关闭的条目提前预警。复核结果应更新到遗留项清单，并在阶段例会上通报，确保相关方对风险状态有共同认知。
下阶段关键节点应做回归验证。在依赖遗留项的任务完成时，检查其输出是否受到遗留问题影响，例如接口开发完成后验证接口定义是否与设计一致，测试执行后确认缺陷分布是否集中在遗留项相关模块。回归验证发现问题，说明此前的启动判断需要修正，应及时调整并行范围或触发停止条件。
防止再次发生，重点在阶段出口标准的固化与评审机制改进。把本次出现的遗留项类型纳入出口检查清单，明确哪些条目必须在阶段关闭前完成、哪些可以带条件移交；评审时要求逐项核对出口标准，而不是笼统给出通过结论；对反复出现的同类遗留问题，分析其在流程中的产生环节，从源头减少带条件移交的情形。
复发信号需要提前识别。若同一类遗留项在多个阶段反复出现，或遗留项关闭期限频繁延期，说明出口标准执行不严或评估过于乐观，应再次审视阶段衔接判断，必要时暂缓后续启动，先修复流程本身。验证与预防形成闭环后，阶段衔接判断才能从个案处置转为可重复的管理动作。
常见问题
上阶段评审结论是“带条件通过”，下阶段能直接启动吗？
可以启动的前提是条件已经明确且可控。先查看评审记录中列出的条件项：如果条件涉及下阶段直接依赖的关键输入，例如接口定义尚未确认、需求基线尚未冻结，应先关闭这些条件再启动主体工作；如果条件只是补充说明性文档或非关键缺陷修复，可以将其列入遗留项清单，明确责任人和关闭期限后，限定范围启动下阶段。
无论哪种情况，都建议在启动前把条件项与下阶段任务的对应关系写清楚，避免“带条件通过”在实际执行中变成无人跟踪的挂账事项。
如果遗留项关闭期限已到但工作仍未完成，应该怎么处理？
期限到期未关闭，应先判断遗留项当前的影响范围是否发生变化。若影响仍限于原定范围，可评估是否延期，但延期需要重新确认责任人和新的关闭时间，并同步调整下阶段并行范围；若遗留项已波及下阶段关键路径，或已引发相关质量问题，应触发停止条件，暂停依赖该遗留项的并行工作。
期限频繁延期本身也是一个信号，说明此前的风险评估偏乐观或出口标准执行不严，需要回到阶段衔接判断，而不是简单续期了事。
有条件启动后，下阶段已经完成的部分工作需要回退吗？
是否回退取决于遗留项对已完成工作的实际影响。先核对已完成任务是否直接消费了存在问题的交付物：如果消费了且输出受到影响，应评估返工范围并安排修正；如果未直接消费，或输出经回归验证未受影响，可以保留已完成工作，继续跟踪遗留项关闭。
回退判断应基于回归验证结果和证据记录，避免因遗留项存在就整体推翻已完成工作，也避免不做核查直接放行。
小团队没有专职评审人员，阶段出口判断可以简化吗？
可以简化形式，但判断依据仍应保留。小团队可以由阶段负责人和下阶段负责人共同核对交付物清单与出口标准，用简短的书面记录替代正式评审会，记录内容包括关键交付物状态、遗留项清单、责任人和关闭期限。
简化的是会议形式和参与人数，关键输入是否具备、遗留项是否可控这两个判断不能省略。否则阶段衔接判断会退化为口头确认，后续出现问题时难以追溯。
多个阶段同时存在遗留项时，排查顺序怎么定？
按对当前下阶段任务的影响程度排序，而不是按阶段先后平均用力。先排查当前下阶段任务直接依赖的交付物，再看更早阶段遗留但仍有影响的条目，最后处理与当前工作无直接关联的历史收尾事项。
如果多个遗留项同时构成阻断，应优先处理位于关键路径上、关闭周期最长的那一项，并据此调整下阶段的启动范围。排查结论汇总到同一份清单中，便于统一跟踪和升级决策。
