瀑布项目按阶段顺序推进，每个阶段都用“进入条件—核心交付物—完成标志”三件事来管理：进入条件确认前置输入和批准是否齐备，核心交付物是必须产出并可评审的成果，完成标志是评审通过、基线确立或验收签署等可核验事件。本文按可行性、需求、设计、开发实现、测试、上线交付、收尾七个阶段逐一说明判断口径，并解释阶段门评审、基线与变更控制如何衔接，适用于需求相对明确、计划性较强的单项目管理场景。
要点总览（TL;DR）
- 瀑布项目通常按可行性、需求、设计、开发实现、测试、上线交付、收尾七个阶段推进，阶段之间以基线为界，上一阶段完成标志未达成原则上不进入下一阶段。
- 进入条件管入口，核心交付物管过程产出，完成标志管出口，三者共同构成阶段门，评审时逐条核对、三项齐备才放行。
- 完成标志要能被第三方核查，例如评审记录、基线版本号、验收签署文件，文档写完本身不构成放行依据。
- 阶段门与里程碑分工不同：里程碑标记时间点，阶段门给出放行决策；混合模式可保留立项、上线交付、收尾等关键阶段门，其余改用迭代推进。
- 阶段数量应与项目风险和规模匹配，小项目合并阶段、保留关键风险点作为阶段门，往往比层层设门更有效。
瀑布项目一般划分为哪些阶段
瀑布项目通常按七个阶段顺序推进：可行性、需求、设计、开发实现、测试、上线交付、收尾。前一阶段的成果构成后一阶段的输入，阶段之间以基线为界，形成一条从立项论证到交付收尾的完整链条。各阶段的一句话职责如下：
- 可行性阶段：论证项目是否值得做、能否做，形成立项依据。
- 需求阶段：把业务目标转化为可确认、可追踪的需求范围。
- 设计阶段：把需求转化为可实施的技术方案与规格说明。
- 开发实现阶段：按设计完成产品构建与单元级验证。
- 测试阶段：对构建成果进行系统验证，确认满足需求与质量标准。
- 上线交付阶段：完成部署、数据迁移与用户验收，移交运行。
- 收尾阶段：完成合同结算、资料归档、经验总结与团队释放。
阶段与里程碑、基线的关系需要分清。里程碑标记项目中的重要时间点、事件或决策点，阶段完成通常对应一个里程碑；基线则是被正式批准、此后变更须走审批的成果版本。一个阶段可以有多个里程碑，但阶段完成标志一般落在该阶段关键成果的基线确立或验收签署上。
阶段划分可以按项目规模裁剪。小型项目可将可行性并入需求阶段，或将上线交付与收尾合并；大型或强监管项目则可能在设计与开发之间增加安全评审、在测试与上线之间增加试运行阶段。裁剪的依据是风险大小、合同要求和外部监管条件，裁剪结果应在项目计划中明确写出，避免执行中临时增减。
需要说明的是，ONES 官网对瀑布项目的表述采用启动、规划、执行、监控、结项五阶段口径，与本文的七阶段划分属于不同颗粒度。两种划分可以对应：可行性、需求、设计大体落在启动与规划阶段，开发实现、测试落在执行与监控阶段，上线交付与收尾落在结项阶段。团队选用哪种划分，取决于管理精细度需要，不必强行统一。
进入条件、核心交付物与完成标志分别指什么
进入条件是启动一个阶段前必须满足的前置条件，常见内容包括：上一阶段完成标志已达成、关键交付物已评审通过并纳入基线、所需人员与资源到位、必要的批准或合同手续完成。进入条件的作用是防止在输入不完整的情况下开工，把返工风险挡在阶段入口。
核心交付物是阶段必须产出的可评审成果，例如需求阶段的需求规格说明书、设计阶段的设计文档、测试阶段的测试报告。核心交付物强调“可评审”：它有明确的责任人、版本和评审记录，能够被下游阶段直接使用。仅存在于个人电脑或口头沟通中的内容，不构成阶段交付物。
完成标志是判定阶段结束的可核验事件，常见形式包括评审会通过并形成结论、成果纳入基线、验收方签署确认、关键指标达到约定阈值。完成标志要能被第三方核查，例如查得到评审记录、基线版本号和签署文件，避免用“基本完成”“大家认可”这类主观描述代替。
三者共同构成阶段门：进入条件管入口，核心交付物管过程产出，完成标志管出口。阶段门评审就是对照这三项逐条核对，三项都满足才放行进入下一阶段。这套机制的价值在于把质量检查点前移，让问题在阶段内暴露，而不是在项目末期集中爆发。
各阶段的进入条件、核心交付物和完成标志对照
下表按七个阶段列出三要素的典型内容。实际项目应结合规模、合同与监管要求调整，表中内容作为判断口径的起点，不作为统一模板强制套用。
| 阶段 | 进入条件 | 核心交付物 | 完成标志 |
|---|---|---|---|
| 可行性 | 业务需求或项目意向已提出；预算与资源意向明确；可组建论证小组 | 可行性研究报告、初步范围说明、风险与投入估算 | 立项评审通过，项目章程或立项批复签署 |
| 需求 | 项目已立项；业务方代表已确定；需求调研计划获认可 | 需求规格说明书、需求跟踪矩阵、范围边界说明 | 需求评审通过，需求基线确立，范围变更须走审批 |
| 设计 | 需求基线已确立；架构与技术负责人到位；设计标准已明确 | 概要设计、详细设计、接口与数据设计、设计评审记录 | 设计评审通过，设计基线确立，开发任务可据此拆分 |
| 开发实现 | 设计基线已确立；开发环境与代码库就绪；开发计划已批准 | 可运行的构建版本、单元测试记录、代码与配置说明 | 构建版本通过冒烟验证并移交测试，代码完成入库 |
| 测试 | 测试版本已移交；测试环境与用例就绪；准入标准已约定 | 测试计划、测试用例、缺陷记录、测试报告 | 测试报告评审通过，遗留缺陷达到约定退出标准 |
| 上线交付 | 测试退出标准已达成；上线方案与回退方案已批准；用户培训完成 | 上线部署记录、数据迁移记录、用户验收报告、运维手册 | 用户验收签署，系统在生产环境稳定运行达到约定观察期 |
| 收尾 | 验收已签署；结算资料齐备；遗留事项清单已确认 | 项目总结报告、资料归档清单、合同结算文件、经验教训记录 | 收尾评审通过，资料完成归档，团队与资源正式释放 |
表格中每一行的完成标志都对应下一行的进入条件，这是瀑布阶段衔接的基本逻辑。例如需求基线确立，既是需求阶段的完成标志，也是设计阶段进入条件中“需求基线已确立”的来源。团队在制定项目计划时，可以把这些节点设置为里程碑，便于跟踪。
阶段门如何运作：评审、基线与变更控制
阶段门评审由项目经理组织，参与角色通常包括阶段交付物责任人、下游阶段代表、质量或架构评审人，涉及验收或合同事项时还需业务方或客户代表参加。评审结论一般有三种形式：通过、有条件通过、不通过。结论应形成书面记录，写明核对项、遗留问题和整改责任人。
基线确立后，变更须走审批。以需求基线为例，基线之后提出的需求增删改，应提交变更申请，说明变更内容、影响范围、对进度与成本的影响，由变更控制责任人或评审组决定是否批准。批准后更新基线版本并通知下游，未批准的变更不进入开发范围。基线的意义在于给变更一个可追溯的入口，让范围蔓延变得可见、可控。
条件不满足时的处置需要事先约定。常见做法包括：回退到上一阶段补充完善后重新评审；对不影响关键路径的次要问题采用有条件通过，列出整改清单并设定关闭期限，在下一阶段门评审时一并核查。有条件通过应控制使用范围，涉及安全、合规或核心范围的问题不宜采用。
阶段门与里程碑容易混淆。里程碑是时间点标记，回答“到了哪个节点”；阶段门是决策机制，回答“能不能进入下一阶段”。一个里程碑可以只是进度提示，而阶段门必须伴随评审结论和放行决定。在项目计划中把两者分开设置，可以避免把“时间到了”误当成“条件满足了”。
这些管理动作需要有承载的地方：阶段交付物集中归档、评审记录可查、基线版本可对比、变更申请走审批流。ONES 瀑布项目管理解决方案基于 PMI、CMMI 理论，覆盖从立项到收尾的瀑布项目管理全过程，将需求管理、研发管理、测试管理和资源管理流程连接起来；其项目计划功能支持按项目阶段或交付物维度做工作分解，并用里程碑标记重要决策点，基线功能支持对比计划与执行的偏差并追溯变更细节。深圳农商行依托 ONES 瀑布项目模板对关键里程碑和交付物进行规范化管理，这一案例的做法可作为参考，具体效果因组织而异。
与迭代交付、混合模式的区别
瀑布阶段门与敏捷迭代评审的区别在于节奏和决策对象。瀑布阶段门按阶段设置，评审的是阶段成果是否达到基线要求，通过后范围相对固定；敏捷迭代评审按固定周期进行，评审的是增量成果并收集反馈，下一轮迭代的范围可以调整。前者强调阶段出口的把关，后者强调持续交付与响应变化。
混合模式下通常保留部分阶段门，裁剪另一部分。常见做法是：立项、上线交付、收尾保留正式阶段门，因为涉及投入决策、生产变更和合同结算；需求、设计、开发实现、测试之间改用迭代方式推进，以增量评审代替逐阶段门评审。保留哪些、裁剪哪些，取决于风险集中在哪里，以及合同或监管是否要求正式审批节点。
交付物粒度也有差异。瀑布阶段的交付物偏向成套的规格与报告，在阶段末一次性评审；迭代交付的成果偏向可运行的小增量，每个迭代结束都有可演示的内容。混合模式往往两者并存：阶段层面保留需求规格、验收报告等成套文档，迭代层面产出增量版本和迭代评审记录。团队需要明确哪类成果进入哪一级评审，避免同一成果被重复评审或无人评审。
一个具体例子与常见误解
以需求阶段向设计阶段过渡为例。进入需求阶段的条件是项目已立项、业务方代表确定、调研计划获认可。阶段内产出需求规格说明书、需求跟踪矩阵和范围边界说明。完成标志是需求评审会通过、需求基线确立。此后设计阶段的进入条件随之满足：需求基线已确立、架构与技术负责人到位、设计标准明确。设计阶段据此产出概要设计与详细设计，评审通过后确立设计基线，开发实现阶段才启动。这个链条中任何一环缺失，都会让下游阶段在输入不完整的情况下开工。
常见误解一：完成标志等于文档写完。文档写完只是产出动作结束，完成标志要求评审通过并形成结论、纳入基线或完成签署。没有评审记录的文档，不能作为阶段放行依据。
常见误解二：进入条件可以事后补。进入条件的作用是在开工前确认输入齐备，事后补批会让阶段内的工作建立在未确认的假设上，返工成本更高。确因外部原因无法齐备的，应在阶段门评审中明确记录为例外并评估影响，而不是默认跳过。
常见误解三：阶段越多越规范。阶段数量应与项目风险和规模匹配，小项目设置过多阶段门会增加评审负担、拉长周期，却未必提升质量。裁剪阶段时把关键风险点保留为阶段门，其余合并推进，往往更符合实际。
把这三条误解反过来看，就是三要素落地的检查清单：完成标志是否有可核验的记录，进入条件是否在开工前确认，阶段划分是否与风险匹配。按这张清单逐阶段核对，瀑布项目的阶段管理就能从形式走向可验证的控制。
常见问题
阶段门评审没有通过，项目应该怎么处理？
先看未通过的原因落在哪一项。如果是核心交付物缺失或质量不达标，通常回退到本阶段补充完善后重新评审；如果是进入条件在开工时就不齐备，需要评估已开展工作受影响的范Χ，补齐输入后重新确认。对不影响关键路径的次要问题，可以采用有条件通过，列出整改清单、设定关闭期限，在下一阶段门评审时一并核查。涉及安全、合规或核心范围的问题，不宜采用有条件通过。
无论哪种处置，评审结论都应形成书面记录，写明核对项、遗留问题和整改责任人，避免口头放行。
需求基线确立之后，业务方又提出新需求，还能改吗？
可以改，但要通过变更流程。基线之后的需求增删改应提交变更申请，说明变更内容、影响范围以及对进度和成本的影响，由变更控制责任人或评审组决定是否批准。批准后更新基线版本并通知下游阶段，未批准的变更不进入开发范围。
基线的意义是给变更一个可追溯的入口，让范围变化可见、可控。如果新需求频繁出现且体量较大，也可以考虑评估项目是否更适合采用迭代或混合方式推进，把变化纳入固定节奏处理。
小型项目也要走七个阶段吗？
不必。阶段划分可以按项目规模、合同要求和外部监管条件裁剪。小型项目常见的做法是把可行性并入需求阶段，或将上线交付与收尾合并；大型或强监管项目则可能在设计与开发之间增加安全评审、在测试与上线之间增加试运行。
裁剪的关键是把风险集中的环节保留为阶段门，其余合并推进。裁剪结果应在项目计划中明确写出，避免执行过程中临时增减阶段，导致评审口径不一致。
混合模式下，哪些阶段门值得保留？
通常保留涉及投入决策、生产变更和合同结算的节点，例如立项、上线交付、收尾；需求、设计、开发实现、测试之间可以改用迭代方式推进，以增量评审代替逐阶段门评审。
保留哪些、裁剪哪些，取决于风险集中在哪里，以及合同或监管是否要求正式审批节点。同时要明确哪类成果进入阶段级评审、哪类成果进入迭代级评审，避免同一成果被重复评审或无人评审。
阶段完成标志和里程碑是不是一回事？
两者相关但不同。里程碑是时间点标记，回答“到了哪个节点”；阶段门是决策机制，回答“能不能进入下一阶段”。阶段完成通常对应一个里程碑，但里程碑本身可以只是进度提示，而阶段门必须伴随评审结论和放行决定。
在项目计划中把两者分开设置，可以避免把“时间到了”误当成“条件满足了”。一个阶段可以有多个里程碑，阶段完成标志一般落在该阶段关键成果的基线确立或验收签署上。
