制定瀑布项目计划，核心是把范围、阶段、交付物、依赖和验收标准按顺序固定下来，形成可执行、可跟踪的基线。本文按“定范围—分阶段—拆任务估算—排依赖定基线—明确责任—跟踪变更”的顺序展开，每一步说明输入、动作和输出，并给出可参照的计划片段与完成检查清单。
要点总览（TL;DR）
- 瀑布计划从范围开始：先写清验收标准、交付物清单和工期预算约束，范围未确认前排出的工期往往要重做。
- 阶段按交付物划分，每阶段定义目标、输出物和准入退出条件，评审关口设在阶段退出处并留下书面记录。
- 任务拆到3到10个工作日、有明确完成标志的粒度，估算时记录类比、参数或专家判断的依据，缓冲单独列出。
- 依赖连成进度网络后识别关键路径，里程碑对应可验证成果，计划经评审后冻结为基线，后续调整走变更流程。
- 执行期按周跟踪关键路径任务，偏差对照基线判断，基线调整只在变更获批后执行并保留原版本。
先定范围与成功标准：计划的地基
瀑布计划的排期建立在范围确定的前提上。范围还在变动时排出的工期和资源，往往在第一次评审后就要重做。制定计划的第一步，是把项目要交付什么、按什么标准算成功写清楚，形成一页范围与成功标准说明，作为后续阶段划分和估算的输入。
这份说明需要包含四类内容：
- 项目目标与验收标准。目标描述项目要解决的业务问题或交付的能力；验收标准写成可核验的条件，例如“系统上线后支持500名用户并发登录，关键页面响应时间不超过2秒”，而不是“系统运行稳定”。验收标准要区分功能验收、性能验收和文档验收，并写明由谁验收。
- 范围说明与主要交付物清单。列出项目要产出的主要交付物，如需求规格说明书、设计文档、测试报告、上线方案、培训材料。同时写明范围之外的内容，例如本期不包含移动端适配，避免执行中反复确认边界。
- 关键假设与约束。工期上限、预算额度、可用人员及投入比例、必须满足的合规要求、依赖的外部供应商或系统接口，都逐条列出。假设是“我们认为成立、但需要验证”的条件，约束是“不能突破”的边界，两者分开记录，便于后续偏差时追溯。
- 干系人与审批角色。写明项目发起人、业务负责人、项目经理、各职能负责人，以及范围说明由谁审批。范围说明经发起人和业务负责人签字确认后，才作为计划基线的一部分。
完成标志：范围与成功标准说明经过审批，验收口径可逐条核验，约束清单中的每一条都有对应的应对说明。
划分阶段与评审关口：把顺序开发落到结构上
瀑布项目的阶段按交付物划分，而不是按部门划分。按部门划分容易出现“设计部做完交给开发部”的接力式结构，阶段之间缺少可评审的成果；按交付物划分，每个阶段结束时都有明确的输出物可供确认，阶段衔接才有依据。
常见的阶段结构是：需求分析、设计、开发实现、测试、上线交付。阶段数量和名称按项目类型调整，例如涉及硬件采购的项目可在设计前增加选型与采购阶段。每个阶段需要定义四项内容：阶段目标、主要活动、输出物、准入与退出条件。
| 阶段 | 阶段目标 | 主要输出物 | 退出评审条件 |
|---|---|---|---|
| 需求分析 | 确认业务需求与验收口径 | 需求规格说明书、验收标准清单 | 业务负责人确认需求范围，验收标准可核验 |
| 设计 | 完成方案与技术设计 | 概要设计、详细设计、接口说明 | 技术评审通过，设计覆盖全部需求条目 |
| 开发实现 | 按设计完成功能开发 | 可运行版本、单元测试记录 | 功能自测通过，代码评审完成 |
| 测试 | 验证功能与性能达标 | 测试报告、缺陷清单 | 遗留缺陷达到约定标准，测试报告经确认 |
| 上线交付 | 完成部署与移交 | 上线方案、操作手册、培训记录 | 上线验证通过，运维接收确认 |
阶段准入条件说明“上一阶段交付什么才能开始本阶段”，退出条件说明“本阶段做到什么程度才算完成”。评审关口设在阶段退出处，由指定评审人对输出物做确认，确认结果形成书面记录。阶段衔接的交付方式要写清楚：输出物放在哪里、以什么版本交付、由谁签收。评审未通过时，明确返工范围和重新评审时间，避免阶段无限期停留。
分解任务、估算工期与资源
阶段划分完成后，从每个阶段的输出物向下拆解，形成工作分解结构（WBS）。拆解层级一般控制在三到四层：项目—阶段—工作包—具体任务。最底层任务应满足两个条件：有明确的完成标志，工期在一个可跟踪的周期内，通常为3到10个工作日；超过两周的任务继续拆分，低于半天的任务可合并到同一工作包。
估算方法按可得信息选择，并记录估算依据：
- 类比估算。参考以往类似项目的实际工期，按规模差异做调整。适用于有历史数据、项目相似度较高的情形，估算时要写明参照的是哪个项目、调整了哪些因素。
- 参数估算。用单位工作量乘以数量，例如按接口数量、页面数量、数据迁移表数量估算。适用于工作量与规模呈稳定比例的任务。
- 专家判断。由承担该任务的职能负责人或资深人员给出估算，适用于无历史数据的新任务。估算结果要记录判断依据和假设，便于后续复盘。
每项任务同时分配负责人和所需角色，例如开发任务需要后端工程师和测试工程师配合，就要写明双方投入比例。估算结果保留不确定性：对信息不足、外部依赖多的任务设置缓冲，缓冲单独列出并说明覆盖的风险，不直接摊进每项任务的工期里，否则偏差出现时无法判断是估算不准还是风险发生。
完成标志：WBS覆盖全部阶段输出物，每项任务有负责人、工期、资源需求和估算依据，缓冲有明确说明。
排定依赖与关键路径：确定里程碑和基线
把任务按依赖关系连成进度网络，是形成可执行计划的关键一步。依赖类型主要有四种：完成到开始（前置任务完成后才能开始）、开始到开始（两项任务可并行启动）、完成到完成（两项任务需同时结束）、开始到完成（较少使用）。瀑布项目中大量使用的是完成到开始关系，例如详细设计完成后才能开始开发。
依赖关系确定后，计算每条路径的总工期，总工期最长的路径即关键路径。关键路径上的任务没有浮动时间，任何延误都会直接推迟项目完成日期，因此这些任务是执行期跟踪的重点。非关键路径上的任务有一定浮动时间，可以在不影响总工期的范围内调整，但浮动时间被消耗完时，该路径也会转为关键路径，需要重新评估。
里程碑设置在阶段完成、重要评审、外部交付节点等位置，数量不宜过多，每个里程碑对应一个可验证的成果，而不是单纯的时间点。里程碑日期写入计划后，作为向干系人汇报进度的基准。
计划评审由项目经理组织，职能负责人、评审人和发起人参加，核对范围覆盖、依赖合理性、资源可用性和里程碑可行性。评审通过后，进度计划、里程碑清单和范围说明一起冻结为基线。基线化的含义是：此后对工期、范围、资源的调整都通过变更流程处理，基线本身保留原始版本，用于对比偏差。
角色分工与交付物责任
计划能否执行，取决于每项交付物是否有明确的责任人和审批人。建议用一张责任矩阵把角色和交付物对应起来，常用的是RACI：负责执行（R）、最终批准（A）、被咨询（C）、被通知（I）。
| 角色 | 计划制定中的职责 | 主要产物 |
|---|---|---|
| 项目发起人 | 批准范围、预算和里程碑，裁决重大变更 | 范围与基线审批记录 |
| 项目经理 | 组织计划编制、维护进度网络、跟踪偏差、发起变更评估 | 进度计划、跟踪报告、变更申请 |
| 职能负责人 | 提供任务估算、分配人员、确认本职能交付物质量 | 估算依据、交付物签收 |
| 评审人 | 按阶段退出条件评审输出物，给出通过或返工结论 | 评审记录 |
| 业务负责人 | 确认需求与验收标准，参与验收 | 需求确认、验收结论 |
每项阶段交付物指定一名责任人（R）和一名审批人（A），审批人不能与责任人同为一人。计划变更由提出方提交变更申请，项目经理组织影响评估，涉及范围或里程碑的变更由发起人审批，仅涉及任务排期微调的由项目经理审批并记录。
示例：一个系统上线项目的瀑布计划片段
以下片段演示从阶段到任务再到里程碑的组合方式，项目背景为某业务系统替换上线，工期约四个月，数据为演示情景。
阶段与交付物：需求分析阶段输出需求规格说明书和验收标准清单；设计阶段输出概要设计、详细设计和数据迁移方案；开发实现阶段输出可运行版本和单元测试记录；测试阶段输出测试报告和缺陷清单；上线交付阶段输出上线方案、操作手册和培训记录。
任务分解与估算：设计阶段拆为“概要设计（8个工作日，架构师负责）”“详细设计（12个工作日，开发组长负责）”“数据迁移方案（5个工作日，数据工程师负责）”。测试阶段拆为“测试用例编写（6个工作日）”“功能测试（15个工作日）”“性能测试（5个工作日）”，性能测试依赖功能测试主要缺陷修复完成。
依赖与里程碑：详细设计完成后开始开发；开发完成并通过自测后进入功能测试；功能测试遗留缺陷达到约定标准后开始性能测试。里程碑设为：需求基线确认、设计评审通过、开发完成、测试通过、上线完成，每个里程碑对应一次评审记录。
评审关口与验收：设计评审由架构师和业务负责人参加，核对设计是否覆盖全部需求条目；测试通过评审核对测试报告中的通过率和遗留缺陷等级；上线验收由业务负责人按验收标准清单逐条确认，运维团队签收操作手册。
执行中的跟踪、变更控制与完成检查
基线建立后，计划进入执行跟踪。跟踪周期按项目节奏设定，通常每周一次，关键路径上的任务可缩短到每两三天核对一次。数据来源包括任务完成情况、交付物提交记录、评审结论和实际工时。偏差判断以基线为参照：任务实际完成时间晚于计划、关键路径任务出现延期、里程碑存在无法按期达成的风险，都属于需要上报的偏差。偏差报告写明原因、影响范围和拟采取的纠正措施。
变更控制按固定流程运行：提出方提交变更申请，说明变更内容和原因；项目经理组织评估对工期、资源、范围和风险的影响；按变更级别提交审批，涉及基线要素的由发起人审批；审批通过后更新计划并记录变更编号，未通过的申请同样留档。基线调整只在变更获批后执行，原基线版本保留，用于对比和复盘。
计划制定是否完成，可用以下清单逐项核对：
- 范围与成功标准说明已审批，验收标准可逐条核验；
- 阶段划分覆盖全部交付物，每阶段有准入和退出条件；
- WBS覆盖所有阶段输出物，最底层任务有完成标志和负责人；
- 每项任务有工期、资源需求和估算依据，缓冲单独列出；
- 依赖关系完整，关键路径已识别，里程碑有对应成果；
- 计划经评审并基线化，基线版本已存档；
- 责任矩阵覆盖全部阶段交付物，审批人已指定；
- 跟踪周期、数据来源和变更流程已向团队说明。
当阶段交付物、评审关口和变更记录需要在同一处流转时，可以用 ONES 的工作项承载任务与工期、用文档管理阶段输出物、用评审记录留存关口结论，使基线版本与变更历史可追溯。工具承载的是计划的管理动作，计划本身的合理性仍取决于范围是否清楚、估算是否有依据。
常见问题
范围在项目启动时无法完全确定，还能先做瀑布计划吗？
可以先做，但要把不确定部分单独标出来。做法是把已确认的范围写入基线，把待确认的内容列为假设或待决事项，并写明由谁在什么时间点确认。排期时对这部分任务设置较宽的缓冲，或将其安排在依赖它的任务之前留出决策窗口。如果待确认范围涉及核心交付物，更稳妥的方式是先完成一轮需求澄清再基线化，避免基线刚建立就触发重大变更。
阶段评审没有通过，计划应该怎么调整？
评审未通过时，先明确返工范围：是输出物局部修改，还是需要回到上一阶段补充输入。局部修改通常只影响本阶段任务和后续紧邻任务，调整本阶段剩余工期并核对关键路径是否变化即可；需要回退时，影响会沿依赖链向后传导，应重新计算受影响路径的完成时间，并评估里程碑是否仍可达成。返工范围和重新评审时间要写入评审记录，避免阶段无限期停留。
关键路径上的任务延期了，应该压缩后续工期还是调整里程碑？
两种方式都可用，取决于延期的性质和可压缩空间。先评估后续关键任务是否有可压缩的余量，例如增加人力、并行开展部分工作，压缩后要确认质量和依赖条件仍然满足。如果压缩空间不足或会带来明显质量风险，则调整里程碑并走变更审批，同时通知受影响的干系人。无论选哪种，都要记录延期原因和采取的措施，作为后续复盘和估算修正的依据。
瀑布计划制定完成后，还需要滚动更新吗？
需要，但更新的是执行层的任务状态和经批准的变更，基线本身保持稳定。每周跟踪时更新任务完成情况、实际工时和偏差说明；变更获批后更新计划版本并记录变更编号，原基线存档用于对比。这样既能让计划反映实际进展，又能保留原始承诺，便于在项目结束时分析估算准确度和变更来源。
小型项目也需要完整的阶段划分和基线流程吗？
可以按比例简化。小型项目可合并阶段，例如把设计与开发合并为一个阶段，但每个保留阶段仍要有输出物和退出确认；基线可以只覆盖范围、里程碑和关键交付日期，不必细化到每项任务的审批。简化的是文档量和审批层级，范围清楚、交付物有人确认、变更有人决策这三件事仍然需要保留，否则计划执行中容易出现责任不清。
