瀑布项目计划的核心，是把范围、阶段、里程碑、依赖和基线一次讲清，再通过变更控制执行。本文面向需要为单个项目编制瀑布式计划的项目经理或负责人，按“定范围—排进度—建基线—分角色—做检查”的顺序给出可执行步骤和配套产物，覆盖从计划编制到基线调整的全过程。
要点总览（TL;DR）
- 瀑布项目计划先锁定可交付物、验收标准和阶段出口准则，再进入排期，避免中期才发现验收分歧。
- 进度计划以里程碑标记可验证的决策点，识别跨阶段依赖并找出关键路径，把关键路径任务作为跟踪重点。
- 计划草案经评审签署后冻结为基线，后续调整通过变更请求评估进度、资源和质量影响，批准后重新基线并保留旧版本。
- 项目经理、职能负责人、评审者和阶段负责人分别在编制、审批、跟踪阶段承担明确职责与交付物，责任落实到人。
- 用完成检查清单逐项核对范围、阶段出口、里程碑、依赖、基线与角色分工，全部通过后再进入执行。
瀑布项目计划先定什么：范围、阶段与验收出口
动手排期之前，先把“做什么、做到什么程度算完成、分几段做”锁定下来。这一步的产物是一份范围与阶段定义表，后续的进度、资源和基线都以它为输入。范围没定清就排期，往往在项目中期才发现验收标准有分歧，返工代价最高。
可交付物清单与验收标准
把项目最终要交出的东西逐项列出，每一项都写明验收标准。可交付物既包括对外交付的产品、系统或文档，也包括对内交付的设计说明、测试报告、上线方案。验收标准要写成可判定的条件，例如“接口文档覆盖全部对外接口，经接口负责人签字确认”，避免“文档完整”“质量达标”这类无法核对的表述。
编制时可参照以下字段逐条填写：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 可交付物名称 | 唯一、可识别 | 设备控制软件 V1.0 |
| 验收标准 | 可判定、有确认人 | 通过全部功能测试用例，测试负责人签署测试报告 |
| 所属阶段 | 对应一个阶段出口 | 系统测试阶段 |
| 验收方式 | 评审、测试或演示 | 测试 + 评审 |
阶段划分与阶段出口准则
瀑布项目的阶段以可交付物和决策点为边界划分，常见形态是需求、设计、开发、测试、上线（或交付）几个阶段。每个阶段都要写明出口准则，即“满足什么条件才能进入下一阶段”。出口准则通常包含三类内容：本阶段可交付物已完成并通过评审、遗留问题已关闭或有明确处理计划、下一阶段所需输入已齐备。
阶段划分不宜过粗也不宜过细。过粗会让阶段内长时间缺少检查点，问题积累到阶段末才暴露；过细会增加评审开销。一个实用的判断是：每个阶段应能对应一次有明确结论的评审，且阶段长度与项目的检查节奏相匹配。
范围基线与变更触发条件
范围基线是经评审确认的可交付物清单与验收标准的集合，它是判断“是否超范围”的参照。基线确认后，出现以下情况应触发变更评估：新增或删减可交付物、验收标准发生实质变化、阶段出口准则调整。变更触发后走变更请求流程，而不是在计划文档里直接改掉，这样范围变化才有记录、有评估、有批准人。
从阶段到里程碑：进度、依赖与关键路径怎么排
范围与阶段确定后，把它们放到时间轴上，形成带里程碑、依赖关系和关键路径的进度计划草案。这一节解决“何时做、先后顺序如何”的问题。
里程碑设置原则与检查点
里程碑标记项目中的重要时间点、事件或决策点，例如“需求评审通过”“样机交付”“系统测试完成”“上线评审通过”。设置里程碑时把握三条原则：一是每个里程碑对应一个可验证的结果，而不是一个模糊的进度百分比；二是里程碑与阶段出口准则挂钩，阶段结束通常就是一个里程碑；三是里程碑数量与项目周期匹配，周期越长，中间检查点越需要加密。
任务分解到可估算粒度
把每个阶段内的任务分解到可以估算工期和资源的粒度。经验上，单项任务的工期控制在数天到两周之间较易跟踪；超过这个范围的任务继续拆分，直到负责人能给出有依据的工期估计。分解时按可交付物或工作包组织，保证每个任务都有明确的完成标志和负责人。
跨阶段依赖与关键路径识别
为任务设置前后置依赖，重点识别跨阶段依赖，例如设计评审通过才能开始开发、硬件到货才能开始联调。依赖关系理清后，找出从项目开始到结束耗时最长的那条任务链，即关键路径。关键路径上的任务一旦延误，总工期直接受影响，因此这些任务是进度跟踪的重点。非关键路径任务有一定的浮动时间，可以据此安排资源错峰。
资源与工期估算的输入
工期估算不能只凭经验拍数，需要几类输入：任务的工作量与复杂度、承担任务的人员技能与可用时间、外部依赖的交付时间（如供应商到货、第三方接口开放）、组织的历史数据或类似项目参考。资源估算则要结合人员饱和度，避免把同一人同时排进多个并行任务。估算结果写入进度计划时，注明估算依据和假设条件，便于后续偏差分析时判断是估算问题还是执行问题。
计划基线怎么建立与变更：评审、冻结与调整流程
进度计划草案完成后，需要经过评审、签署并冻结为基线，之后按变更控制执行。基线的作用是提供一个稳定的比较基准，让“计划与执行的偏差”可以被度量。
基线评审参与角色与签署
基线评审通常由项目经理组织，参与方包括各阶段的可交付物负责人、承担关键任务的职能负责人，以及质量或评审角色。评审关注三件事：范围与验收标准是否完整可判定、进度与资源安排是否可行、依赖与风险是否已识别并有应对。评审通过后由项目经理与各职能负责人签署确认，签署记录与基线版本一并归档。
基线冻结后的变更请求流程
基线冻结后，任何对范围、里程碑日期、关键路径任务或资源安排的调整，都应通过变更请求提出。流程一般包括：提出变更并说明原因、评估变更对进度、资源和质量的影响、由授权人审批、批准后更新计划并重新基线、通知受影响的角色。变更请求要保留记录，便于在项目复盘时追溯计划为何调整。
变更影响评估与重新基线条件
影响评估至少覆盖三个方面：对关键路径和总工期的影响、对资源饱和度和成本的影响、对已确认验收标准的影响。评估结论可以是批准、驳回或调整后批准。满足以下条件时执行重新基线：变更已获批准、受影响的计划内容已更新、相关角色已确认新的安排。重新基线后保留旧版本，用于对比版本细节、追溯变更过程。
在工具层面，ONES 的项目计划场景支持创建工作分解结构、设置任务前后置依赖，并用里程碑标记重要时间点、事件或决策点；同时支持设置项目计划和里程碑基线，对比计划与执行的偏差，并通过版本对比追溯变更细节。这些能力对应本节描述的编制、冻结与调整动作，具体配置以实际版本为准。
角色与交付物分工：谁编计划、谁审批、谁跟踪
计划能否落地，取决于每个动作是否有人负责、有明确产物。下表按角色列出编制、审批、跟踪三个阶段的主要职责与交付物。
| 角色 | 编制阶段 | 审批阶段 | 跟踪阶段 |
|---|---|---|---|
| 项目经理 | 组织范围与阶段定义，汇总进度计划草案 | 提交基线评审，组织签署 | 跟踪里程碑与关键路径偏差，发起变更请求 |
| 职能负责人 | 提供任务工期与资源估算，确认本领域可交付物 | 评审并签署本领域相关基线内容 | 报告任务进展，处理本领域依赖与风险 |
| 评审者（质量或技术评审角色） | 确认验收标准可判定 | 参与基线评审，出具评审意见 | 参与阶段评审，核对出口准则 |
| 阶段负责人 | 分解本阶段任务，明确完成标志 | 确认阶段出口准则 | 组织阶段评审，提交阶段完成报告 |
阶段评审与里程碑跟踪的责任人需要明确到人：阶段评审由阶段负责人组织、项目经理参与确认；里程碑达成情况由项目经理汇总，在里程碑节点向项目干系人通报偏差与纠偏措施。责任分工写入计划文档，避免出现“大家都以为别人在跟踪”的情况。
示例：一个含硬件交付的瀑布项目计划片段
以下为演示情景，用于说明填写方式，不代表真实项目数据。
某设备控制系统项目分为需求、设计、开发、联调测试、交付五个阶段。范围与阶段定义表节选如下：
| 阶段 | 主要可交付物 | 阶段出口准则 | 里程碑 |
|---|---|---|---|
| 需求 | 需求规格说明书 | 需求评审通过，遗留问题关闭 | M1 需求评审通过 |
| 设计 | 软硬件设计说明 | 设计评审通过，接口定义确认 | M2 设计冻结 |
| 开发 | 软件版本、硬件样机 | 单元测试通过，样机自测完成 | M3 样机完成 |
| 联调测试 | 测试报告 | 全部用例执行完毕，严重缺陷清零 | M4 测试通过 |
| 交付 | 交付包与操作手册 | 客户验收签字 | M5 验收交付 |
依赖与关键路径在示例中的体现：硬件样机制作依赖设计冻结（M2），联调测试依赖样机完成（M3）与软件版本发布，因此“设计冻结—样机制作—联调测试”构成关键路径，样机制作周期一旦延长，M4 与 M5 顺延。软件侧的部分开发任务有浮动时间，可在样机制作期间并行推进。
基线变更在示例中的处理：联调测试阶段发现某接口需增加兼容性要求，属于范围变化。项目经理提出变更请求，评估结论为增加约一周测试工作量、M4 顺延，关键路径相应调整。变更经审批后更新计划并重新基线，旧版本保留用于对比，变更记录在阶段评审中通报。
完成检查：计划可执行性的核对项
计划编制完成后，用以下清单逐项核对。全部通过，计划才达到可执行与可跟踪的标准。
- 范围与验收标准：每项可交付物都有可判定的验收标准和确认人，范围基线已确认。
- 阶段出口准则：每个阶段都有明确的出口准则，且准则可验证、有对应评审。
- 里程碑：每个里程碑对应可验证的结果，与阶段出口挂钩，数量与项目周期匹配。
- 任务粒度：任务已分解到可估算、可跟踪的粒度，每项任务有负责人和完成标志。
- 依赖与关键路径：跨阶段依赖已识别，关键路径已明确并标注为跟踪重点。
- 资源估算：工期估算有依据和假设条件，关键人员饱和度已核对。
- 基线与变更流程：基线已评审签署并冻结，变更请求流程、评估口径和审批人已明确。
- 角色与交付物：编制、审批、跟踪各阶段的职责已落实到人，阶段评审与里程碑跟踪有明确责任人。
核对中发现缺项，回到对应章节补齐后再进入执行。计划执行期间，按里程碑和阶段评审检查偏差，偏差超出容忍范围时走变更流程调整基线，保持计划与执行的可比性。
常见问题
瀑布项目已经开工，还能补建计划基线吗？
可以，但需要把补建当作一次正式的基线建立动作来做。先补齐范围与阶段定义表，明确已完成部分的可交付物和验收标准；再以当前实际进度为起点整理剩余任务的依赖与关键路径；然后组织评审签署，把补建后的计划冻结为基线。补建前的执行情况作为历史记录保留，不并入基线，这样后续偏差对比才有清晰起点。
阶段出口准则和里程碑有什么区别，需要重复设置吗？
两者关注点不同。阶段出口准则是判断“能否进入下一阶段”的条件集合，通常包含可交付物完成、遗留问题处理和下一阶段输入齐备；里程碑是时间轴上的标记点，用来向干系人通报进展和决策结果。实践中常把阶段结束设为里程碑，此时里程碑的达成条件就是阶段出口准则，不必重复定义，但里程碑还应写明通报对象和决策事项。
关键路径上的任务延误后，应该先压缩工期还是先走变更？
先判断延误是否影响已冻结的里程碑日期。若在容忍范围内，由项目经理组织纠偏，例如调整非关键路径资源支援关键任务，纠偏后按原基线继续跟踪；若预计影响里程碑或总工期，则提出变更请求，评估对进度、资源和质量的影响，由授权人审批后重新基线。两种处理都要留记录，便于复盘时区分执行问题和估算问题。
跨阶段依赖涉及外部供应商时，计划里要写哪些内容？
至少写明供应商交付物、约定交付时间、验收方式和延误时的应对方案。把供应商交付设为前置依赖，并在进度计划中标注其对关键路径的影响；同时准备替代或缓冲安排，例如预留到货后的缓冲时间、约定分批交付。供应商的实际交付时间应作为进度跟踪的固定检查项，在里程碑评审中一并核对。
小项目也需要完整的基线评审和变更流程吗？
流程可以简化，但基线本身建议保留。小项目可把评审合并为一次范围与进度确认会，由项目经理和主要交付负责人签署；变更控制可简化为书面变更记录加一名授权人审批。判断标准是：范围、里程碑日期和关键路径任务发生变化时，能否找到谁批准、为什么改、改前改后的版本。满足这一点，流程就算到位。
