瀑布项目管理按“需求确认—设计—开发—测试—验收交付”的顺序推进，每个阶段以明确的输入、交付物和评审通过作为进入下一阶段的条件。落地时先定阶段划分与里程碑，再定各阶段负责人和交付物清单，然后用变更控制和阶段评审守住顺序，最后用阶段完成检查表判断能否放行。本文面向第一次负责瀑布项目的读者，给出可直接套用的阶段划分表、分阶段操作卡、角色责任矩阵和放行检查清单。
要点总览（TL;DR）
- 瀑布项目从阶段划分开始：按需求、设计、开发、测试、验收交付搭骨架，为每个阶段设关口评审，评审通过才进入下一阶段。
- 每个阶段按输入、动作、输出、完成标志四要素执行，完成标志即放行条件，未满足时不进入下一阶段。
- 角色与交付物用 RACI 矩阵固定下来，每份关键交付物只设一个审批人，阶段交接以书面确认记录为准。
- 需求变更走申请、影响评估、审批、回写计划四步；评审不通过、关键交付物缺失、严重缺陷未关闭等情形触发返工或阶段回退。
- 阶段放行和项目自查使用同一套检查清单，检查结果与阶段计划、变更记录一并留存，作为复盘参考。
瀑布项目先定哪几件事：阶段划分与里程碑
瀑布项目启动后第一件事是把项目切成阶段，并为每个阶段设一个关口。阶段切分决定了后续计划、人员安排和评审节奏，切得太粗会失去控制点，切得太细会增加评审负担。常见做法是先按典型序列搭骨架，再根据项目规模、交付形态和合同或验收节点调整粒度。
典型阶段序列为：需求、设计、开发、测试、验收交付。规模较小的项目可以把设计与开发合并为一个阶段，或把验收交付并入测试阶段末尾；涉及外部合同验收的项目，通常需要把验收交付单列为独立阶段，以便与合同节点对齐。阶段粒度的判断依据主要有三条：项目周期长短、交付物是否需要外部确认、合同或验收节点是否要求单独汇报。
里程碑与阶段关口是两个相关但不同的概念。阶段关口是阶段结束时的评审动作，评审通过才允许进入下一阶段；里程碑是项目中的重要时间点、事件或决策点，通常设在关口处，也可以设在阶段内部的关键节点上。设置里程碑时，应让它对应一个可验证的结果，例如“需求规格说明书评审通过”“测试报告签署”，避免只写日期。
阶段划分的输出物是一份阶段计划表和一份里程碑清单。阶段计划表至少包含阶段名称、起止条件、负责人、主要交付物和评审方式；里程碑清单包含里程碑名称、计划日期、对应交付物和达成判定标准。两份表在项目启动会上确认，作为后续进度跟踪和偏差判断的基准。
| 阶段 | 起止条件 | 里程碑 | 评审方式 |
|---|---|---|---|
| 需求 | 项目立项完成至需求规格说明书评审通过 | 需求基线确认 | 需求评审会，需求方与开发、测试共同参加 |
| 设计 | 需求基线确认至设计评审通过 | 设计基线确认 | 设计评审会，技术负责人审批 |
| 开发 | 设计评审通过至开发完成并自测通过 | 开发完成 | 阶段进度评审，抽查自测记录 |
| 测试 | 开发完成至测试报告签署 | 测试通过 | 测试评审会，缺陷收敛情况确认 |
| 验收交付 | 测试报告签署至验收结论签署、交付物归档 | 验收通过 | 用户验收会，验收方签署结论 |
阶段计划与里程碑确定后，需要落到可跟踪的载体上。ONES 的项目计划支持按项目阶段或交付物维度创建工作分解结构，为任务设置前后置依赖，并用里程碑标记重要时间点与决策点；设置计划与里程碑基线后，可以对比计划与执行的偏差，追溯变更细节。这样阶段关口是否到期、里程碑是否达成，在项目执行过程中有据可查。
每个阶段怎么走：输入、动作、输出与完成标志
阶段划分解决“切成几段”，本节解决“每段内部怎么做”。每个阶段都按输入、动作、输出、完成标志四要素描述，完成标志即放行条件，未满足时不进入下一阶段。
需求阶段
输入是项目立项材料、业务方原始诉求和合同或任务书中的范围描述。动作包括需求收集、需求分析与澄清、编写需求规格说明书、组织需求评审。输出是经评审通过的需求规格说明书和需求基线。完成标志是需求评审结论为通过，评审意见已闭环，需求方与开发、测试三方对范围无遗留异议。
设计阶段
输入是需求基线。动作包括概要设计、详细设计、技术方案确认和设计评审。概要设计说明系统结构、模块划分和接口关系，详细设计说明模块内部逻辑、数据结构和关键算法。输出是设计文档和设计评审记录。完成标志是设计评审通过，技术负责人确认方案可实施，设计文档与需求条目可对应追溯。
开发阶段
输入是设计文档和开发计划。动作包括任务分解、编码、单元自测和阶段内进度跟踪。任务分解应落到可分配、可估算的粒度，每项任务有负责人和计划完成时间。输出是完成编码并通过自测的软件版本、任务完成记录。完成标志是开发任务全部关闭，自测记录齐全，遗留问题已登记并评估对测试阶段的影响。
测试阶段
输入是开发完成的版本、需求规格说明书和设计文档。动作包括编写测试计划与测试用例、执行测试、缺陷提交与回归、编写测试报告。缺陷闭环要求每个缺陷有处理结论：修复验证通过、延期处理或确认不修复，延期和不修复需有审批记录。输出是测试用例、缺陷记录和测试报告。完成标志是测试报告签署，严重级别缺陷全部关闭，遗留缺陷有明确处理意见。
验收交付阶段
输入是测试报告和验收标准。动作包括对照验收标准逐项确认、组织用户验收、整理交付物并归档。输出是验收结论、交付物清单和归档记录。完成标志是验收方签署验收结论，交付物按清单归档完毕，遗留事项形成书面处理计划。
| 阶段 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 需求 | 立项材料、原始诉求、范围描述 | 收集、分析、编写规格说明、评审 | 需求规格说明书、需求基线 | 评审通过、意见闭环 |
| 设计 | 需求基线 | 概要设计、详细设计、方案确认、评审 | 设计文档、评审记录 | 评审通过、可追溯 |
| 开发 | 设计文档、开发计划 | 任务分解、编码、自测、进度跟踪 | 软件版本、任务完成记录 | 任务关闭、自测齐全 |
| 测试 | 软件版本、需求与设计文档 | 测试计划与用例、执行、缺陷闭环、报告 | 用例、缺陷记录、测试报告 | 报告签署、严重缺陷关闭 |
| 验收交付 | 测试报告、验收标准 | 逐项确认、用户验收、归档 | 验收结论、交付物清单 | 验收签署、归档完成 |
角色怎么分工：谁负责哪个阶段和哪份交付物
瀑布项目的责任空档多发生在阶段交接处：上一阶段的人认为已经交付，下一阶段的人认为材料不完整。解决办法是把角色职责和交付物归属写成矩阵，交接时逐项确认。
瀑布项目中常见的角色包括项目经理、需求负责人、设计负责人、开发负责人、测试负责人和验收方。项目经理对整体计划、里程碑和变更控制负责；需求负责人对需求规格说明书和需求基线负责；设计负责人对设计文档和技术方案负责；开发负责人对开发计划、代码质量和自测记录负责；测试负责人对测试计划、用例、缺陷闭环和测试报告负责；验收方对验收标准和验收结论负责。
分工采用 RACI 方式表达：R 为直接负责执行的人，A 为对结果审批把关的人，C 为需要事前征询意见的人，I 为需要知会结果的人。每份关键交付物只设一个 A，避免审批责任分散。
| 交付物 | R 负责 | A 审批 | C 参与 | I 知会 |
|---|---|---|---|---|
| 阶段计划表与里程碑清单 | 项目经理 | 项目经理上级或项目发起人 | 各阶段负责人 | 验收方 |
| 需求规格说明书 | 需求负责人 | 项目经理 | 开发负责人、测试负责人 | 验收方 |
| 设计文档 | 设计负责人 | 技术负责人 | 开发负责人、测试负责人 | 项目经理 |
| 开发计划与自测记录 | 开发负责人 | 项目经理 | 设计负责人 | 测试负责人 |
| 测试计划、用例与测试报告 | 测试负责人 | 项目经理 | 开发负责人 | 验收方 |
| 验收结论与交付物清单 | 项目经理 | 验收方 | 各阶段负责人 | 项目发起人 |
阶段交接采用书面确认方式：上一阶段负责人提交交付物清单和完成说明，下一阶段负责人核对后确认接收，评审记录或签字作为交接凭证。交接确认记录与交付物一起归档，出现争议时以记录为准。
顺序推进怎么守住：变更控制与阶段评审机制
瀑布项目的顺序性靠两道机制维持：变更控制处理“要不要改”，阶段评审处理“能不能过”。两者都需要固定流程和记录，否则顺序会在口头协调中被逐步打破。
变更控制流程
变更流程分四步：变更申请、影响评估、审批、回写计划。申请人提交变更申请，说明变更内容、原因和期望时间；影响评估由项目经理组织，评估对需求基线、设计、开发任务、测试范围、里程碑和验收标准的影响，给出工作量与进度影响结论；审批按变更影响范围确定审批层级，影响里程碑或验收标准的变更由项目发起人或验收方参与审批；审批通过后回写阶段计划、任务清单和里程碑，并通知相关角色。
变更影响判断要落到后续阶段：需求变更通常影响设计和开发任务，范围扩大还可能影响测试用例和验收标准；设计变更影响开发任务和接口约定；开发阶段的重大变更需要评估是否回退到设计阶段。评估结论应写明受影响的阶段、交付物和里程碑，而不是只写“有影响”。
阶段评审机制
阶段评审在关口处进行，参与人包括本阶段负责人、下一阶段负责人、项目经理，涉及验收的评审邀请验收方参加。评审要点包括：交付物是否齐全并符合约定格式、完成标志是否达成、遗留问题是否有处理计划、下一阶段输入是否具备。评审结论分为通过、有条件通过和不通过三种，有条件通过需列明待办事项和完成期限，不通过则明确返工范围。
返工与阶段回退的触发条件应事先约定：评审不通过、关键交付物缺失、严重缺陷未关闭、变更导致上游交付物失效，都属于触发条件。回退时更新阶段计划，重新设定受影响里程碑的日期，并在变更记录中说明原因。
这些管理动作需要可追溯的记录载体。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节；需求、研发、测试流程可以在同一项目内衔接，阶段交付物和评审结论有对应的记录位置。评审记录模板可采用固定结构：评审阶段、参与人、交付物清单、评审要点逐项结论、遗留事项与责任人、评审结论与日期。
一个完整示例：中型系统交付项目的瀑布推进过程
以下为演示情景，用于说明方法如何串联，不代表真实客户案例。
某企业委托开发一套内部业务系统，合同约定四个月完成交付并验收。项目组按需求、设计、开发、测试、验收交付五个阶段划分，每个阶段设一个关口评审，里程碑分别为需求基线确认、设计基线确认、开发完成、测试通过和验收通过。
需求阶段由需求负责人组织业务部门访谈，两周内完成需求规格说明书初稿，评审会上开发负责人提出两处接口预留问题，测试负责人提出验收标准的可测性意见，修改后评审通过，需求基线确认。设计阶段由设计负责人完成概要设计和详细设计，技术负责人审批通过，设计文档与需求条目建立对应关系。
开发阶段进行到第三周时，业务方提出增加一类报表导出功能。项目经理组织影响评估，结论是该变更影响两个开发任务、三个测试用例和验收标准中的一项，预计增加八个工作日，影响“开发完成”里程碑。变更提交审批，项目发起人与验收方确认后通过，阶段计划和里程碑日期同步更新，测试负责人据此补充用例。
测试阶段执行两轮测试，严重缺陷在第一轮全部关闭，一般缺陷遗留三项，经审批延期至验收后处理并在测试报告中注明。测试报告签署后进入验收交付，验收方对照验收标准逐项确认，其中报表导出功能按变更后的标准验收，验收结论签署，交付物按清单归档，遗留缺陷处理计划作为附件一并移交。
完成检查：判断瀑布项目是否按计划推进的清单
阶段放行和项目自查使用同一套检查项，区别在于检查范围：阶段放行只查本阶段，项目自查覆盖全部已完成阶段。以下清单可逐项核对，任一项不满足时应记录原因和处理计划，再决定是否放行。
- 阶段交付物是否齐全，格式是否符合约定，是否通过评审并有评审结论记录。
- 阶段完成标志是否逐项达成，未达成项是否有书面处理计划。
- 里程碑是否按计划达成，偏差是否有原因说明、影响评估和处理记录。
- 变更是否走完申请、影响评估、审批流程，是否已回写阶段计划和里程碑。
- 阶段交接是否有下一阶段负责人的确认记录，交付物清单是否与责任矩阵一致。
- 缺陷与遗留问题是否登记完整，严重级别问题是否关闭或有审批后的处理意见。
- 验收标准是否逐项确认，验收结论是否签署，交付物是否归档。
- 下一阶段输入是否具备，负责人和资源是否已到位。
清单的执行频率建议与关口一致：每个阶段结束时执行一次阶段放行检查，项目中期和验收前各执行一次全面自查。检查结果与阶段计划、变更记录一并留存，作为项目复盘和后续项目阶段划分的参考。
常见问题
瀑布项目一定要严格按五个阶段推进吗？阶段可以合并或拆分吗？
五个阶段是常见骨架，实际划分可以按项目情况调整。规模较小、周期较短的项目可以把设计与开发合并为一个阶段，或把验收交付并入测试阶段末尾；涉及外部合同验收的项目，通常需要把验收交付单列为独立阶段，以便与合同节点对齐。判断粒度主要看三条：项目周期长短、交付物是否需要外部确认、合同或验收节点是否要求单独汇报。合并或拆分后，阶段计划表和里程碑清单要同步更新，并在项目启动会上确认。
项目进行到开发阶段，业务方提出新需求，应该直接改还是走变更流程？
建议走变更流程，即使变更看起来很小。流程分四步：提交变更申请说明内容和原因，由项目经理组织影响评估，按影响范围确定审批层级，审批通过后回写阶段计划、任务清单和里程碑。影响评估要落到具体受影响的阶段、交付物和里程碑，例如影响几个开发任务、几个测试用例、是否影响验收标准，而不是只写“有影响”。影响里程碑或验收标准的变更，需要项目发起人或验收方参与审批。
阶段评审结论为“有条件通过”时，项目还能进入下一阶段吗？
可以进入，但条件要写清楚。有条件通过需列明待办事项、责任人和完成期限，待办事项在下一阶段内跟踪闭环。如果待办事项涉及下一阶段的输入，例如设计文档缺少关键接口说明，应先补齐再启动下一阶段的核心工作。评审结论为不通过时，明确返工范围，返工完成后重新评审，受影响里程碑的日期同步更新并记录原因。
阶段交接时上一阶段负责人认为已交付，下一阶段负责人认为材料不全，怎么处理？
这类争议靠事先约定的交付物清单和交接确认记录解决。项目启动时就把每份关键交付物的责任人和验收标准写进角色责任矩阵；阶段交接时，上一阶段负责人提交交付物清单和完成说明，下一阶段负责人逐项核对后确认接收，评审记录或签字作为交接凭证。出现争议时以记录为准。如果清单本身有遗漏，应在复盘中补充，而不是在交接现场临时口头约定。
瀑布项目推进中，怎么判断某个阶段可以放行？
按检查清单逐项核对：阶段交付物是否齐全并通过评审，完成标志是否逐项达成，里程碑偏差是否有原因说明和处理记录，变更是否走完审批并回写计划，阶段交接是否有确认记录，严重级别缺陷是否关闭或有审批后的处理意见，下一阶段输入是否具备。任一项不满足时，记录原因和处理计划，再决定是否放行。阶段放行只查本阶段，项目中期和验收前的全面自查覆盖全部已完成阶段。
