瀑布项目管理以阶段顺序推进为主线，每个阶段有明确的输入、活动、输出和完成标志，阶段之间通过评审关口衔接。本文面向需要建立或规范单项目瀑布流程的读者，给出阶段划分、评审设置、角色分工、变更控制和进度跟踪的具体做法，并在交付物与评审记录环节说明ONES可承载的管理动作。
要点总览（TL;DR）
- 瀑布项目管理以顺序推进的阶段为主线：先明确范围与交付物，再划分需求、设计、开发、测试、上线阶段，为每个阶段定义输入、活动、输出和可核验的完成标志。
- 阶段之间用评审关口衔接，评审结论分为通过、有条件通过和退回三种，评审中提出的范围调整转入变更控制流程处理。
- 角色分工围绕交付物划分编写、审核、咨询和知会责任，编写与审核保持分离，角色缺位时提前在项目启动文档中写明替代安排。
- 变更控制要求每次范围调整都有申请、影响评估、按层级审批和基线更新通知，未批准的变更同样留档。
- 进度跟踪以里程碑和交付物完成度为主，按周检查偏差并指定纠偏责任人，落地效果用检查清单逐项核对。
瀑布项目管理的基本流程与阶段划分
瀑布项目管理的顺序推进逻辑是：上一阶段的输出构成下一阶段的输入，阶段成果经过确认后才进入下一阶段。项目启动时先明确范围与交付物，再依次经过需求、设计、开发、测试、上线五个典型阶段。每个阶段都要回答四个问题：拿什么做输入、做哪些活动、产出什么、达到什么条件算完成。
阶段划分的粒度取决于项目规模和交付物复杂度。周期在三个月以内、交付物单一的项目，可以把需求与设计合并为一个阶段；涉及多系统集成、外部验收或合规审查的项目，应把需求拆为需求调研与需求确认，把测试拆为系统测试与验收测试。判断粒度是否合适，可以看两条标准：每个阶段的输出能否被独立评审，阶段负责人能否对完成标志负责。阶段过多会增加评审成本，阶段过少会让风险集中在后期暴露。
| 阶段名称 | 输入 | 主要活动 | 输出交付物 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 需求 | 项目立项书、业务目标、干系人清单 | 需求调研、需求分析、范围确认 | 需求规格说明书、范围说明书 | 需求评审通过，干系人签字确认范围 | 需求负责人 |
| 设计 | 已确认的需求规格说明书 | 概要设计、详细设计、技术方案评审 | 设计说明书、接口文档、技术方案 | 设计评审通过，开发与测试确认可实施 | 设计负责人 |
| 开发 | 设计说明书、开发计划 | 编码、单元测试、代码评审、集成 | 可运行版本、单元测试报告、代码评审记录 | 开发完成，单元测试通过，版本提交测试 | 开发负责人 |
| 测试 | 可运行版本、测试计划与用例 | 系统测试、缺陷修复与回归、验收测试 | 测试报告、缺陷清单、验收记录 | 测试通过率达标，遗留缺陷已评估并处置 | 测试负责人 |
| 上线 | 测试报告、上线方案、回滚预案 | 部署、数据迁移、上线验证、移交 | 上线记录、运维手册、项目总结 | 上线验证通过，运维接收，项目收尾确认 | 项目经理 |
这张表可以直接作为项目启动会的讨论底稿。实际使用时，把每行的输出交付物替换为项目真实文档名称，把完成标志写成可核验的条件，例如“需求评审记录已归档且无未关闭的高优先级意见”，避免使用“基本完成”这类无法判断的表述。
阶段衔接与评审关口怎么设置
阶段评审是瀑布项目最关键的衔接机制。评审关口设在每个阶段结束时，与里程碑对应：里程碑标记时间点，评审回答“这个时间点上的成果是否达到进入下一阶段的条件”。里程碑日期可以调整，评审结论必须明确，二者结合才能既管节奏又管质量。
评审参与角色按阶段确定。需求评审由业务方、需求负责人、设计与测试代表参加；设计评审由设计负责人、开发负责人、测试负责人参加；测试评审由测试负责人、开发负责人、项目经理参加；上线评审由项目经理、运维负责人、业务方参加。评审材料至少包括本阶段交付物、完成标志自检表、遗留问题清单和下一阶段启动条件说明。
评审结论分三种处理方式：
- 通过：交付物满足完成标志，遗留问题已登记责任人和期限，阶段正式关闭，下一阶段启动。
- 有条件通过：主体成果达标，但存在不影响下一阶段启动的遗留项。明确遗留项内容、责任人和关闭期限，下一阶段可启动，遗留项纳入跟踪表按周检查。
- 退回：交付物未达到完成标志，或存在影响后续阶段的关键缺陷。列出整改项和重新评审时间，本阶段不关闭。
评审中提出的范围调整不直接修改交付物，而是转入变更控制流程：记录变更内容，评估对进度、成本和后续阶段的影响，按审批权限决策后再更新交付物和基线。这样评审结论保持清晰，变更也有独立记录可追溯。
评审检查表可按以下条目核对：交付物是否齐全并按模板编写；完成标志是否逐条自检；遗留问题是否登记责任人与期限；下一阶段输入是否已准备；评审结论与签字是否归档。评审记录和阶段交付物需要长期留存，ONES Wiki 支持文档关联任务，并可在文档中插入 ONES Project 的工作项列表，便于把评审材料与对应任务放在同一处查阅。
角色分工与各阶段交付物清单
瀑布项目的角色边界围绕交付物划分：谁编写、谁审核、谁批准、谁需要知会。项目经理对整体计划、里程碑和变更流程负责，不替代职能角色做技术判断；需求、设计、开发、测试负责人对本阶段交付物的内容和质量负责；业务方作为需求提出者和验收方参与评审。
| 交付物 | 编写（R） | 审核（A） | 咨询（C） | 知会（I） |
|---|---|---|---|---|
| 项目立项书与范围说明书 | 项目经理 | 业务方 | 需求、设计负责人 | 项目团队 |
| 需求规格说明书 | 需求负责人 | 业务方、项目经理 | 设计、测试负责人 | 开发负责人 |
| 设计说明书与接口文档 | 设计负责人 | 技术负责人 | 开发、测试负责人 | 项目经理 |
| 可运行版本与单元测试报告 | 开发负责人 | 技术负责人 | 测试负责人 | 项目经理 |
| 测试报告与缺陷清单 | 测试负责人 | 项目经理 | 开发负责人 | 业务方 |
| 上线方案与回滚预案 | 开发负责人 | 运维负责人、项目经理 | 测试负责人 | 业务方 |
| 阶段评审记录 | 项目经理 | 评审主持人 | 各阶段负责人 | 项目团队 |
交付物需要版本与基线管理。每个阶段评审通过时，将该阶段交付物定为一个基线版本，后续修改以新版本记录并注明变更原因。基线的作用是让后续阶段有稳定的参照，也让变更影响可以对比。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本细节追溯变更。
角色缺位时需要提前安排替代。常见情况包括：项目规模小、需求与设计由同一人承担时，审核人应由技术负责人或项目经理担任，保持编写与审核分离；测试人员不足时，可由开发交叉测试并保留测试记录，验收测试仍由业务方或独立测试角色执行；业务方无法及时参加评审时，应书面授权代理人并明确授权范围。替代安排写入项目启动文档，避免评审时临时决定。
范围与变更控制的操作方法
瀑布项目的变更控制目标是让每一次范围调整都有申请、有评估、有决策、有记录。变更申请单至少包含以下字段：变更编号、提出人与提出日期、变更描述、变更原因、涉及的需求或交付物编号、期望完成时间、紧急程度。描述要具体到可判断的范围，例如“新增报表导出功能，支持按部门筛选”，避免“优化报表体验”这类无法评估的表述。
影响评估由项目经理组织，需求、设计、开发、测试负责人分别给出意见，形成一份评估结论：对当前阶段交付物的影响、对后续阶段排期的影响、对成本和资源的影响、对已定基线的影响、技术风险。评估结论附在变更申请单后，作为审批依据。
审批层级按影响程度划分：不影响里程碑和已确认范围的变更，由项目经理审批；影响阶段排期但不影响整体里程碑的，由项目经理与相关阶段负责人共同审批；影响整体里程碑、成本或验收范围的，提交项目决策人或业务方审批。每次审批记录结论、审批人、审批日期和附加条件。
变更批准后，更新受影响的交付物和计划，重新设定基线版本，并向项目团队和相关干系人发出变更通知，说明变更内容、生效时间和需要配合的动作。未批准的变更同样记录结论和原因，避免后续重复提出。变更记录按编号归档，与阶段评审记录分开保存，便于统计变更频次和来源。
进度跟踪与里程碑管理
里程碑设置遵循少而关键的原则。一个典型瀑布项目设五到八个里程碑，覆盖阶段完成、关键评审、外部依赖交付和上线。每个里程碑写明日期、对应交付物、完成判据和责任人。里程碑日期来自阶段计划的汇总，不单独拍定，避免计划与里程碑两张皮。
阶段进度跟踪以交付物完成度为主、任务完成率为辅。每周检查三项内容：本阶段交付物清单中已完成和未完成的数量；关键任务的计划完成时间与实际完成时间；已识别风险的状态变化。交付物完成度用“已评审通过”“已提交待评审”“编写中”“未开始”四档记录，比百分比更便于判断真实进展。
偏差识别看两类信号：里程碑临近但完成标志未达成，或关键路径任务出现延期。发现偏差后先判断原因属于资源不足、需求不清还是技术障碍，再选择纠偏动作：调整资源投入、拆分剩余工作、调整后续阶段排期，或在必要时启动变更流程调整范围。纠偏动作要指定责任人和完成时间，并在下一次跟踪中复核效果。
状态汇报按对象区分频率：项目团队每周一次进度同步，聚焦任务和风险；项目经理向项目决策人每两周或每个里程碑汇报一次，内容包括里程碑状态、偏差、变更和需要决策的事项；向业务方在阶段评审时汇报阶段成果和下一阶段计划。汇报材料以里程碑清单和跟踪表为基础，保持数据口径一致。ONES 支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解计划，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点，适合承载上述跟踪动作。
示例：一个瀑布项目的阶段推进过程
以下为演示情景，用于说明方法如何串联，不代表真实客户项目。某企业需要建设一套内部合同管理系统，周期四个月，涉及法务、财务和信息技术三个部门，采用瀑布方式推进。
项目启动后确定范围：合同起草、审批流转、归档查询三个模块，不含电子签章。需求阶段输出需求规格说明书和范围说明书，需求评审由法务和财务确认流程节点，评审通过后范围基线确定。设计阶段完成概要设计和接口文档，设计评审中测试负责人提出审批流转缺少异常退回场景，作为遗留项登记，限期在设计阶段关闭前补充。开发阶段按模块拆分任务并设置依赖，单元测试通过后提交测试。测试阶段发现归档查询性能不达标，测试报告记录缺陷并评估影响，开发修复后回归通过。上线阶段按上线方案部署，业务方完成验收，运维接收并归档项目总结。
项目进行到开发阶段中期，法务提出新增合同模板管理功能。项目经理受理变更申请，评估结论为：新增功能影响开发排期约两周，不影响整体上线里程碑的前提是测试阶段压缩一周。变更提交项目决策人审批，批准后更新开发计划和需求文档，重设基线，向三个部门发出变更通知。测试阶段按调整后的计划执行，压缩部分通过增加测试人员投入弥补。
测试阶段第二周，跟踪表显示归档查询缺陷修复比计划晚三天，里程碑存在延期风险。项目经理判断原因是开发人员同时处理变更功能和缺陷修复，随即调整任务优先级，将变更功能的部分工作后移，保证缺陷修复优先，并在下一次周报中向决策人说明调整情况和里程碑状态。最终上线里程碑按原日期达成。
落地完成检查清单
以下清单用于判断瀑布管理机制是否建立并可运行，建议在项目启动后两周内完成首次核对，此后每个阶段评审时复核。
- 阶段模型已确定，每个阶段有书面定义的输入、活动、输出和完成标志。
- 阶段定义表中的完成标志可核验，未使用模糊表述。
- 每个阶段设置了评审关口，评审参与角色、评审材料和结论处理规则已明确。
- 评审记录有统一模板，通过、有条件通过、退回三种结论均有处理记录。
- 角色—阶段—交付物责任矩阵已发布，编写人与审核人分离。
- 交付物有版本和基线规则，阶段评审通过后形成基线版本。
- 角色缺位的替代安排已写入项目启动文档。
- 变更申请单字段完整，影响评估和审批层级已定义。
- 变更批准后有基线更新和通知动作，未批准变更也有记录。
- 里程碑清单包含日期、交付物、完成判据和责任人。
- 进度跟踪表按周更新，偏差有原因分析和纠偏责任人。
- 状态汇报的对象、频率和内容口径已约定，并实际执行。
清单中任何一项无法回答“谁来做、做什么、产出什么、何时检查”，说明该环节还停留在原则层面，需要补充具体规则后再投入运行。ONES 基于 PMI、CMMI 理论覆盖从立项到收尾的瀑布项目管理全过程，可将需求管理、研发管理、测试管理和资源管理流程连接起来，适合作为上述阶段、评审和变更记录的承载工具；具体模板配置和版本差异可在选型时向官方核验。
常见问题
项目周期很短，还需要完整走需求、设计、开发、测试、上线五个阶段吗？
可以合并，但合并的是阶段数量，阶段内部的输入、活动和完成标志仍需保留。周期在三个月以内、交付物单一的项目，通常把需求与设计合并为一个阶段，评审时同时确认范围和技术方案。判断合并是否合适，看合并后的输出能否被独立评审、负责人能否对完成标志负责。合并后仍要保留评审记录，否则后续变更和验收缺少参照。
阶段评审已经通过，之后业务方又提出新需求，应该走评审还是走变更？
走变更控制流程。评审回答的是本阶段成果是否达到进入下一阶段的条件，评审通过意味着阶段关闭；新需求属于对已确认范围的调整，需要单独受理。操作上先记录变更申请，评估对当前交付物、后续排期、成本和基线的影响，再按影响程度提交对应层级审批。批准后更新交付物和计划、重设基线并通知相关方，未批准也要记录结论和原因。
小团队里需求、设计由同一人承担，评审时如何保证把关有效？
关键是保持编写与审核分离，而不是要求每个角色都配专职人员。可以由技术负责人或项目经理担任审核人，重点核对交付物是否满足完成标志、遗留问题是否登记责任人和期限。测试人员不足时，可安排开发交叉测试并保留测试记录，验收测试仍由业务方或独立测试角色执行。这类替代安排应在项目启动文档中写明，避免评审现场临时决定。
里程碑日期和阶段评审时间冲突时，以哪个为准？
里程碑标记时间点，评审回答成果是否达标，两者作用不同。里程碑临近但完成标志未达成时，先判断原因属于资源不足、需求不清还是技术障碍，再选择纠偏动作：调整资源投入、拆分剩余工作、调整后续阶段排期，或在必要时启动变更流程调整范围。不建议为了让里程碑按期达成而放宽评审标准，那会把风险推到后期阶段集中暴露。
用工具承载瀑布项目时，阶段交付物、评审记录和变更记录应该怎么组织？
建议按阶段建立交付物目录，评审记录与对应阶段交付物放在一起，变更记录按编号单独归档，便于统计变更频次和来源。ONES Wiki 支持文档关联任务，并可在文档中插入 ONES Project 的工作项列表，评审材料与对应任务可以在同一处查阅；ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本细节追溯变更。具体模板配置和版本差异建议在选型时向官方核验。
