瀑布项目管理落地时，先要把阶段主线、角色交付和评审变更三件事固定下来：按需求、设计、开发、测试、上线划分阶段，为每个阶段写明输入、动作、输出和完成标志；用角色职责表把交付物落到人；用阶段评审和变更申请守住阶段边界。本文给出可直接套用的阶段计划表、职责表、评审清单和变更模板，并说明这些记录如何在ONES中承载。
要点总览（TL;DR）
- 瀑布项目管理以阶段串行为主线：按需求、设计、开发、测试、上线划分阶段，为每个阶段写明输入、关键动作、输出物和可核验的完成标志。
- 角色分工要落到交付物：项目经理、需求负责人、技术负责人、测试负责人和业务方各自对应明确的输出物与评审签署责任。
- 阶段评审是进入下一阶段的门槛，评审不通过就留在当前阶段返工；变更统一走申请单，完成范围、进度、质量、成本四维影响评估后再更新基线。
- 上线前用交付物齐备性、评审记录、基线确认和变更关闭情况逐项核对，重点纠正阶段边界模糊、评审流于形式和变更未评估三类偏差。
- 阶段计划、评审记录和变更申请需要集中留痕，ONES 可按阶段组织工作分解、设置依赖与里程碑，并通过基线和版本对比跟踪偏差与变更。
瀑布项目管理的基本流程与阶段划分
瀑布项目以阶段串行推进为主线，前一阶段通过评审后才进入下一阶段。阶段划分的依据是交付物的形态变化：需求阶段把业务诉求转成可验收的需求说明，设计阶段把需求转成可开发的技术方案，开发阶段产出可测试的版本，测试阶段产出质量结论，上线阶段完成交付与移交。需求相对明确、计划性较强的项目适合这种划分方式；需求频繁变化时，需要在变更控制上投入更多精力。
每个阶段都要定义四件事：输入是什么、主要动作做什么、输出物是什么、完成标志是什么。完成标志应当可核验，例如“需求说明书经业务方签字确认”比“需求基本明确”更便于判断阶段是否结束。
| 阶段 | 输入 | 关键动作 | 输出物 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 需求 | 项目立项说明、业务目标 | 需求调研、范围确认、验收标准定义 | 需求说明书、范围清单、验收标准 | 业务方与项目经理签字确认需求基线 | 需求负责人 |
| 设计 | 已确认的需求说明书 | 架构设计、接口设计、数据库设计、设计评审 | 概要设计、详细设计、评审记录 | 技术负责人签署设计评审通过结论 | 技术负责人 |
| 开发 | 设计文档、开发计划 | 编码、单元测试、代码评审、版本构建 | 可运行版本、单元测试报告、构建记录 | 版本通过冒烟测试并移交测试 | 技术负责人 |
| 测试 | 可运行版本、测试方案 | 用例执行、缺陷跟踪、回归测试 | 测试报告、缺陷清单、质量结论 | 遗留缺陷达到约定标准，测试负责人签署报告 | 测试负责人 |
| 上线 | 测试报告、上线方案 | 上线部署、数据迁移、验收、移交 | 上线记录、验收单、运维移交文档 | 业务方验收通过，运维接收 | 项目经理 |
范围、进度、质量三条基线在阶段中各有位置：范围基线在需求阶段结束时确定，进度基线在设计阶段结束时随详细计划确定，质量基线在测试方案中明确验收标准与缺陷门槛。三条基线一经确认，后续调整都要走变更流程。阶段评审是进入下一阶段的门槛，评审不通过则停留在当前阶段返工，这是串行流程不被随意打断的关键。
角色分工与各阶段交付物清单
瀑布项目的职责悬空，通常源于交付物没有明确责任人。做法是把每个阶段的输出物逐一对应到角色，并在评审时由对应角色签署结论。
| 角色 | 主要职责 | 负责的交付物 | 参与的评审 |
|---|---|---|---|
| 项目经理 | 编制阶段计划、协调资源、跟踪进度、组织评审、管理变更 | 项目计划、阶段计划表、评审记录、变更记录、上线验收单 | 全部阶段评审，主持评审 |
| 需求负责人 | 需求调研、范围界定、验收标准编写、需求变更影响说明 | 需求说明书、范围清单、验收标准 | 需求评审、设计评审、验收评审 |
| 技术负责人 | 技术方案设计、开发任务分解、代码质量把关 | 概要设计、详细设计、可运行版本、单元测试报告 | 设计评审、开发转测试评审 |
| 测试负责人 | 测试方案与用例编写、缺陷管理、质量结论输出 | 测试方案、测试用例、测试报告、缺陷清单 | 需求评审、测试评审、上线评审 |
| 业务方 | 确认需求与验收标准、参与验收、提出变更申请 | 需求确认签字、验收结论、变更申请单 | 需求评审、上线验收 |
评审结论的签署方式建议统一：每份评审记录写明评审时间、参与人、评审对象版本号、结论（通过、有条件通过、不通过）以及遗留问题清单。有条件通过时，遗留问题要指定责任人和关闭时间，并在进入下一阶段前确认关闭。交付物需要版本管理，文件名或文档属性中标注版本号与状态（草稿、评审中、已确认），已确认版本归档保存，后续修改生成新版本，旧版本保留以便追溯。
阶段评审与变更控制怎么落地
阶段评审的触发时点是当前阶段输出物完成、准备进入下一阶段之前。参与人至少包括项目经理、该阶段交付物负责人、下游阶段负责人和业务方代表。通过标准可以归纳为三条：输出物齐备且版本已确认；输出物内容满足下一阶段的输入要求；遗留问题已记录并明确处理计划。
评审不通过时，由交付物负责人组织返工，项目经理更新阶段计划中的返工任务与时间，返工完成后重新发起评审。再评审仍使用同一份评审记录模板，注明是第几次评审，避免评审历史断档。
变更申请单建议包含以下字段：
- 变更编号、提出人、提出日期
- 变更内容描述与变更原因
- 影响的阶段与交付物
- 影响评估：范围、进度、质量、成本四个维度分别说明
- 评估结论与审批人意见
- 执行计划：责任人、完成时间、需要更新的基线
影响评估是变更控制的核心动作。范围变化要判断是否触及已确认的需求基线；进度变化要重算关键路径上的里程碑；质量变化要确认验收标准是否调整。审批通过后，项目经理同步更新基线、阶段计划和相关交付物版本，并在变更记录中登记关闭状态。未经评估的变更不应直接进入开发。
一个瀑布项目的执行示例
以下为演示情景，用于说明方法如何串联，不代表真实客户案例。某企业内部系统升级项目，范围是替换旧版审批模块并迁移历史数据，计划周期四个月，分为需求、设计、开发、测试、上线五个阶段。
需求阶段输入为立项说明和业务部门提出的流程优化诉求，需求负责人完成调研后输出需求说明书与验收标准，业务方签字确认，范围基线确定。设计阶段技术负责人输出概要设计与详细设计，设计评审中发现接口方案与现有系统不兼容，评审结论为有条件通过，遗留问题指定技术负责人在一周内关闭后进入开发。
开发阶段进行到第三周，业务方提出增加移动端审批入口。项目经理要求提交变更申请单，影响评估结论为：范围增加一个端，开发工作量增加约两周，测试用例需补充，上线里程碑顺延。审批通过后，项目经理更新进度基线与阶段计划，测试负责人同步补充测试方案。这次变更的处理过程完整记录在变更记录中，包括评估结论和基线更新说明。
测试阶段结束时，测试报告显示遗留缺陷均为低优先级且已约定上线后修复，测试负责人签署质量结论。上线评审由项目经理主持，业务方、技术负责人、测试负责人参加，确认上线方案、回滚方案和运维移交文档齐备后通过，随后完成部署与验收。整个过程中，每个阶段的交付物都能对应到具体责任人，评审记录和变更记录构成完整的执行轨迹。
上线前的完成检查与常见偏差
判断一个阶段或项目是否完成，依据是交付物齐备性和评审记录，而非主观感觉。上线前可按以下清单逐项核对：
- 各阶段输出物是否齐备，版本是否为已确认状态
- 每份阶段评审记录是否包含参与人、结论和遗留问题关闭情况
- 范围基线、进度基线、质量基线是否有对应的确认记录
- 所有变更申请是否完成影响评估、审批和基线更新
- 测试报告中的遗留缺陷是否有明确处理计划
- 上线方案、回滚方案、运维移交文档是否完成评审
- 业务方验收结论是否已签署
瀑布执行中的典型偏差有三类。阶段边界模糊表现为上一阶段未评审就启动下一阶段工作，纠正动作是项目经理在阶段计划中把评审设为下一阶段任务的开始条件，责任归属项目经理。评审流于形式表现为评审记录只有结论没有遗留问题，纠正动作是统一评审模板并要求逐项填写，责任归属各阶段交付物负责人。变更未评估表现为需求口头调整后直接开发，纠正动作是明确变更入口，未提交申请单的调整不进入开发排期，责任归属项目经理与需求负责人共同把关。
用工具承载阶段、评审与变更记录
上述方法落到执行层面，需要阶段计划、评审记录和变更申请有统一的存放位置，否则版本和结论容易散落在个人文档中。ONES可帮助团队规划项目工作、安排任务、跟踪进度，并围绕关键阶段和交付目标开展协同管理，适合承载这类串行项目的计划与记录。
阶段计划可以在项目中按阶段维度组织工作分解结构，为任务设置前后置依赖，用里程碑标记评审和上线等关键决策点，使阶段串行关系在计划中直接可见。阶段交付物作为任务产出挂接到对应阶段，责任人通过任务分配明确。评审记录和变更申请以项目内文档或工作项形式留痕，评审结论、参与人和遗留问题随阶段归档。项目经理通过设置计划和里程碑基线，对比计划与执行的偏差，识别进度风险；变更执行后通过版本对比追溯变更细节。ONES Project提供敏捷、瀑布、通用任务协同等多种项目模板，瀑布模板可作为阶段计划的起点。
这套承载方式适用于希望把阶段评审和变更记录集中管理、减少线下文档分散的团队。团队规模较小、阶段较少的项目，也可以先用表格和共享文档执行本文的模板，待阶段数量和参与角色增多后再迁移到工具中统一管理。
常见问题
需求在项目中途频繁变化，瀑布项目管理还能用吗？
可以用，但要把变更控制做扎实。瀑布方法适合需求相对明确、计划性较强的项目；需求变化频繁时，阶段串行本身不需要推翻，需要加强的是变更入口和影响评估。具体做法是：所有调整统一提交变更申请单，评估对范围、进度、质量和成本的影响，审批通过后同步更新基线和阶段计划。如果变化量大到每个阶段都难以稳定收口，可以评估是否改用迭代方式推进，这属于方法选择问题，与瀑布流程本身不冲突。
阶段评审不通过，项目进度怎么处理？
评审不通过时，项目停留在当前阶段返工，不进入下一阶段。项目经理需要在阶段计划中登记返工任务、责任人和预计完成时间，返工完成后重新发起评审，并在评审记录中注明是第几次评审，保持评审历史连续。进度影响要如实反映到里程碑上，必要时走变更流程调整进度基线，避免用压缩下游阶段时间的方式掩盖返工。
小团队阶段少、角色兼职，还需要完整的评审和变更记录吗？
记录可以简化，关键动作不能省。小团队里一人兼多个角色是常见情况，评审参与人可以合并，但评审结论、遗留问题和变更影响评估仍要留下书面记录，否则阶段边界和基线状态无法追溯。执行上可以先用表格和共享文档套用本文的模板，等阶段数量、参与角色和变更频次增加后，再迁移到项目管理工具中统一管理。
阶段计划、评审记录和变更申请放在工具里，具体怎么组织？
常见做法是按阶段维度组织工作分解结构，为任务设置前后置依赖，用里程碑标记评审和上线等决策点，让串行关系在计划中直接可见。阶段交付物挂接到对应阶段的任务产出上，责任人通过任务分配明确。评审记录和变更申请以项目内文档或工作项形式留痕，随阶段归档。ONES 支持项目计划的工作分解、依赖与里程碑设置，并提供基线和版本对比用于跟踪偏差与变更追溯，ONES Project 也提供瀑布项目模板作为起点。
上线前发现部分阶段评审记录缺失，还能继续上线吗？
建议先补齐再上线。评审记录缺失意味着该阶段的输出物是否满足下一阶段输入要求没有可核验的依据，直接上线会把风险带到交付环节。处理方式是：由该阶段交付物负责人补充评审，确认输出物版本和遗留问题状态；如果发现遗留问题未关闭，先评估其对上线的影响再决定是否放行。补齐后的记录与上线验收单一起归档，形成完整的执行轨迹。
