瀑布项目的阶段划分，需要同时满足计划可控和交付可验收两个要求。比较实用的做法是依据六类因素确定切分方向：交付物形态、技术不确定性、评审与决策节点、外部依赖与合规要求、资源与组织边界、风险集中度。再按“可独立评审、可独立验收、可交接”的标准切出阶段，为每个阶段写明输入、输出、完成标志和准入条件。本文面向新项目启动时制定阶段计划的场景，给出一套可直接套用的判断规则、衔接条件表和检查清单。
要点总览（TL;DR）
- 瀑布阶段划分可依据六类因素：交付物形态、技术不确定性、评审与决策节点、外部依赖与合规要求、资源与组织边界、风险集中度，实际使用时组合判断。
- 阶段边界用三项标准检验：成果可独立评审、可独立验收、可交接给下一角色；只满足一两项时，该节点更适合作为阶段内里程碑。
- 每个阶段写明输入、交付物及形式、完成标志、评审方式和下一阶段准入条件，交付物控制在三到五项，避免阶段过粗或过细。
- 阶段衔接条件写成“谁在什么材料上确认什么结论”，交付物责任人与评审责任人明确到人，变更按提出、评估、批准、回写计划的路径处理。
- 阶段计划完成后用检查清单逐项核对，确认边界对应可评审成果、衔接条件可验证、风险与外部依赖已落到具体阶段。
阶段划分的六类依据因素
阶段划分不是把工期平均切成几段，而是找到项目中自然存在的“完成—确认—交接”节点。下面六类因素分别回答不同问题，实际使用时通常需要组合判断：先看交付物能否分解，再看技术验证和决策节点落在哪里，最后用依赖、组织和风险修正边界。
| 因素 | 判断问题 | 对阶段切分的影响 |
|---|---|---|
| 交付物形态与可分解性 | 最终交付物由哪些可独立描述的组成部分构成？各部分能否单独评审？ | 交付物本身分层清晰时，可按组成部件或文档集划分阶段；交付物高度耦合时，阶段宜围绕一次完整交付设置，避免把同一交付物拆到多个阶段反复返工。 |
| 技术不确定性与验证需求 | 哪些技术方案需要先验证才能进入大规模实施？验证结果会影响后续设计吗？ | 存在关键技术选型或可行性验证时，应单独设置验证或方案确认阶段，把验证结论作为后续阶段的准入条件。 |
| 评审与决策节点 | 哪些节点需要客户、管理层或技术委员会做出正式确认？ | 每个需要正式决策的位置都应成为阶段边界，决策所需材料即该阶段的交付物，决策结论即下一阶段的准入依据。 |
| 外部依赖与合规要求 | 是否存在供应商交付、第三方接口、审批许可或合规检查？ | 外部依赖的到位时间决定阶段顺序；合规检查通常需要独立阶段或在阶段末设置专项评审，不能与内部开发混在一起。 |
| 资源与组织边界 | 阶段之间是否发生团队交接、外包转自研、跨部门移交？ | 组织交接点适合作为阶段边界，交接需要明确的交付物清单和接收确认，否则责任容易在交接处断档。 |
| 风险集中度 | 哪些工作失败概率高或失败影响大？风险是否集中在某一段？ | 高风险工作宜前置并单独成段，尽早暴露问题；风险分散且相互独立时，可合并为同一阶段并行推进。 |
六类因素出现冲突时，优先级通常是：合规与外部依赖决定硬边界，评审决策节点决定正式边界，技术不确定性和风险决定是否需要增加前置阶段，交付物形态和资源边界决定阶段内部如何组织。举例来说，某项目交付物可以按模块拆分，但客户只在整体上线前做一次验收，那么模块拆分适合作为阶段内的工作包，阶段边界仍应设在客户验收点。
如何确定阶段边界与阶段交付安排
把因素转成阶段，核心动作是逐个候选边界做三项检验：该边界上的成果能否独立评审、能否独立验收、能否交接给下一角色继续工作。三项都成立，边界可以成立；只成立一两项，说明该节点更适合作为阶段内的里程碑，而不是阶段边界。
边界判定规则
- 可独立评审：边界上有一份完整材料，评审人能据此判断工作是否达到预期，不需要等后续工作完成才能评价。
- 可独立验收：边界成果有明确的验收标准，验收方可以签字确认，确认后原则上不因后续阶段工作而推翻。
- 可交接：下一角色拿到边界交付物后可以开始工作，所需信息、环境和权限在交接时已经具备。
阶段交付物的粒度与形式
阶段交付物应写成“对象＋状态”，例如“需求规格说明书，已通过客户评审并完成签署”，而不是只写“需求文档”。交付物形式按阶段性质选择：方案类阶段以文档和评审记录为主，开发类阶段以可运行版本和测试报告为主，上线类阶段以部署记录、验收单和移交清单为主。每个阶段交付物控制在三到五项，超出说明该阶段承担了过多目标，应考虑拆分或把部分内容降为阶段内里程碑。
阶段数量与粒度的权衡
阶段过粗的典型表现是：一个阶段持续数月，期间没有可评审成果，问题到阶段末才暴露。阶段过细的表现是：每个阶段只有几天，评审会频繁召开但每次决策内容很少，团队大量时间用于准备评审材料。判断方法可以看两条：一是每个阶段是否至少有一项对项目走向有实质影响的决策或验收；二是相邻两个阶段的交付物是否明显不同。若相邻阶段交付物几乎一样，通常可以合并。
阶段交付物清单可按以下结构填写：阶段名称、阶段目标（一句话）、输入（上一阶段交付物及外部条件）、主要工作、交付物及形式、完成标志、评审方式、下一阶段准入条件。这份清单在项目启动会上确认，后续变更按阶段衔接规则处理。
阶段间衔接条件与角色分工
阶段划分能否执行，取决于阶段之间的门是否关得住。每个阶段结束时需要同时定义两组条件：本阶段的准出条件，即交付物达到什么状态才算完成；下一阶段的准入条件，即哪些前提具备后才能启动。两组条件应可验证，写成“谁在什么材料上确认什么结论”，避免“基本完成”“大致具备”这类无法核对的表述。
| 衔接要素 | 写法要求 | 示例 |
|---|---|---|
| 准出条件 | 交付物名称＋完成状态＋确认人 | 概要设计说明书完成内部评审，架构负责人签署评审结论 |
| 准入条件 | 前置交付物＋外部前提＋启动确认 | 客户确认需求基线；测试环境就绪；项目经理确认后启动开发阶段 |
| 评审方式 | 评审类型、参与角色、决策规则 | 阶段评审会，客户代表、项目经理、技术负责人参加，重大问题需书面闭环后方可通过 |
| 变更处理 | 变更提出、评估、批准、回写计划 | 阶段内变更由项目经理评估影响，涉及范围或验收标准的变更提交变更控制负责人批准，批准后更新阶段计划与基线 |
角色分工按“交付物责任＋评审责任”两条线对应。交付物责任人是该阶段成果的直接负责人，负责按标准完成并提交评审；评审责任人对准出结论签字，对结论负责；项目经理负责组织衔接、跟踪准入条件、处理变更；客户或业务代表在涉及需求确认和验收的阶段承担确认职责。同一人可以在不同阶段承担不同角色，但每个阶段的交付物责任人和评审责任人应明确到人，不能只写部门。
在工具层面，阶段计划、交付物和评审节点需要落在同一处，避免计划表与评审记录分离。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点、事件或决策点；设置计划和里程碑基线后，可对比计划与执行的偏差并追溯变更细节。这类能力适合承载阶段边界、衔接条件和变更记录，具体模板配置以实际产品为准。
示例：一个系统建设项目的阶段划分
以下为演示情景，用于说明因素如何落到阶段和衔接条件，不代表真实项目。某企业启动一套业务系统建设项目，最终交付物包括需求规格说明书、系统设计文档、可运行系统、测试报告、上线部署记录和验收报告。外部依赖包括第三方接口联调窗口和客户方的数据迁移配合；合规方面需要在设计完成后进行一次安全评审；开发团队与实施团队分属两个部门，存在交接。
| 阶段 | 边界理由 | 主要交付物 | 完成标志 |
|---|---|---|---|
| 需求与方案确认 | 需求是后续所有工作的输入，客户需要正式确认；技术选型存在不确定性，需在此阶段完成可行性验证 | 需求规格说明书、技术方案说明、可行性验证结论 | 客户签署需求基线；技术方案通过内部评审 |
| 设计 | 设计成果需要独立评审，安全评审也安排在此阶段末，形成合规检查点 | 系统设计文档、安全评审记录 | 设计评审通过；安全问题闭环 |
| 开发与内部测试 | 开发团队在此阶段完成主体工作，阶段末向实施团队交接可运行版本 | 可运行系统版本、内部测试报告、交接清单 | 内部测试通过率达到约定标准；实施团队签收交接清单 |
| 联调与验收准备 | 第三方接口联调依赖外部窗口，需单独成段管理；验收材料在此阶段汇总 | 联调记录、用户验收测试方案、验收材料包 | 联调问题闭环；验收方案经客户确认 |
| 上线与验收 | 上线和验收是客户决策节点，也是项目收尾的正式边界 | 部署记录、验收报告、移交文档 | 客户签署验收报告；运维移交完成 |
衔接条件的具体写法示例：开发与内部测试阶段的准出条件为“可运行系统版本部署至测试环境，内部测试报告完成且遗留问题均有处理结论，实施团队签收交接清单”；联调与验收准备阶段的准入条件为“交接清单已签收，第三方接口联调窗口已确认，联调环境就绪”。变更处理上，若联调中发现接口协议需要调整，由项目经理评估对设计和开发工作的影响，涉及验收标准变化的提交客户确认，确认后更新阶段计划并记录基线变更。
阶段计划完成检查
阶段计划初稿完成后，用下面这份清单逐项核对。每一项都应有明确答案，答不上来的条目就是计划需要补充的地方。
| 检查项 | 核对标准 | 通过标志 |
|---|---|---|
| 阶段输入、输出与完成标志 | 每个阶段都写明输入来源、交付物和完成标志 | 完成标志可被第三方核对，不依赖主观判断 |
| 边界对应可评审交付物 | 每个阶段边界上都有一份可独立评审的成果 | 评审人能仅凭该成果判断阶段是否完成 |
| 衔接条件可验证 | 准出与准入条件写成具体材料、确认人和结论 | 条件满足与否可由他人复核 |
| 风险与外部依赖落位 | 已识别的高风险工作和外部依赖都归入具体阶段，并有应对安排 | 没有“悬空”的依赖或无人负责的风险 |
| 角色责任清晰 | 每个阶段的交付物责任人和评审责任人明确到人 | 交接点有签收或确认动作 |
| 阶段粒度合理 | 相邻阶段交付物有明显区别，每个阶段至少包含一项实质决策或验收 | 不存在长期无评审成果的阶段，也不存在交付物重复的碎阶段 |
| 变更路径明确 | 阶段内和阶段间的变更都有提出、评估、批准和回写计划的路径 | 变更批准后能更新阶段计划与基线 |
检查通过后，阶段计划即可作为项目启动的基准版本发布，并在执行中按衔接条件逐段确认。阶段划分本身也可以在项目复盘中修订，但修订应通过变更流程回写计划，保持计划、交付物和评审记录一致。
常见问题
项目需求在启动时只能确认一部分，阶段划分还能按瀑布方式做吗？
可以，但需要把不确定性显式放进阶段结构。做法是在正式开发阶段之前设置方案确认或可行性验证阶段，把待确认的需求和技术选型集中在该阶段解决，并把验证结论作为后续阶段的准入条件。这样阶段边界仍然清晰，同时为需求变化留出了正式的处理位置。如果需求不确定性长期无法收敛，说明项目更适合迭代式方法，阶段划分本身解决不了这个问题。
阶段评审会上各方意见不一致，阶段能否算通过？
这取决于评审规则是否在阶段计划中事先写明。建议在阶段计划里定义决策方式，例如由评审责任人综合各方意见给出结论，重大问题需书面闭环后才可通过。意见不一致时，把分歧记录为待办事项并明确责任人和关闭时间，避免阶段在未确认的状态下直接进入下一阶段。规则事先约定，评审现场才有可执行的判断依据。
阶段执行中发现上一阶段的交付物有遗漏，应该回到上一阶段还是在本阶段补？
先评估遗漏对当前阶段工作的影响范围。如果遗漏影响当前阶段的核心输入，应暂停相关工作，按变更流程补充上一阶段交付物并重新确认，再恢复当前阶段；如果影响有限，可以在当前阶段内补充，但需记录在案并同步给上一阶段的评审责任人。关键是让补充动作进入计划和变更记录，避免交付物与计划脱节。
阶段数量多好还是少好，有没有参考标准？
没有统一的数量标准，判断依据是每个阶段是否至少包含一项对项目走向有实质影响的决策或验收，以及相邻阶段的交付物是否明显不同。相邻阶段交付物几乎一样时通常可以合并；一个阶段持续数月且期间没有可评审成果时，应考虑拆分。阶段数量最终由项目的交付物结构、决策节点和外部依赖决定。
阶段计划和评审记录分散在不同表格里，怎么保持衔接条件可追溯？
把阶段计划、交付物和评审节点放在同一处管理，可以减少计划与记录脱节。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点、事件或决策点；设置计划和里程碑基线后，可对比计划与执行的偏差并追溯变更细节。具体模板配置以实际产品为准。
