瀑布项目管理按阶段顺序推进：先明确范围与验收标准，再分解任务与工期、排定里程碑和依赖，随后按阶段执行与评审，用变更控制守住基线，最后以验收证据收尾。本文面向第一次负责瀑布项目的项目经理和阶段负责人，覆盖单项目从启动到收尾的操作步骤、角色分工与检查表；组织级流程制度、敏捷框架实践不在本文展开。
要点总览（TL;DR）
- 启动阶段先把目标、范围边界、成功标准和验收标准写成书面文件，并明确项目经理、阶段负责人、评审人、变更审批人四类角色，后续计划与验收才有统一依据。
- 计划编制按WBS分解到可估算、可交付、可指派的工作包，识别依赖与关键路径，用历史数据、专家判断或三点估算给出工期，标注缓冲后冻结基线。
- 阶段执行以周例会跟踪完成度、偏差和风险，阶段交付物完成时按事先明确的通过标准评审，结论书面记录，不通过则返工再评审。
- 变更控制要求每项变更都有申请单、影响评估和分级审批，获批后同步更新基线并通知相关角色，未审批的变更暂停并补流程或回退。
- 收尾以验收核对表逐项确认，完成移交清单、遗留项登记、复盘记录和文档归档，才算项目真正结束。
瀑布项目启动前要定下哪些东西
启动阶段的任务是把“做什么、做到什么程度算成功、谁负责”写成可引用的文件。这一阶段不追求计划细节，重点是让后续的计划、执行和验收都有统一依据。启动说明或项目章程是这一阶段的核心产出，它至少应包含四类内容：项目目标（要解决什么业务问题、预期结果是什么）、范围边界（包含什么、明确排除什么）、成功标准（用什么指标或事实判断项目成功）、关键约束（预算、工期、合规要求等已知条件）。范围边界写得越具体，执行阶段因理解差异产生的返工越少。
需求与验收标准需要书面化。做法是把每项需求写成可验证的条目，并对应一条验收标准，例如“支持按部门导出月度报表，导出字段与财务口径一致，抽样核对10份无差异”。验收标准由提出方与交付方共同确认，确认后的版本作为后续验收的比对基准。口头确认的需求在评审时容易产生争议，书面化是控制这一风险最直接的手段。
阶段划分按交付物切分，而不是按自然时间切分。每个阶段应有一个可评审的交付物，例如“需求规格说明书通过评审”作为一个阶段的结束标志，比“第一个月结束”更有管理意义。里程碑标记重要时间点、事件或决策点，与阶段交付物对应。角色分工需要明确四类人：项目经理负责整体计划、跟踪与对外沟通；阶段负责人对本阶段交付物和进度负责；评审人负责阶段评审并给出通过或不通过的结论；变更审批人负责变更申请的审批。角色责任表应写清每个人的具体职责和决策权限，避免出现“大家都参与、没人负责”的情况。
启动阶段的完成标志是：项目章程或启动说明经确认、验收标准书面化并双方认可、阶段划分与里程碑表确定、角色责任表落实到人。这四项齐备后，计划编制才有稳定的输入。
如何分解任务、估算工期并排出可执行计划
计划编制的第一步是把范围转成工作分解结构（WBS）。分解的粒度标准是“可估算、可交付、可指派”：每个工作包能估出工期、有明确产出、能落到一个负责人。常见做法是按交付物或项目阶段分解，再向下拆到具体任务。分解过粗会导致估算失真，过细会增加跟踪成本，一般以单个工作包工期在数天到两周之间为宜。
WBS完成后识别任务之间的依赖关系，区分强制依赖（如测试必须在开发完成后）和软依赖（如文档可与开发并行）。把依赖关系串起来后找出关键路径，即决定项目总工期的最长任务链。关键路径上的任务延误直接影响交付日期，计划跟踪时应优先关注。工期估算常用三种依据：历史项目数据（同类任务的實際耗时）、专家判断（由做过类似工作的负责人评估）、三点估算（分别给出乐观、最可能、悲观工期，加权得出期望值）。三种方法可以结合使用，历史数据充分时优先用数据，新类型任务用专家判断加三点估算。
缓冲设置有两种常见方式：在关键路径末端设置项目缓冲，吸收整体不确定性；在非关键路径任务后设置接驳缓冲，防止其延误传导到关键路径。缓冲不是隐藏的余量，应明确标注并纳入基线，否则跟踪时无法区分“计划内缓冲消耗”和“真实偏差”。资源分配要检查同一负责人在同一时段是否被安排了超出可用工时的任务，冲突在计划阶段解决比在执行阶段解决成本低。
计划基线经项目经理与阶段负责人确认后冻结，作为后续进度对比的基准。基线冻结不意味着计划不能改，而是改动必须走变更流程。在工具层面，ONES 的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；设置计划与里程碑基线后，可对比计划与执行的偏差。计划编制的完成标志是：WBS覆盖全部范围、依赖关系与关键路径明确、工期估算有依据、缓冲已标注、基线已确认冻结。
阶段执行与评审怎么组织
每个阶段开始时召开阶段启动会，明确本阶段的目标、交付物、任务分派和时间安排。任务分派要落到具体负责人和完成时间，阶段负责人确认本阶段输入已齐备（如上一阶段的评审结论、必要的资料和资源）。阶段启动会的输出是任务分派记录和本阶段的风险预判。
执行期间的进度跟踪以周例会为主要节奏，跟踪对象包括三类：完成度（已完成任务与计划对比）、偏差（进度、工时、质量的偏离程度及原因）、风险与问题（新出现的风险、已发生的问题及处理状态）。跟踪时对照基线看偏差，而不是只看“任务是否在推进”。偏差超过预设阈值时，判断是正常波动还是需要采取纠正措施；需要调整计划时，区分日常调整与正式变更，后者走变更控制流程。
阶段评审在阶段交付物完成时进行，参与角色包括阶段负责人（汇报交付物与完成情况）、评审人（按验收标准逐项检查）、项目经理（确认评审结论并决定是否进入下一阶段），必要时邀请提出方参加。通过标准应在评审前明确，例如“交付物覆盖本阶段全部需求条目、遗留问题已登记且有责任人和处理计划”。评审结论写成书面记录，明确“通过”“有条件通过”或“不通过”。有条件通过需列出待办项和完成时限；不通过时，阶段负责人组织返工，返工完成后提交再评审，再评审的范围可以聚焦未通过项，但结论同样书面记录。
风险与问题在发现时登记，记录内容包括描述、影响、责任人、处理措施和状态。升级路径按影响程度设定：影响本阶段交付物或里程碑的问题由项目经理协调，影响项目整体目标或需要跨部门资源的问题升级到项目发起人或管理层。阶段执行的完成标志是：本阶段交付物完成并通过评审、执行记录与问题清单更新完毕、评审结论已归档。
变更控制与基线维护怎么做
变更控制的目的是让范围、进度、质量的调整有记录、有评估、有审批，避免基线被悄悄改动。变更申请单需要写清三项内容：变更内容（具体改什么，改前改后对比）、影响范围（涉及哪些需求、交付物、任务）、对工期和成本的影响（预计增加或减少多少工作量、是否影响里程碑）。影响描述越具体，审批判断越有依据。
变更评估由项目经理组织，评估维度包括：对范围的影响（是否引入新需求或删减已确认需求）、对进度的影响（是否影响关键路径和里程碑）、对成本与资源的影响（是否需要额外人力或预算）、对质量与验收标准的影响（验收标准是否需要同步调整）。涉及技术方案的变更应请阶段负责人或技术负责人参与评估。评估结论写成影响评估记录，附在变更申请单后。
审批权限按变更影响程度分级。影响限于单个阶段内部、不触及里程碑和验收标准的变更，可由项目经理审批；影响里程碑、项目总工期或验收标准的变更，由项目发起人或变更审批人审批；涉及合同范围或预算的变更，按组织规定的权限上报。分级规则应在启动阶段就确定，避免每次变更临时找人拍板。
变更获批后，更新对应的基线（范围基线、进度基线或验收标准），记录新版本号并通知所有受影响的角色，包括阶段负责人、评审人和提出方。基线更新后，后续的进度对比以新版本为准。未经审批就执行的变更，一经发现应暂停相关工作，补走变更流程或回退到基线状态；已经产生的工作量在变更记录中如实登记，作为复盘时的输入。ONES 支持设置项目计划和里程碑基线并对比版本细节，用于追溯变更前后的差异。变更控制的完成标志是：每项变更都有申请单、影响评估和审批记录，基线版本与最新批准状态一致。
收尾与验收需要哪些证据
验收以启动阶段确认的验收标准为比对基准，逐项确认。做法是制作验收核对表，每项标准对应一条确认记录，写明验证方式（如抽样检查、演示、文档审查）和结论。提出方与交付方共同确认，确认结果写入验收确认单。验收标准在执行中经过批准变更的，以变更后的版本为准。
交付物移交需要清单和接收确认。移交清单列出全部交付物（文档、系统、数据、账号权限等）、移交方式和接收人，接收人逐项确认后签字或书面回复。移交不等于验收，验收确认的是“符合标准”，移交确认的是“已交付到接收方手中”，两者都应留痕。
遗留问题和未完成项单独登记，写明描述、影响、责任人和计划处理时间。遗留项不因项目收尾而消失，应明确由谁在什么时间跟进，避免收尾后无人负责。项目复盘围绕四类内容展开：目标达成情况（对照成功标准）、计划与实际偏差及原因、变更处理的经验、可复用的做法与需改进的环节。复盘输出复盘记录，结论应具体到可执行的动作，而不是笼统的评价。
文档归档范围一般包括：项目章程或启动说明、验收标准、WBS与进度计划（含基线版本）、阶段评审记录、变更申请单与影响评估、验收确认单、移交清单、复盘记录。归档目录按阶段或文档类型组织，便于后续项目查阅。收尾的完成标志是：验收确认单签署、移交清单确认完毕、遗留项有责任人和时限、复盘记录完成、归档目录完整。
一个完整示例：三个月交付的系统上线项目
以下为演示情景，用于说明各阶段文档的填写方式，非真实客户案例。某内部系统上线项目计划三个月完成，团队包含项目经理1名、开发4名、测试2名、业务提出方1名。
启动阶段的验收标准写法示例：“核心业务流程（下单、审批、对账）在测试环境全流程跑通，抽样20笔业务数据与手工计算结果一致；系统支持50人并发操作，响应时间不超过3秒；上线后一周内无阻断级缺陷。”范围边界写明“本期不含移动端适配和第三方物流接口对接”。阶段划分为：需求与设计（第1个月）、开发与测试（第2个月）、上线与验收（第3个月），每个阶段以对应交付物通过评审为结束标志。
WBS与里程碑示例：需求与设计阶段分解为需求调研、规格说明书编写、规格评审、概要设计、设计评审五个工作包；里程碑“规格评审通过”设在第3周末，“设计评审通过”设在第4周末。开发与测试阶段按模块分解，测试任务依赖对应模块开发完成，关键路径为“核心模块开发→集成测试→回归测试”。
一次变更申请的处理示例：开发中期，业务提出方要求增加“审批流程支持三级会签”。变更申请单写明变更内容、影响范围（涉及审批模块的3个任务和2条验收标准）、工期影响（预计增加8个工作日，影响“开发完成”里程碑）。评估结论为影响关键路径，需调整里程碑。审批由项目发起人完成，获批后更新进度基线和验收标准，通知测试负责人调整测试用例。变更记录归档，复盘时作为“需求确认阶段应更充分”的依据。
阶段评审记录示例：“开发与测试阶段评审，参与人：项目经理、开发负责人、测试负责人、业务提出方。评审结论：有条件通过。待办：遗留的2个中等级缺陷在5个工作日内修复并回归，回归通过后进入上线阶段。”最终验收记录对照验收标准逐项确认，附抽样测试结果和并发测试报告，提出方签署验收确认单。
完成检查：瀑布项目做到什么程度算合格
检查按阶段进行，每项检查都要求有对应证据，而不是凭印象判断。下表给出各阶段的核心检查项、通过标准和证据要求。
| 阶段 | 检查项 | 通过标准 | 证据 |
|---|---|---|---|
| 启动 | 目标、范围边界、成功标准是否书面化 | 三项内容齐全且经提出方确认 | 项目章程或启动说明 |
| 启动 | 验收标准是否可验证 | 每条需求对应可检查的验收条目 | 验收标准文档 |
| 启动 | 角色分工是否落实到人 | 四类角色均有指定人员 | 角色责任表 |
| 计划 | WBS是否覆盖全部范围 | 每个工作包可估算、可交付、可指派 | WBS表 |
| 计划 | 依赖与关键路径是否明确 | 关键路径已识别并标注 | 进度计划 |
| 计划 | 基线是否冻结 | 基线经确认并有版本记录 | 基线版本记录 |
| 执行 | 阶段评审是否按标准进行 | 每次评审有书面结论和参与人 | 评审记录 |
| 执行 | 偏差与风险是否跟踪 | 偏差有原因分析，风险有责任人和措施 | 周会记录、问题清单 |
| 变更 | 变更是否走审批 | 每项变更均有申请、评估、审批记录 | 变更申请单、影响评估 |
| 变更 | 基线是否同步更新 | 批准变更后基线版本已更新并通知 | 更新后的基线、通知记录 |
| 收尾 | 验收是否逐项确认 | 验收标准全部有确认结论 | 验收确认单 |
| 收尾 | 移交与遗留项是否落实 | 移交清单确认，遗留项有责任人和时限 | 移交清单、遗留项登记 |
| 收尾 | 复盘与归档是否完成 | 复盘记录有可执行结论，归档目录完整 | 复盘记录、归档目录 |
常见失分点集中在三处：基线未冻结或冻结后随意改动，导致进度对比失去意义；变更无记录，范围悄悄扩大而工期和验收标准未同步调整；评审走形式，结论只有“通过”二字，没有对照标准的检查记录。检查时点建议设在每个阶段结束时和项目收尾时，由项目经理组织自查，阶段负责人提供证据，必要时由项目发起人抽查。检查发现的问题登记为待办项，明确责任人和完成时间，作为下一阶段跟踪的内容。
常见问题
瀑布项目执行中需求方临时提出新要求，应该直接做还是先走变更？
先判断这项要求是否改变已确认的范围、验收标准、里程碑或工期。只要触及其中任何一项，就应暂停实施，按变更流程提交申请单，写清变更内容、影响范围和工期成本影响，由对应权限的审批人决定。影响仅限单个阶段内部、不触及里程碑和验收标准的调整，可由项目经理审批；影响里程碑、总工期或验收标准的，由项目发起人或变更审批人审批。已经投入的工作量在变更记录中如实登记，作为后续复盘的输入。
阶段评审结论写“有条件通过”时，后续怎么跟踪才不流于形式？
“有条件通过”需要同时写清三件事：待办项的具体内容、每项的责任人、完成时限。待办项登记到问题清单，纳入下一阶段的周例会跟踪，完成情况作为进入下一阶段或最终验收的前置条件。再评审时可以只聚焦未通过项，但结论同样书面记录，并注明参与人和检查依据。如果待办项在时限内未完成，由项目经理判断是否影响里程碑，必要时升级到项目发起人。
关键路径上的任务已经延误，调整计划还算不算变更？
要看调整是否改变已冻结的基线。日常的任务顺序微调、在不影响里程碑的前提下重新分配负责人，属于执行层面的调整，由项目经理在周例会上决定并记录即可。一旦延误导致里程碑日期、项目总工期或验收标准需要改动，就属于正式变更，应提交变更申请、做影响评估并按权限审批，获批后更新基线版本并通知阶段负责人、评审人和提出方。区分这两种情况的标准应在启动阶段就写进变更管理规则，避免每次临时判断。
项目收尾时还有未完成项，验收确认单能不能先签？
可以签，但前提是把未完成项作为遗留问题单独登记，写明描述、影响、责任人和计划处理时间，并在验收确认单或附件中体现。验收确认的是交付物符合验收标准，遗留项确认的是后续由谁在什么时间跟进，两者分开记录。如果未完成项涉及核心验收标准，应先按变更流程调整验收标准或延期验收，再签署确认单，避免验收结论与实际交付状态不一致。
用工具管理瀑布项目时，基线和变更记录应该怎么对应？
基本做法是每次基线冻结或变更获批后都保留一个可追溯的版本，让进度对比始终以最新批准版本为准。在 ONES 中，项目计划支持按目标、交付物或项目阶段等维度分解工作、设置任务前后置依赖并用里程碑标记关键节点，设置项目计划和里程碑基线后可对比计划与执行的偏差，也能通过对比版本细节追溯变更前后的差异。工具记录的是结果，变更申请单、影响评估和审批结论仍需按流程留档，两者对应起来才能在复盘时还原决策过程。
