瀑布项目通常按顺序划分为启动、规划、执行、监控与控制、收尾五个阶段，部分组织会把需求与设计从规划中拆出单列。每个阶段都以明确的进入条件开始，以核心交付物通过评审或验收作为完成标志，上一阶段成果确认后才进入下一阶段。本文按阶段清单、概念边界、进入条件与交付物、衔接机制、相邻概念和常见误解逐项展开，帮助你在实际项目中判断“一个阶段何时算开始、何时算结束”。
要点总览（TL;DR）
- 瀑布项目通常按启动、规划、执行、监控与控制、收尾五个阶段顺序推进，需求与设计可从规划中拆出单列。
- 每个阶段以进入条件开始、以核心交付物通过评审或验收为完成标志，上一阶段确认后才进入下一阶段。
- 阶段衔接依靠阶段关口评审、基线冻结和变更控制，评审不通过时工作退回本阶段返工。
- 阶段与里程碑、迭代、工作包是不同概念：里程碑是时间点，迭代是敏捷框架的工作段，工作包是阶段内部的管理单元。
- 阶段长度和数量应随项目规模调整，等长划分和阶段越多越规范都是常见误解。
瀑布项目包含哪些阶段：一句话答案与阶段清单
瀑布项目的典型阶段是启动、规划、执行、监控与控制、收尾。这个顺序体现的是工作重心的推进：先把项目立起来，再把做法定下来，然后按既定做法产出成果，全程对照基准纠偏，最后完成验收和收尾。五个阶段并非每家企业都原样照搬，但职责划分大体一致。
- 启动：确认项目存在的理由、目标、关键干系人和授权，回答“为什么做、由谁负责”。
- 规划：把目标拆成可执行的范围、进度、成本、质量和资源安排，形成经过评审的计划基准。
- 执行：按计划组织人员完成可交付成果，并开展过程质量检查。
- 监控与控制：跟踪实际进展与基准的偏差，处理变更请求，发布状态报告。
- 收尾：完成验收签字、资料归档、经验总结和资源释放。
常见变体是把需求分析和设计从规划中拆出来单列。需求阶段以需求规格说明通过确认为完成标志，设计阶段以技术方案或设计文档通过评审为完成标志。这种拆法适合需求复杂、设计工作量大的项目，代价是阶段数量增加、评审点增多。另一种变体是把监控与控制视为贯穿执行期的活动，而非独立时间段，但职责内容不变。
瀑布阶段的定义与边界：什么算一个阶段
在瀑布方法中，一个阶段是围绕一组可交付成果组织起来的工作区间，具备三个要素：明确的产出物、可核验的评审点、清晰的责任人。三者缺一，阶段就容易退化成时间上的分段。判断某段工作是否构成一个阶段，可以问：它结束时是否有需要确认的成果？确认由谁做出？确认不通过时工作是否退回？
阶段与里程碑不同。里程碑是时间轴上的一个检查点，本身不包含工作区间；阶段是有起点、有过程、有产出的工作段，其结束处通常设置里程碑。阶段与工作包也不同：工作包是范围分解到可估算、可分配层级的单元，属于规划阶段的产物，是阶段内部的管理对象，而非阶段本身。
本文讨论的范围限于单个项目内部的阶段构成、进入条件与交付物。组织级的研发流程制度、阶段门禁审批规则、敏捷迭代框架的运作方式属于另外的主题，不在本文展开。项目实际执行时，阶段划分需要与所在组织的流程要求对齐，本文给出的是方法层面的通用框架。
各阶段的进入条件、核心交付物与完成标志
下表按五个阶段列出进入条件、核心交付物和完成标志，可作为项目启动会或阶段评审时的对照清单。表中内容是通用做法，具体项目的交付物名称和评审形式可按组织模板调整。
| 阶段 | 进入条件 | 核心交付物 | 完成标志 |
|---|---|---|---|
| 启动 | 业务需求或合同依据明确，发起人确定 | 项目章程、干系人清单、启动会纪要 | 章程获批，启动会确认目标与授权 |
| 规划 | 项目章程生效，核心团队到位 | 范围说明书、工作分解结构、进度与成本基准、质量与风险计划 | 计划通过评审，基准冻结 |
| 执行 | 计划基准发布，资源与任务已分配 | 按基准产出的产品、系统或服务成果，质量检查记录 | 可交付成果完成并通过质量检查 |
| 监控与控制 | 执行开始，基准可测量 | 状态报告、偏差分析、变更请求与变更记录 | 偏差得到处理，变更完成审批与落实 |
| 收尾 | 成果交付完成，验收条件具备 | 验收签字文件、经验总结、归档资料、资源释放记录 | 验收通过，资料归档，团队解散或转岗 |
启动阶段的关键在于授权。项目章程应写清目标、范围边界、主要干系人和项目经理的权限，缺少授权依据的项目在后续资源协调中容易受阻。规划阶段的关键在于基准：范围、进度、成本三项基准一旦冻结，后续变更就有了比较对象。执行阶段的关键在于按基准产出并同步做质量检查，把问题留在过程内解决。监控与控制阶段的关键在于偏差识别和变更控制，状态报告要能回答“与基准相比偏了多少、准备怎么处理”。收尾阶段的关键在于验收签字和经验总结，验收文件是项目结束的正式凭据，经验总结则为后续项目提供参考。
需要说明的是，监控与控制虽然单列为一个阶段，实际运作中与执行并行。执行期间按固定节奏收集进展数据、比对基准、处理变更，这些动作贯穿执行全过程，而非等到执行结束后才开始。
阶段之间如何衔接：评审、基线与变更控制
瀑布阶段顺序推进的机制由三件事支撑：阶段关口评审、基线冻结和变更控制。三者配合，才能让“上一阶段确认后才进入下一阶段”真正落地。
阶段关口评审是衔接的主要手段。每个阶段结束前，由责任人组织评审，对照该阶段的完成标志逐项核对交付物。评审通过，阶段关闭，下一阶段获得进入条件；评审不通过，工作退回本阶段返工，返工范围和期限由评审结论确定。关口评审的价值在于把问题挡在阶段边界上，避免缺陷带入后续阶段放大成本。
基线冻结是评审通过后的动作。规划阶段形成的范围、进度、成本基准经批准后冻结，作为后续比较的参照。冻结不意味着不能改，而是改动必须走变更请求：提出变更、评估对范围进度成本的影响、由授权人审批、批准后更新基准并记录。变更记录本身也是监控与控制阶段的交付物之一。
上一阶段未通过时的处理需要提前约定。常见做法是明确返工责任人和时限，返工完成后重新评审；若返工影响已批准的下游计划，则同步发起变更请求调整基准。把回退路径写进项目计划，比在评审现场临时协商更可控。在项目协作工具中，阶段关口评审可以落实为评审任务与交付物文档的关联，变更请求以工作项形式流转审批，评审结论和变更记录留存在同一项目空间内，便于后续追溯。ONES 支持工作项状态流转与文档协作，可用于承载这类阶段评审和变更记录的管理动作，具体配置按团队流程设定。
容易混淆的相邻概念：阶段、里程碑与迭代
阶段、里程碑、迭代、工作包在实际沟通中经常混用，区分它们有助于准确描述项目状态。下表按同一口径对比。
| 概念 | 是否有工作区间 | 主要作用 | 与阶段的关系 |
|---|---|---|---|
| 阶段 | 有，包含一组工作和产出 | 组织工作推进，设置评审关口 | 本身 |
| 里程碑 | 无，是时间点 | 标记关键检查点或重要事件 | 通常设在阶段结束处 |
| 迭代 | 有，固定周期的重复工作段 | 在短周期内交付可用增量并获取反馈 | 敏捷框架的组成单位，与瀑布阶段是不同方法的结构 |
| 工作包 | 有，范围分解的最小管理单元 | 估算、分配和跟踪具体工作 | 位于阶段内部，是规划阶段的产物 |
阶段与里程碑的区别最容易被忽略：里程碑没有持续时间和产出，它只是“某件事已达成”的标记；阶段则有完整的工作过程和交付物。阶段与迭代的区别在于方法归属：迭代是敏捷框架中固定周期、以可用增量为目标的工作段，瀑布阶段则以顺序推进和关口评审为特征。两者可以组合使用，例如在瀑布项目的执行阶段内部采用迭代方式组织开发，但阶段本身的性质不变。阶段与工作包是层级关系：阶段在上，工作包在下，一个阶段通常包含多个工作包。
具体例子与常见误解
以一个企业客户管理系统上线项目为例（演示情景）。启动阶段，业务部门提出系统替换需求，发起人批准项目章程，召开启动会明确目标和项目经理授权。规划阶段，团队编制范围说明书和工作分解结构，排出上线时间表，计划通过评审后冻结基准。执行阶段，开发、配置和数据迁移按计划推进，每完成一个模块做一次质量检查。监控与控制阶段，团队每两周比对一次进度，发现接口联调延期后提交变更请求，调整后续排期并更新基准。收尾阶段，业务方完成验收签字，团队整理配置文档和操作手册，召开总结会记录经验，项目成员回归原岗位。整个过程按阶段推进，每个阶段的结束都以评审或验收为标志。
围绕阶段划分，有几个常见误解值得澄清：
- 误解一：各阶段必须等长。阶段长度取决于工作量和风险，规划阶段往往比启动阶段长得多，收尾阶段可能很短。等长划分没有方法依据。
- 误解二：阶段越多越规范。阶段数量应与项目规模和复杂度匹配。小型项目把需求和设计并入规划，减少评审点，反而更高效；阶段过多会增加协调成本和等待时间。
- 误解三：阶段评审只是走形式。评审的作用是确认完成标志是否达成，没有评审结论的阶段无法判断能否进入下一阶段，后续偏差也就失去了追溯依据。
- 误解四：进入下一阶段后上一阶段完全封闭。已关闭阶段发现的问题仍需处理，通常通过变更请求或缺陷流程回流，处理记录纳入当前阶段的监控范围。
阶段划分随项目规模调整是正常做法。小项目可以合并阶段、简化交付物；大项目可以拆分阶段、增加专项评审。判断标准是每个阶段是否仍有明确的产出、评审点和责任人，而非阶段数量的多少。
常见问题
小型项目是否必须完整走完五个阶段？
不必。阶段划分应与项目规模和复杂度匹配。小型项目可以把需求与设计并入规划，合并部分评审点，减少协调成本；也可以简化交付物名称和评审形式。判断标准是每个保留的阶段是否仍有明确的产出、评审点和责任人。合并阶段时，需要确认被合并工作的完成标志在合并后的阶段评审中仍能被核验，避免出现无人确认的中间成果。
阶段评审未通过时，已经开始的下一阶段工作怎么处理？
常见做法是先暂停或收缩下一阶段中依赖该成果的工作，把返工范围和期限写进评审结论，返工完成后重新评审。若返工影响已批准的下游计划，同步发起变更请求调整基准。把回退路径提前写进项目计划，比在评审现场临时协商更可控。已经投入的下游工作应评估是否需要返工，处理记录纳入当前阶段的监控范围。
监控与控制阶段为什么常被说成与执行并行？
监控与控制单列为一个阶段，是为了明确偏差识别、变更控制和状态报告的职责，但实际运作中这些动作贯穿执行全过程。执行期间按固定节奏收集进展数据、比对基准、处理变更，而非等到执行结束后才开始。因此项目计划中可以把监控与控制的活动排进执行期的时间表，同时保留独立的职责分工和交付物要求。
瀑布项目执行阶段内部可以采用迭代方式组织开发吗？
可以。阶段与迭代属于不同方法的结构：瀑布阶段以顺序推进和关口评审为特征，迭代是敏捷框架中固定周期、以可用增量为目标的工作段。在瀑布项目的执行阶段内部采用迭代方式组织开发，阶段本身的性质和关口评审要求不变。这种组合适合需求相对稳定、但开发工作需要短周期反馈的项目，前提是阶段层面的交付物和完成标志仍然清晰可核验。
阶段划分需要和组织的流程制度对齐到什么程度？
本文给出的是方法层面的通用框架，实际项目需要与所在组织的流程要求对齐。对齐的重点通常是阶段门禁的审批规则、交付物模板和评审记录要求。如果组织制度规定的阶段数量或名称与通用五阶段不同，以组织要求为准，同时保留每个阶段的产出、评审点和责任人三要素。组织级流程制度的设计属于另外的主题，不在本文展开。
