制定瀑布项目计划，先把可交付成果拆到可估算的工作包，再按依赖关系排出阶段与里程碑，明确每个任务的工期、负责人、输入和完成标准，最后补齐资源、风险与变更基线。计划成稿后要经过评审确认，作为后续变更控制的基准。本文聚焦单项目计划的制定方法，按范围确认、工作分解、依赖与工期估算、资源与里程碑、风险与基线、评审与变更控制的顺序展开，并给出可填写的工作分解表、角色职责表和完成检查清单。
要点总览（TL;DR）
- 瀑布项目计划按范围确认、工作分解、依赖与工期估算、资源与里程碑、风险与基线、评审与变更控制的顺序制定，前一步确认后再进入下一步。
- WBS 以可交付成果为导向拆到工作包，末级工作包要能估算、能分配、能验收，并记录输入、输出、负责人和完成标准。
- 排期先标强制依赖、找出关键路径，工期估算写明依据和假设，里程碑设在阶段交付物完成或关键评审点并配通过标准。
- 计划经评审确认后固化为基线，执行中按同一口径比对进度，偏差走变更审批并生成新基线，保留原基线便于追溯。
- 定稿前用完成检查清单逐项核对范围一致性、工作包可分配、关键路径、估算依据、缓冲、资源、风险与变更流程和基线状态。
瀑布项目计划的骨架：先定范围再排期
瀑布项目计划由八类要素构成：范围说明、工作分解结构（WBS）、任务依赖、工期估算、资源分配、里程碑、风险登记表、计划基线。这八类要素之间存在先后关系，前一项没有确认就进入后一项，后面的估算和排期会反复返工。
推荐的制定顺序如下，每一步都应有明确的产出物：
- 范围确认：明确项目目标、交付物清单和验收条件，产出范围说明。范围没有冻结，WBS 就缺少分解依据。
- 工作分解：把可交付成果逐层拆到工作包，产出 WBS 分解表。
- 依赖与工期估算：识别任务间前后置关系，估算每个工作包的工期，产出带依赖关系的任务清单。
- 资源与里程碑：为工作包分配负责人和资源，在阶段交付物完成或关键评审点设置里程碑，产出资源计划和进度计划。
- 风险与基线：登记风险及其应对措施，将评审通过的计划固化为基线版本。
这个顺序的核心逻辑是：范围决定拆什么，拆分决定估什么，估算和依赖决定怎么排，资源和里程碑决定谁来保证节点，风险与基线决定计划在执行中如何被比对和控制。组织级的流程制度、多项目组合排期以及敏捷框架的迭代管理，属于另外的管理层次，本文不展开。
从可交付成果拆到工作包：WBS的拆法
WBS 的拆分以可交付成果为导向，按“项目—阶段—可交付成果—工作包”逐层分解。末级工作包需要同时满足三个条件：可以估算工期和成本、可以分配给一个明确的负责人、有可验收的完成标准。只满足其中一两个条件，说明拆分粒度还需要调整。
粒度判断可以参考以下规则：
- 单个工作包的工期控制在便于跟踪的区间，通常为数天到两周；跨月且无法中途检查的工作包应继续拆分。
- 工作包小到“一个人半天完成”时，管理成本会超过跟踪收益，可以合并到同一可交付成果下。
- 同一工作包不应由两个以上角色共同负责，需要多人协作时拆成并行工作包并分别指定负责人。
每个工作包在分解表中记录四项信息：输入（开始前必须具备的文档、数据或前置成果）、输出（完成后交付的成果）、负责人、完成标准（评审通过、测试通过或文档签认等可核验条件）。下表是可参照填写的结构：
| WBS编号 | 工作包名称 | 输入 | 输出 | 负责人 | 完成标准 |
|---|---|---|---|---|---|
| 2.1 | 需求规格编写 | 范围说明、业务访谈记录 | 需求规格说明书 | 需求负责人 | 需求评审通过并签认 |
| 2.2 | 接口清单梳理 | 需求规格说明书 | 接口清单 | 技术负责人 | 接口清单经双方确认 |
| 3.1 | 概要设计 | 需求规格说明书、接口清单 | 概要设计文档 | 架构负责人 | 设计评审通过 |
拆分完成后做一次完整性核对：逐条对照范围说明中的交付物，确认每项都有对应的工作包承接；同时检查是否存在两个工作包描述同一份成果的情况。范围有遗漏会在执行阶段以返工形式暴露，范围重复则会造成重复估算和资源冲突。
排依赖、估工期、定里程碑
依赖关系分为强制依赖和可并行部分。强制依赖来自工作本身的先后逻辑，例如设计完成才能开发、开发完成才能测试；可并行部分则是没有直接输入输出关系的任务，可以安排在同一时间段由不同人员推进。排依赖时先标出强制依赖，再从任务链中找出耗时最长的一条路径作为关键路径。关键路径上的任务延误一天，项目结束时间就顺延一天，因此这些任务的负责人和资源需要优先保障。
工期估算常用的依据有三类：历史项目的实际工时数据、领域专家对工作量的判断、以及与类似项目的类比。无论采用哪种依据，都要在计划中记录估算假设，例如“按现有需求条目数量估算，若需求增加超过一定比例需重新估算”。假设写清楚，后续偏差分析才有对照口径。
里程碑设置在阶段交付物完成或关键评审点，每个里程碑要有明确的通过标准，例如“概要设计评审通过”“测试报告签认”“上线审批完成”。里程碑只标记结果节点，不承担具体工作量，这样进度汇报时能清楚区分“任务完成了多少”和“阶段是否真正通过”。
缓冲的处理方式需要提前约定。常见做法是在关键路径末端预留项目缓冲，在非关键路径的任务后预留接驳缓冲，并明确缓冲由项目经理统一管理，任务执行人不能自行消耗。缓冲位置和数量写进计划，执行中才能判断延误是否已经侵蚀了整体余量。
角色分工与各阶段交付物
计划制定涉及四类角色，职责边界需要在启动时讲清楚，避免出现“计划由项目经理一个人写完、执行时无人认账”的情况。
| 角色 | 在计划制定中的职责 | 主要产出 |
|---|---|---|
| 项目经理 | 组织范围确认与分解，汇总依赖与工期，编排进度计划，组织评审，维护基线 | 范围说明、进度计划、风险登记表、基线版本 |
| 职能负责人 | 确认本领域工作包的拆分合理性，提供工期估算依据，承诺资源投入 | WBS 中本领域部分、资源计划 |
| 任务执行人 | 参与工作包粒度与完成标准的确认，反馈估算假设 | 工作包输入输出说明、完成标准 |
| 评审方 | 对范围完整性、估算依据、资源可行性和里程碑可验证性提出评审意见 | 评审记录与确认结论 |
各阶段的交付物按制定顺序沉淀：范围说明对应范围确认，WBS 分解表对应工作分解，进度计划与资源计划对应排期与分配，风险登记表对应风险识别，基线版本对应评审通过后的计划冻结。这些文档在计划评审时一并提交，评审通过后进入版本管理。
计划变更的职责同样要明确：执行人提出变更申请并说明原因，项目经理评估对工期、资源和关键路径的影响，职能负责人确认资源调整是否可行，评审方或授权人审批，审批通过后由项目经理更新计划并生成新的基线版本。变更申请、评估意见和审批结论一并归档，作为后续追溯的依据。
示例：一个交付型项目的计划片段
以下为演示情景，用于说明填写方式，不代表真实客户案例。某交付型项目分为需求确认、设计、开发、测试、上线五个阶段，计划片段如下：
| 阶段 | 工作包 | 负责人 | 工期 | 依赖 | 完成标准 |
|---|---|---|---|---|---|
| 需求确认 | 需求调研与规格编写 | 需求负责人 | 8个工作日 | 范围说明签认 | 需求评审通过 |
| 设计 | 概要设计与接口定义 | 架构负责人 | 6个工作日 | 需求评审通过 | 设计评审通过 |
| 开发 | 功能开发与单元测试 | 开发负责人 | 15个工作日 | 设计评审通过 | 单元测试通过、代码评审完成 |
| 测试 | 系统测试与缺陷修复 | 测试负责人 | 10个工作日 | 开发提测 | 测试报告签认、遗留缺陷达到关闭标准 |
| 上线 | 上线准备与发布 | 项目经理 | 3个工作日 | 测试报告签认 | 上线审批完成、发布验证通过 |
里程碑设置为：需求评审通过、设计评审通过、测试报告签认、上线完成四个节点，每个节点对应上表中的完成标准。关键路径为需求确认→设计→开发→测试→上线，开发阶段工期最长，是资源保障的重点。
假设执行中测试阶段发现缺陷数量超出预期，测试负责人提出将系统测试工期延长5个工作日。项目经理评估后确认该任务在关键路径上，项目结束时间相应顺延5天，同时检查项目缓冲是否足以吸收。评估结论提交审批，审批通过后更新进度计划并生成新的基线版本，变更记录中保留原基线、变更原因和影响范围。若项目类型不同，例如以采购交付或设备安装为主，阶段划分需按实际交付物调整，不能直接套用上述五阶段结构。
计划评审与执行中的基线控制
计划评审是计划从草稿变为执行依据的关键环节。评审时逐项检查以下内容：范围说明中的交付物是否都有 WBS 工作包承接；工期估算是否写明了依据和假设；资源分配是否与职能负责人确认过；里程碑是否有可核验的通过标准；风险登记表是否覆盖了主要风险并有应对措施。评审意见形成记录，修改完成后由评审方确认，计划方可固化为基线。
基线确认后，实际进展按与计划相同的口径汇报，例如统一以工作包完成标准和里程碑通过情况作为进度判断依据，避免出现“任务完成了百分之八十”这类无法核对的表述。执行中定期将实际进展与基线比对，偏差出现时按以下路径处理：
- 分析偏差原因，区分是估算假设失效、资源未到位还是范围发生变化。
- 评估偏差对关键路径、里程碑和项目结束时间的影响。
- 形成变更申请，提交审批，审批通过后更新计划并生成新基线。
- 在变更记录中保留原基线、变更内容、审批结论和生效时间，便于后续版本对比和复盘。
计划的工作包、依赖关系、里程碑和基线版本需要有承载的地方。ONES 的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构并制定进度计划，任务可设置前后置依赖，里程碑用于标记重要时间点、事件或决策点；设置计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本对比追溯变更细节。资源安排上，项目经理可通过工时日历查看资源饱和度并调整节点负责人。这些能力对应的是计划落地后的承载与比对环节，计划本身的要素和顺序仍按前文方法确定。
完成检查：计划是否可执行的判断标准
计划定稿前，用以下清单逐项核对。全部满足，计划才具备执行和作为基线的前提；有未满足项，应回到对应步骤补充，而不是带着缺口进入执行。
| 检查项 | 判断标准 | 核对结果 |
|---|---|---|
| 范围与 WBS 一致 | 范围说明中的每项交付物都有工作包承接，无遗漏、无重复 | □ |
| 工作包可分配 | 每个末级工作包有明确负责人、输入、输出和完成标准 | □ |
| 依赖与关键路径清晰 | 强制依赖已标注，关键路径已识别并说明保障措施 | □ |
| 工期估算有依据 | 每个阶段的估算写明依据和假设，并经职能负责人确认 | □ |
| 里程碑可验证 | 每个里程碑有通过标准和对应评审方 | □ |
| 缓冲位置明确 | 项目缓冲和接驳缓冲的位置、数量及管理责任人已约定 | □ |
| 资源分配可行 | 资源投入经职能负责人承诺，关键路径任务资源优先保障 | □ |
| 风险与变更流程就绪 | 风险登记表已建立，变更提出、评估、审批和更新职责已明确 | □ |
| 基线已确认 | 计划经评审确认，基线版本已纳入版本管理 | □ |
清单核对完成后，计划即可作为执行和变更控制的基准。执行过程中每次基线更新，都应重新核对与变更相关的检查项，确保新版本同样满足可执行条件。
常见问题
瀑布项目计划制定到一半，范围又发生变化，应该怎么处理？
先判断变化发生在哪个环节。如果范围说明尚未确认，直接补充范围并同步调整 WBS；如果计划已经评审形成基线，则按变更流程处理：提出变更申请、评估对工期和关键路径的影响、审批通过后更新计划并生成新基线。不要在未评估影响的情况下直接改表，否则后续进度比对会失去统一口径。
工作包拆到多细比较合适？
判断标准是能否估算、能否分配给一个明确负责人、能否验收。工期通常控制在数天到两周，跨月且无法中途检查的工作包应继续拆分；小到一个人半天就能完成的工作包，管理成本会超过跟踪收益，可以合并。多人协作的工作包应拆成并行工作包并分别指定负责人。
关键路径上的任务延误了，缓冲也消耗完，怎么办？
先分析延误原因，区分估算假设失效、资源未到位还是范围变化；再评估对里程碑和项目结束时间的影响。缓冲耗尽意味着整体余量已被侵蚀，需要形成变更申请，说明顺延天数或调整方案，提交审批。审批通过后更新计划并生成新基线，变更记录中保留原基线、原因和影响范围，便于后续复盘。
计划评审时，评审方重点看什么？
重点核对五项：范围说明中的交付物是否都有工作包承接；工期估算是否写明依据和假设；资源分配是否经职能负责人确认；里程碑是否有可核验的通过标准；风险登记表是否覆盖主要风险并有应对措施。评审意见形成记录，修改完成后由评审方确认，计划才能固化为基线。
ONES 在瀑布项目计划落地中能承载哪些环节？
ONES 的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构并制定进度计划，任务可设置前后置依赖，里程碑用于标记重要时间点、事件或决策点。设置计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本对比追溯变更细节；项目经理还可通过工时日历查看资源饱和度并调整节点负责人。计划本身的要素和制定顺序仍按前文方法确定，工具承载的是排期、比对与变更追溯环节。
