瀑布项目计划的核心，是把项目按阶段顺序拆开，写清每个阶段的输入、活动、输出和完成标志，再确定谁负责、谁评审、满足什么条件才能进入下一阶段。一份可执行的计划至少包含阶段划分与顺序、交付物清单、里程碑与评审点、角色与审批职责、变更处理规则。下面按编制顺序说明做法，并给出可直接套用的表格与检查清单。
要点总览（TL;DR）
- 瀑布项目计划从阶段基线开始：按交付物形态、评审节点和依赖关系划分阶段，用准入准出条件控制阶段衔接。
- 每个阶段写清输入、活动、输出和完成标志四类字段，完成标志要可判定，如评审通过、签字确认或验收标准达成。
- 里程碑放在关键决策点和阶段交接处，识别阶段间依赖与关键路径，并把缓冲作为计划中明列的时间。
- 角色上区分计划编制、评审和批准职责，交付物责任人与验收人分开设置，可用 RACI 矩阵表达。
- 变更经申请、影响评估和批准后更新阶段计划与基线，例外情况记录并定期回顾，计划才能持续指导执行。
瀑布项目计划先定什么：阶段划分与顺序基线
编制瀑布计划的第一步是确定阶段基线，即项目分成哪几个阶段、按什么顺序推进、每个阶段在什么条件下结束。阶段基线一旦确定，后续的交付物、里程碑、角色分工都围绕它展开。划分阶段时，建议同时考虑三个依据：交付物的形态（每个阶段结束时产出什么可评审的成果）、评审节点的位置（哪些成果需要正式评审后才能继续）、依赖关系（哪些工作必须在另一项工作完成后才能开始）。
阶段顺序不只是先后排列，还要定义衔接条件，也就是准入准出规则。准入条件说明进入某阶段前必须具备什么，例如上一阶段交付物已评审通过、所需资源已到位；准出条件说明该阶段何时算完成，例如交付物已提交并通过评审、遗留问题已记录并有处理结论。把这两个条件写进计划，阶段交接才有判断依据，避免上一阶段工作未收尾就进入下一阶段。
范围基线与阶段边界需要对应起来。项目范围说明书或需求清单中的每一项内容，都应能落到某个阶段的交付物中；反过来，每个阶段的交付物也应能追溯到范围基线中的条目。这样在后续出现范围争议时，可以判断某项工作属于哪个阶段、是否在计划之内。
| 阶段名称 | 起止条件 | 主要交付物 | 进入下一阶段的前提 |
|---|---|---|---|
| 需求与方案 | 项目启动后开始，需求评审通过结束 | 需求规格说明、总体方案 | 需求与方案评审通过，范围基线确认 |
| 设计与开发 | 范围基线确认后开始，开发完成并通过内部测试结束 | 设计文档、可运行版本、测试记录 | 内部测试通过，遗留缺陷有处理结论 |
| 验收与交付 | 内部测试通过后开始，客户验收签字结束 | 验收报告、交付清单、操作手册 | 验收签字完成，交付物移交完毕 |
每个阶段要写清的四件事：输入、活动、输出与完成标志
阶段基线确定后，需要把每个阶段写到可执行的粒度。建议每个阶段计划固定包含四类字段：输入、活动、输出、完成标志。四类字段齐全，阶段计划才能既指导执行，又作为交接依据。
输入写清本阶段开始前必须具备的条件，包括上游交付物、所需资源和前置审批。例如“设计阶段输入：已评审通过的需求规格说明、架构师到位、开发环境可用”。输入缺失时应触发预警，而不是默认可以开工。
活动是阶段内的工作项拆分。拆分粒度以能分配给一个责任人、能估算工作量、能判断完成为宜。估算方式可采用类比估算或专家判断，并注明估算依据和假设条件。工作项之间如有先后关系，在计划中标注依赖。
输出是交付物清单，每项交付物应写明名称、格式和质量要求。质量要求尽量可检验，例如“接口文档需覆盖全部对外接口，字段说明完整，经开发与测试双方确认”。
完成标志是判断阶段结束的标准，常见形式包括评审通过、签字确认、验收标准达成。完成标志应可判定，避免写成“基本完成”“大致就绪”这类模糊表述。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 输入 | 上游交付物、资源、前置条件 | 需求规格说明（已评审）、测试环境 |
| 活动 | 工作项、责任人、估算 | 接口设计（3人日）、数据库设计（2人日） |
| 输出 | 交付物名称、格式、质量要求 | 设计文档，覆盖全部模块，经评审 |
| 完成标志 | 评审、签字或验收标准 | 设计评审会通过，评审记录归档 |
当阶段计划需要多人协作填写和评审时，可以把工作项和交付物放在统一的项目计划中管理。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，便于把上述四类字段落到具体工作项上。
里程碑、依赖与进度排布：把阶段计划连成时间线
各阶段计划写好后，需要连成整体时间线。里程碑应设置在关键决策点和阶段交接处，例如需求评审通过、设计冻结、验收签字。里程碑不是普通任务节点，它标记的是需要做出判断或确认的时间点，因此每个里程碑都应绑定明确的评审或决策动作。
阶段间依赖需要逐条识别。常见依赖包括：下游阶段的输入来自上游阶段的输出、某些活动共享同一资源、外部供应商交付影响内部排期。识别依赖后，找出决定项目总工期的关键路径，关键路径上的任务延误将直接推迟项目完成时间，应重点跟踪。
缓冲与风险预留要写进计划，而不是留在口头。可以在关键路径末端设置项目缓冲，在高风险活动后设置阶段缓冲，并注明缓冲的用途和动用规则。缓冲不是隐藏的余量，而是计划中明确列出的时间，使用时需记录原因。
| 里程碑 | 位置 | 评审或决策内容 | 前置依赖 |
|---|---|---|---|
| M1 需求基线确认 | 需求阶段结束 | 需求范围与优先级确认 | 需求评审会完成 |
| M2 设计冻结 | 设计阶段结束 | 设计方案定稿，变更需走流程 | M1 通过、设计评审完成 |
| M3 验收签字 | 验收阶段结束 | 客户确认交付物符合要求 | 内部测试通过、交付物移交 |
在工具中排布时，为项目任务设置前后置依赖可以让任务关联一目了然，用里程碑标记重要时间点、事件或决策点，便于团队按同一时间线协作。
角色与职责：谁编计划、谁评审、谁批准阶段交接
瀑布计划的执行效果很大程度取决于角色是否清晰。建议至少区分四类职责：项目经理负责整体计划的编制与维护，协调阶段之间的衔接；阶段负责人负责本阶段计划的细化、执行和交付物提交；评审人负责对交付物和阶段完成情况给出评审意见；批准人负责对阶段交接和重大变更做出决定。四类职责可以由同一人兼任，但应在计划中写明，避免出现无人负责的环节。
阶段评审的参与角色应覆盖上游和下游：上游交付方说明成果，下游接收方确认输入是否可用，评审人给出结论，批准人决定是否放行。决策方式可以约定为评审会一致通过或批准人裁定，并在计划中写明未通过时的处理路径，例如限期整改后复评。
交付物责任人与验收人应分开设置。责任人负责产出交付物，验收人负责判断交付物是否满足要求。两者分开，验收才有独立性。下表以 RACI 形式给出一个参考分工，A 为批准、R 为负责、C 为被咨询、I 为被通知。
| 活动 | 项目经理 | 阶段负责人 | 评审人 | 批准人 |
|---|---|---|---|---|
| 编制整体计划 | A/R | C | I | I |
| 细化阶段计划 | C | A/R | I | I |
| 交付物评审 | C | R | A/R | I |
| 阶段交接批准 | R | C | C | A |
| 重大变更审批 | R | C | C | A |
评审和交接如果靠邮件和会议记录流转，容易出现结论散落、状态不清的问题。ONES 可帮助团队规划项目工作、安排任务、跟踪进度，并围绕关键阶段和交付目标开展协同管理，使阶段评审的结论和交付物状态有统一的记录位置。
变更与例外：范围、进度调整如何回到计划里
瀑布计划执行中出现变更属于正常情况，关键在于变更经过评估并反映到计划中。建议的流程是：提出变更申请，说明变更内容、原因和期望时间；由项目经理组织影响评估，分析对范围、进度、成本和质量的影响；由批准人根据评估结论决定是否接受；接受后更新阶段计划、里程碑和基线，并通知相关角色。
影响评估要具体到受影响的阶段和里程碑。例如范围增加会导致哪个阶段的工作项增加、哪个里程碑需要后移、关键路径是否改变。评估结论应写入变更记录，作为后续追溯的依据。变更对基线的影响处理方式应事先约定：是更新基线并保留历史版本，还是在原基线之外另设新基线，两种方式都要在计划中写明。
例外情况包括未按准入条件进入下一阶段、评审未通过先行推进、缓冲被动用等。例外应记录发生时间、原因、处理措施和批准人，定期回顾，判断是否需要调整计划或流程。例外记录的价值在于让偏差可见，而不是追究责任。
| 变更记录字段 | 填写内容 |
|---|---|
| 变更编号与提出人 | 唯一编号，提出人及提出日期 |
| 变更内容与原因 | 具体调整什么，为什么调整 |
| 影响评估 | 受影响阶段、交付物、里程碑、关键路径 |
| 决策结论 | 接受、拒绝或延期，批准人及日期 |
| 计划更新 | 更新后的阶段计划与基线版本 |
计划与执行的偏差需要可对比。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题；通过对比版本细节，可以追溯变更细节，为变更记录提供依据。
一个完整示例：从阶段表到里程碑的瀑布计划
以下示例为演示情景，用于说明前述方法如何组合，不代表真实项目数据。某内部系统升级项目周期约三个月，团队包含项目经理、需求负责人、开发负责人、测试负责人和业务方代表。
阶段划分：需求与方案阶段（第1至3周），交付需求规格说明和总体方案，完成标志为需求评审通过、范围基线确认；设计与开发阶段（第4至9周），交付设计文档、可运行版本和测试记录，完成标志为内部测试通过、遗留缺陷有处理结论；验收与交付阶段（第10至12周），交付验收报告、交付清单和操作手册，完成标志为业务方验收签字。
里程碑设置：M1 需求基线确认放在第3周末，由业务方代表批准；M2 设计冻结放在第5周末，设计变更此后需走变更流程；M3 验收签字放在第12周末，由业务方代表批准。依赖关系上，开发工作依赖设计文档完成，验收依赖内部测试通过，关键路径为需求评审、设计、开发、测试、验收。
角色分工：项目经理编制整体计划并跟踪关键路径；需求负责人和开发负责人分别担任阶段负责人；测试负责人担任测试相关交付物的评审人；业务方代表担任里程碑批准人。变更处理：开发阶段中业务方提出增加一项报表需求，项目经理评估后确认影响开发阶段约5人日、M3 可能后移一周，提交批准人决策，接受后更新阶段计划和基线，并在变更记录中登记。
在工具中落地时，可以用「项目计划」按阶段分解工作项并设置依赖与里程碑，把交付物与评审结论关联到对应工作项，使示例中的阶段表、里程碑和角色分工在同一计划中可查。
完成检查：瀑布项目计划是否可执行的核对项
计划编制完成后，可用以下清单逐项核对。每一项都应有明确答案，存在否定的项目应回到对应章节补充。
- 阶段划分是否覆盖项目全范围，每个阶段是否有明确的起止条件和主要交付物？
- 每个阶段的输入、活动、输出、完成标志四类字段是否齐全，完成标志是否可判定？
- 范围基线中的每项内容是否都能对应到某个阶段的交付物？
- 阶段之间的准入准出条件是否写明，交接是否有判断依据？
- 里程碑是否设置在关键决策点和阶段交接处，每个里程碑是否绑定评审或决策动作？
- 阶段间依赖是否识别，关键路径是否明确，缓冲是否在计划中列明？
- 计划编制、评审、批准三类职责是否落实到人，交付物责任人与验收人是否分开？
- 变更申请、影响评估、审批和计划更新的流程是否写明，变更记录字段是否完整？
- 例外情况的记录方式和回顾机制是否约定？
- 计划是否有统一存放位置，相关角色能否查到最新版本和基线？
核对通过后，计划即可作为阶段交接和进度跟踪的依据。执行过程中按变更流程维护计划，定期用基线对比检查偏差，瀑布计划的控制作用才能持续发挥。
常见问题
瀑布项目计划编制完成后，执行中还需要调整吗？
需要。瀑布计划的阶段基线相对稳定，执行中的范围、进度调整仍会持续发生。建议按变更流程处理：提出变更申请，评估对受影响阶段、交付物和里程碑的影响，由批准人决策后更新计划与基线，并保留历史版本。定期用基线对比检查偏差，判断是否需要调整后续阶段的排布。
阶段评审未通过，但项目进度压力很大，可以先进入下一阶段吗？
这属于计划中的例外情况。如果确需先行推进，应在计划中约定例外处理规则：记录发生时间、原因、处理措施和批准人，明确遗留问题的整改期限和复评安排。例外记录的作用是让偏差可见、可追溯，避免未收尾的工作被带入后续阶段而难以定位。
小型瀑布项目是否也需要完整的角色分工和变更记录？
可以按项目规模裁剪，但两类职责建议保留：一是阶段完成的判断由谁做出，二是交付物由谁验收。人员较少时，计划编制、评审和批准可以由同一人兼任，但要在计划中写明。变更记录可以简化字段，至少保留变更内容、影响和决策结论，便于后续追溯。
瀑布计划中的缓冲应该怎么设置才不至于变成隐藏余量？
把缓冲作为计划中明确列出的时间，注明用途和动用规则。常见做法是在关键路径末端设置项目缓冲，在高风险活动之后设置阶段缓冲。动用缓冲时记录原因和批准人，定期回顾缓冲消耗情况，据此判断后续阶段是否需要调整排期。
用工具管理瀑布计划时，阶段、交付物和评审结论如何放在一起？
可以把阶段作为计划分解的维度，在每个阶段下建立工作项并设置前后置依赖和里程碑，把交付物与对应工作项关联，评审结论记录在同一位置。ONES 支持用「项目计划」按目标、交付物或项目阶段等维度分解计划和工作，并支持设置任务依赖、里程碑以及计划与里程碑基线，便于对比计划与执行的偏差。
