瀑布项目的阶段计划要能指导执行，关键在于三件事写清楚：阶段边界落在可独立验收的成果上，每个阶段的交付物有责任人和可判定的完成标志，相邻阶段之间有成对的准入与退出条件。本文按“切边界—排交付—定衔接—分角色—看示例—做检查”的顺序展开，适用于新项目启动时制定单项目层面的阶段计划。阶段计划中的工作项、里程碑、文档与评审记录，可以在ONES中承载并与基线对比。
要点总览（TL;DR）
- 阶段边界切在成果可独立验收、责任可交接的位置：先按交付物和决策点切出阶段，再用工期约束校验阶段长度，避免按日历平均切分。
- 阶段交付安排要写清交什么、谁负责做、谁负责评审、什么状态算完成；完成标志用“交付物+检查方式+通过标准+确认人”的结构写成可判定的检查项。
- 衔接条件成对设置：上一阶段的退出条件与下一阶段的准入条件一一对应，评审结论分为放行、带条件放行、返工、暂缓，并写明各结论的决策人。
- 阶段计划由项目经理牵头编制与维护，技术负责人、质量角色和业务方按职责参与评审与签署；基线化后影响边界或衔接条件的变更走提交、影响评估、审批、记录路径。
- 计划编制完成后用检查清单逐项核对边界、交付物、责任人、完成标志、衔接条件、评审规则、变更路径和里程碑对齐情况，未通过项优先补齐再基线化。
先定划分依据：阶段边界从哪里切
阶段边界应切在“成果可以独立验收、责任可以交接”的位置。判断一个候选边界是否成立，看三点：该位置是否有可交付、可检查的成果；是否对应一个需要做出继续投入决策的时点；交接后下一阶段的责任人是否能独立开展工作。三条都满足，边界就基本可靠；只满足时间节点而成果尚不可验收，边界应后移。
按交付物与决策点切分，与按时间平均切分会产生不同结果。按时间切分容易得到“第一个月、第二个月”这类边界，阶段结束时说不清完成了什么；按成果切分则得到“需求规格通过评审”“系统测试报告签署”这类边界，评审时有明确对象。时间在阶段划分中作为约束条件使用：先按成果切出阶段，再用工期要求校验阶段长度是否可接受，必要时合并或拆分，而不是反过来用日历决定边界。
识别边界候选点时，重点看两类位置。一是关键风险集中处，例如技术方案存在多种路线、外部接口依赖第三方、监管审查节点；这类位置单独成阶段，便于集中资源和决策。二是外部依赖交接处，例如供应商交付、客户确认、上游系统就绪；这类位置作为边界，可以把等待和返工的影响限制在一个阶段内。
阶段粒度需要取舍。阶段过多，评审和文档成本上升，阶段间的等待时间拉长；阶段过少，风险暴露晚，问题积累到后期才被发现。可操作的判断是：一个阶段内部如果存在两种以上性质差异很大的工作（如方案设计与编码实现），或存在一个必须单独决策的风险点，就考虑拆分；两个相邻阶段如果交付物由同一批人连续完成、中间没有实质决策，就考虑合并。
常见序列“需求—设计—开发—测试—上线”适用于需求相对明确、计划性较强的项目，可作为起点而非固定模板。调整方式举例：需求不稳定时，在需求与设计之间增加原型验证或方案评审阶段；涉及硬件或外部集成时，在设计之后增加接口联调阶段；上线风险高的项目，在上线前单独设试运行或灰度验证阶段。调整后仍需保证每个阶段有可验收成果。
完成本节工作后，应产出一份阶段边界划分依据清单，至少包含：切分原则（成果可验收、决策点、责任交接）、边界候选点及其理由、最终确定的阶段序列及各阶段一句话目标。
阶段交付安排：每个阶段交什么、谁来做、何时算完成
阶段交付安排要回答四个问题：交什么、谁负责做、谁负责评审、什么状态算完成。四项缺一项，阶段计划在执行中就会出现“做完了但没人认”或“评审过了但标准不明”的情况。
交付物按类型区分，便于安排评审方式。文档类交付物（需求规格、设计说明、测试方案）以评审通过为完成；可运行版本类交付物（构建包、部署环境、演示版本）以在约定环境验证通过为完成；评审记录类交付物（评审意见、问题清单及关闭情况）以问题关闭或明确遗留处理为完成；验收结论类交付物（阶段验收单、客户确认函）以签署为完成。一个阶段通常包含多种类型，应分别列出，避免只写“完成需求文档”而漏掉评审记录。
责任角色与评审角色要分开。交付物的负责人对内容和按时提交负责，评审人对是否符合约定标准负责。同一人兼任两者时，应在计划中注明，并考虑增加独立检查环节。评审人应在阶段开始前确定，避免阶段末临时找人。
完成标志的写法要可判定。可用结构是“交付物 + 检查方式 + 通过标准 + 确认人”。例如“需求规格说明书经业务方与技术负责人评审，评审意见全部关闭或遗留项已登记处理计划，由项目经理确认”，比“需求阶段完成”更可执行。完成标志中出现“基本完成”“大致符合”这类表述时，应改写为具体检查项。
交付时间与里程碑的关系是：里程碑标记重要时间点、事件或决策点，阶段交付物的计划完成时间应落在里程碑之前或与之对齐，使里程碑成为阶段成果的检查时点而非孤立日期。里程碑日期调整时，应同步检查对应阶段交付安排是否仍可行。
阶段交付安排表可按以下结构填写：
| 阶段 | 交付物 | 负责人 | 评审人 | 完成标志 | 计划时间 |
|---|---|---|---|---|---|
| 需求 | 需求规格说明书、需求评审记录 | 需求负责人 | 业务方、技术负责人 | 评审意见关闭或遗留项有处理计划，项目经理确认 | 第1—3周 |
| 设计 | 概要设计、接口设计、设计评审记录 | 技术负责人 | 架构评审人、测试负责人 | 设计评审通过，接口清单经上下游确认 | 第4—6周 |
| 开发 | 可运行版本、单元测试记录 | 开发负责人 | 技术负责人 | 约定环境部署成功，单元测试通过率达到计划值 | 第7—12周 |
| 测试 | 测试报告、缺陷清单 | 测试负责人 | 项目经理、业务方 | 测试用例执行完毕，遗留缺陷已分级并有处理结论 | 第13—16周 |
| 上线 | 上线方案、上线确认单 | 项目经理 | 业务方、运维负责人 | 上线检查项全部通过，业务方签署确认 | 第17周 |
表中内容为示例结构，实际填写应结合项目规模与评审要求调整。
阶段间衔接条件：准入、评审与变更怎么卡住
衔接条件的作用是让“能否进入下一阶段”成为可判定的事项。做法是成对设置：上一阶段的退出条件与下一阶段的准入条件一一对应，退出条件满足即准入条件满足，避免两套标准互相矛盾。例如上一阶段退出条件为“设计评审通过且接口清单确认”，下一阶段准入条件即写“设计评审记录已归档、接口清单已由上下游签署”。
阶段评审的结论应分为几类并明确放行规则：放行，全部条件满足，进入下一阶段；带条件放行，主要条件满足，遗留项有责任人和截止时间，允许在下一阶段初期并行关闭；返工，关键条件未满足，本阶段补充工作后重新评审；暂缓，存在外部依赖或重大未决问题，暂停推进并升级决策。每类结论的决策人应在计划中写明，通常由项目经理提出、阶段评审会决策，重大事项升级至项目发起人。
未满足条件时的处理要提前约定，而不是临时协商。带条件进入适用于遗留项不影响下一阶段主体工作的情形，需登记遗留清单并设定关闭时点；返工适用于交付物质量不达标的情形，返工范围和工作量应评估后更新计划；暂缓适用于外部依赖未就绪或关键决策未定的情形，应明确恢复条件和升级路径。
阶段间变更请求的路径包括：提出变更（说明变更内容、原因、影响阶段）、影响评估（对交付物、工期、资源、后续阶段衔接条件的影响）、审批（按变更影响范围确定审批层级）、更新计划与基线、通知相关方。变更记录应保留变更前后的对比，便于后续追溯。阶段计划基线化后，任何影响阶段边界或衔接条件的变更都应走此路径。
本节产出为阶段衔接条件清单与评审放行规则，清单中每条条件应包含：条件描述、判定方式、责任人、检查时点、未满足时的处理方式。
角色与交付物分工：谁对阶段计划负责
阶段计划需要明确的责任分配，否则容易出现计划编制后无人维护、评审组织临时找人、变更无人审批的情况。
项目经理对阶段计划的整体编制与维护负责，包括组织边界划分、汇总交付安排、跟踪衔接条件满足情况、发起计划变更。技术负责人对阶段技术交付物的内容质量和评审标准负责，参与设计、开发、测试阶段的边界判断。质量角色对评审过程与完成标志的判定规则负责，检查交付物是否符合约定标准。业务方对需求类交付物和验收结论负责，参与相关阶段评审并签署确认。
阶段计划文档的编制由项目经理牵头，技术负责人和业务方参与评审，评审通过后基线化。基线化的意义是形成可对比的基准，后续变更可追溯。阶段评审由项目经理组织，决策者按评审事项确定：技术事项由技术负责人决策，业务验收事项由业务方决策，跨阶段资源与范围事项升级至项目发起人。
计划变更的审批角色按影响范围区分：仅影响单阶段内部安排的变更，由项目经理审批；影响阶段边界或衔接条件的变更，由项目经理提出、技术负责人与业务方会签；影响项目整体目标或重大资源的变更，升级至项目发起人审批。
| 角色 | 阶段计划中的职责 | 主要产出 |
|---|---|---|
| 项目经理 | 编制与维护阶段计划，组织评审，跟踪衔接条件，发起变更 | 阶段计划文档、评审记录、变更记录 |
| 技术负责人 | 判断技术边界，确定技术交付物标准，参与评审决策 | 设计类交付物、技术评审意见 |
| 质量角色 | 检查完成标志判定规则，核查交付物符合性 | 检查记录、评审问题清单 |
| 业务方 | 确认需求与验收标准，参与阶段评审并签署 | 需求确认、验收结论 |
示例：一个新项目的瀑布阶段计划怎么落地
以下为演示情景：某内部管理系统新建项目，需求由业务部门提出，开发团队约十人，计划周期约四个月，涉及与既有系统的数据对接。示例仅用于说明方法，不代表特定行业或组织的标准做法。
阶段序列与边界：需求阶段，边界为需求规格通过评审；设计阶段，边界为设计评审通过且接口清单经上下游确认；开发阶段，边界为可运行版本在测试环境部署成功；测试阶段，边界为测试报告签署；上线阶段，边界为上线确认单签署。数据对接作为设计阶段内的专项工作，因其依赖外部系统排期，在设计阶段单独设接口联调检查点，未单独成阶段。
各阶段交付物与完成标志示例：需求阶段交付需求规格说明书和评审记录，完成标志为评审意见全部关闭或遗留项登记处理计划并由项目经理确认；设计阶段交付概要设计、接口设计和设计评审记录，完成标志为设计评审通过、接口清单由上下游双方签署；开发阶段交付可运行版本和单元测试记录，完成标志为测试环境部署成功、单元测试通过率达到计划值；测试阶段交付测试报告和缺陷清单，完成标志为用例执行完毕、遗留缺陷分级并有处理结论；上线阶段交付上线方案和上线确认单，完成标志为上线检查项全部通过、业务方签署。
衔接条件与评审放行示例：设计阶段退出条件为设计评审通过且接口清单确认，对应开发阶段准入条件为设计文档归档、接口清单可查、开发环境就绪。若接口清单中有一项待外部系统确认，评审结论为带条件放行，遗留项登记责任人和两周内关闭的时点，开发阶段可先开展不依赖该接口的工作。若设计评审发现关键方案未定，结论为返工，补充方案后重新评审。
在协作工具中的承载方式：阶段可对应项目计划中的工作分解结构节点，阶段交付物对应工作项及其完成状态，里程碑标记阶段评审和关键决策点，任务间设置前后置依赖表达衔接关系。阶段计划与里程碑设置基线后，可对比计划与执行的偏差；评审记录和阶段文档归档在项目文档中，与对应工作项关联。ONES的项目计划支持按交付物或项目阶段分解工作、设置任务依赖和里程碑，并支持计划与里程碑基线及变更对比，可作为承载上述内容的工具之一，具体配置以实际版本为准。
完成检查：阶段计划是否可执行
阶段计划编制完成后，用以下清单逐项检查。每项都应能给出明确答案，无法回答的项即为需要补充的内容。
- 边界检查：每个阶段边界是否落在可独立验收的成果或明确决策点上？是否存在仅按时间切分、阶段末说不清完成了什么的边界？
- 交付物检查：每个阶段是否列出了交付物清单，并区分文档、可运行版本、评审记录、验收结论等类型？
- 责任检查：每项交付物是否有负责人和评审人，且两者职责已区分？评审人是否在阶段开始前确定？
- 完成标志检查：每个阶段的完成标志是否可判定，是否包含检查方式、通过标准和确认人？是否存在“基本完成”这类模糊表述？
- 衔接条件检查：相邻阶段的退出条件与准入条件是否成对对应？每条条件是否有判定方式、责任人和检查时点？
- 评审规则检查：评审结论类型和放行规则是否明确？带条件放行、返工、暂缓各自的处理方式和决策人是否写明？
- 变更路径检查：阶段计划是否已基线化？变更的提交、影响评估、审批和记录路径是否明确？
- 里程碑检查：里程碑是否与阶段成果检查时点对齐？里程碑日期调整时是否有同步检查机制？
清单全部通过，阶段计划具备执行条件；存在未通过项时，优先补齐影响衔接判定的内容，再进入计划基线化。
常见问题
阶段数量定多少合适？阶段拆得太细或太粗分别有什么问题？
阶段数量以能管住关键风险为限，没有统一数字。判断依据是阶段内部工作的性质是否一致、是否存在必须单独决策的风险点。
拆得太细的代价是评审和文档成本上升，阶段之间的等待时间拉长，团队把精力花在走流程上；拆得太粗的代价是风险暴露晚，问题积累到后期才被发现，返工影响面更大。
可操作的取舍是：一个阶段内存在两种以上性质差异很大的工作，或存在一个必须单独决策的风险点，就考虑拆分；两个相邻阶段的交付物由同一批人连续完成、中间没有实质决策，就考虑合并。合并或拆分后，仍要保证每个阶段有可独立验收的成果。
需求在项目中途发生变化，阶段边界和衔接条件要不要跟着改？
要看变更影响的范围。仅影响单阶段内部任务安排的变更，由项目经理审批后更新计划即可；影响阶段边界、交付物或衔接条件的变更，应走变更路径：说明变更内容和原因、评估对交付物、工期、资源和后续阶段衔接条件的影响，由项目经理提出、技术负责人与业务方会签，再更新计划与基线并通知相关方。
需求变化频繁时，更根本的做法是回到阶段划分本身检查：如果需求阶段结束时需求仍不稳定，说明边界切在了成果尚不可验收的位置，应考虑在需求与设计之间增加原型验证或方案评审阶段，把不确定性集中在前段处理，而不是让变更一路穿透到开发和测试阶段。
“带条件放行”和“返工”怎么区分？遗留项多的时候容易混。
区分标准是遗留项是否影响下一阶段的主体工作。
带条件放行适用于主要条件已满足、遗留项不影响下一阶段主体推进的情形，例如接口清单中有一项待外部系统确认，开发阶段可以先做不依赖该接口的部分。放行时须登记遗留清单，写明责任人和关闭时点，并在下一阶段初期跟踪关闭。
返工适用于交付物质量不达标、关键条件未满足的情形，例如设计评审发现关键方案未定。返工范围和工作量应评估后更新计划，补充完成后重新评审，不能以带条件放行的名义绕过。
判断不清时，问一句：遗留项不解决，下一阶段的核心工作能否正常开展？能，走带条件放行；不能，走返工。
阶段计划基线化之后，日常执行中还需要维护哪些内容？
基线化形成的是可对比的基准，日常维护围绕偏差展开，主要包括三类动作。
- 跟踪衔接条件：按清单逐条核对判定方式、责任人和检查时点，临近阶段评审前确认条件满足情况，未满足的提前启动处理。
- 记录评审结论：每次阶段评审的结论类型、决策人和遗留项处理计划归档，与对应阶段的工作项关联，便于后续追溯。
- 管理变更：影响阶段边界或衔接条件的变更走审批路径，保留变更前后的对比记录，基线随之更新。
在ONES中，项目计划支持按交付物或项目阶段分解工作、设置任务依赖和里程碑，并支持计划与里程碑基线及变更对比，可作为承载阶段计划与偏差跟踪的工具之一，具体配置以实际版本为准。
小团队项目也要按这套方法写完整的阶段计划吗？
方法的核心是三件事：边界落在可验收成果上、交付物有责任人和完成标志、衔接条件可判定。这三件事与团队规模无关，但承载形式的详略可以调整。
小团队可以把阶段交付安排表和衔接条件清单合并成一份简表，评审会与阶段例会同场进行，评审记录从简但保留结论类型和遗留项处理计划。需要保留的是判定依据本身：完成标志不能退化成“做完了”，衔接条件不能退化成“没问题就往下走”。
项目规模扩大、外部依赖增多或涉及监管审查时，再补充独立的评审记录、变更审批层级和基线对比。组织级的流程制度设计属于另一层面的事项，不在单项目阶段计划的范围内。
