单项目该用瀑布还是混合管理，取决于需求与交付的不确定性、外部约束和变更成本，而非团队习惯。本文给出一张方法选择判定表，按阶段划分、阶段衔接、变更与评审机制、角色与交付物四个要素设计流程，并用一个混合模式示例和一份落地检查表，帮助你把方法结论变成可执行、可验证的安排。
要点总览（TL;DR）
- 方法选择先看四个维度：需求确定性、交付节奏与外部约束、变更成本、合规与验收要求，组合结果通常落到顺序式瀑布、阶段门控混合或局部迭代三类倾向。
- 选定方法后按四步落地：拆分阶段与里程碑并写明准出条件、定义阶段衔接评审与交接物、圈定迭代嵌入位置、设置统一变更入口与影响评估路径。
- 角色职责要分别写明：项目经理维护计划与变更入口，业务负责人确认需求基线与验收，技术负责人评估技术影响，质量角色执行准出检查；交付物统一存放并做版本管理。
- 用阶段准出一次通过率、变更回流次数、返工工时、里程碑偏差四项指标验证方法是否执行到位，连续两个周期无改善时按现象调整流程。
先判断项目特征：方法选择的四个判定维度
方法选择的起点是把项目特征说清楚，再映射到方法倾向。建议在项目启动会上，由项目经理与业务负责人共同填写下表，逐项给出取值，最后看组合结果。判定表的价值在于把“我觉得适合瀑布”变成有依据的共同判断，也便于后续复盘时回看当初的选择理由。
| 维度 | 判断问题 | 取值 | 对应方法倾向 |
|---|---|---|---|
| 需求确定性 | 核心需求是否已在启动前明确并可冻结？范围变化预计有多大？ | 高（需求清晰、范围稳定）／中（主干清晰、细节待定）／低（方向明确、内容待探索） | 高→顺序式瀑布；中→阶段门控混合；低→局部迭代或迭代为主 |
| 交付节奏与外部约束 | 是否存在固定的对外交付节点、合同节点或监管时限？节点之间能否分批交付？ | 强约束且不可分批／强约束可分批／弱约束 | 不可分批→瀑布；可分批→混合（按批次设里程碑）；弱约束→可增加迭代环节 |
| 变更成本 | 需求变更引发的返工范围有多大？是否涉及硬件、外部集成或已签署的验收标准？ | 高（变更牵动多环节）／中／低 | 高→前置评审与阶段门控；中→设变更入口与影响评估；低→迭代内消化 |
| 合规与验收要求 | 是否需要完整的阶段文档、评审记录与可追溯的验收证据？ | 强（需逐阶段留痕）／一般／弱 | 强→瀑布或阶段门控混合；一般→混合；弱→迭代为主，保留关键记录 |
四个维度组合后，通常落到三类倾向。第一类是顺序式瀑布：需求确定性高、外部节点不可分批、变更成本高、合规要求强，四个条件同时成立时，按阶段顺序推进最稳妥。第二类是阶段门控混合：整体按阶段推进并设准出评审，但在需求细化、设计验证或部分开发环节嵌入短周期迭代，适合需求主干清晰、细节需要边做边确认的项目。第三类是局部迭代：只在少数不确定性高的环节采用迭代，其余环节保持顺序交付。
填写时有两个操作要点。其一，每个维度只选一个主取值，避免“既高又低”导致结论模糊；若团队分歧明显，把分歧点写成待验证假设，在首个阶段结束时复核。其二，判定结论要写明理由和复核时间，例如“因验收需逐阶段留痕，采用阶段门控混合，三个月后按变更回流情况复核”。判定表不是一次性动作，项目特征变化时应重新评估。
核心操作步骤：从阶段划分到阶段衔接的流程设计
方法结论确定后，下一步是把它转成阶段结构和衔接机制。以下四步按顺序执行，每步都明确输入、负责人动作、输出物与完成标志，便于逐项核对。
步骤一：拆分阶段与里程碑
输入是判定表结论、项目目标与交付物清单。项目经理牵头，业务负责人和技术负责人参与，按目标、交付物或项目阶段维度拆分工作，形成阶段划分与里程碑安排。每个阶段要写清三件事：阶段目标、主要交付物、准出条件。准出条件是这一步的关键产出，它应当可核验，例如“需求基线经业务负责人签字确认”“设计说明通过技术评审并关闭全部阻断意见”。完成标志是阶段计划与里程碑清单经项目组确认并纳入版本管理。
步骤二：定义阶段衔接的评审与交接物
输入是阶段计划与各阶段交付物清单。项目经理组织定义每个阶段结束时的评审形式、参与角色和交接物，例如上一阶段向下一阶段移交需求基线、设计说明和遗留问题清单。交接物要明确责任人和接收人，避免出现“文档写了但没人确认”的断档。完成标志是每个阶段边界都有对应的评审安排和交接物清单，且已排入项目日历。
步骤三：确定迭代环节的嵌入位置
混合模式的关键是分清哪些环节迭代推进、哪些保持顺序交付。通常把需求细化、方案验证、部分开发与测试环节设为迭代推进，把立项、基线确认、验收交付等环节保持顺序推进。输入是判定表中需求确定性与变更成本的取值；项目经理与业务负责人共同圈定迭代范围，并说明每个迭代的周期与产出。完成标志是形成一张“环节—推进方式—产出”对照表，团队对边界无异议。
步骤四：设置变更入口与影响评估路径
输入是变更成本判断与阶段准出条件。项目经理设定统一的变更入口，明确谁可以提变更、由谁评估影响、评估结论如何进入计划调整。影响评估至少覆盖范围、进度、成本与已完成的评审记录。完成标志是变更入口在项目内公布，且首条变更按该路径完整走通一次，形成可参照的记录。
| 步骤 | 输入 | 负责人动作 | 输出物 | 完成标志 |
|---|---|---|---|---|
| 拆分阶段与里程碑 | 判定表结论、项目目标、交付物清单 | 项目经理牵头拆分阶段，定义目标与准出条件 | 阶段计划、里程碑清单、准出条件 | 计划经项目组确认并纳入版本管理 |
| 定义衔接评审与交接物 | 阶段计划、交付物清单 | 组织确定评审形式、参与角色、交接物 | 阶段评审安排、交接物清单 | 每个阶段边界均有评审与交接安排 |
| 确定迭代嵌入位置 | 需求确定性、变更成本取值 | 圈定迭代范围与周期 | 环节—推进方式—产出对照表 | 团队对迭代边界达成一致 |
| 设置变更入口 | 变更成本判断、准出条件 | 设定入口、评估责任人与路径 | 变更流程说明、首条变更记录 | 首条变更按路径完整走通 |
阶段、里程碑与交付物确定后，需要在协作工具中承载，否则计划与执行容易脱节。ONES 支持用项目计划创建工作分解结构，按目标、交付物或项目阶段维度分解工作，为任务设置前后置依赖，并用里程碑标记重要时间点与决策点；设置计划与里程碑基线后，可对比计划与执行的偏差，并通过版本对比追溯变更细节。混合模式下，项目经理还可以在项目计划中关联迭代和研发任务，把顺序推进的阶段与迭代环节放在同一视图中掌握进度。
角色分工与各阶段交付物
方法能否落地，很大程度取决于职责边界是否清楚。下表列出四类核心角色在方法选择与执行中的职责，团队规模较小时可由一人兼任，但职责要分别写明。
| 角色 | 方法选择阶段职责 | 执行阶段职责 |
|---|---|---|
| 项目经理 | 组织填写判定表，汇总维度取值，提出方法建议 | 维护阶段计划与里程碑，组织阶段评审，管理变更入口，跟踪偏差 |
| 业务负责人 | 确认需求确定性与验收要求，参与方法结论确认 | 确认需求基线，参与阶段准出评审，对范围变更提出业务意见 |
| 技术负责人 | 评估变更成本与技术可行性，判断哪些环节适合迭代 | 组织技术方案评审，把控迭代内技术产出质量，评估变更的技术影响 |
| 质量与评审角色 | 提出合规与验收证据要求，明确评审标准 | 执行阶段准出检查，核对交付物完整性，记录评审结论 |
阶段准出评审建议采用“评审人独立给出结论、项目经理汇总”的方式：参与角色包括项目经理、业务负责人、技术负责人和质量角色，结论分为通过、有条件通过、不通过三类。有条件通过须列明待关闭事项、责任人和关闭时间，未关闭事项带入下一阶段跟踪。决策方式在项目启动时写清，避免评审现场临时约定。
各阶段应产出的交付物至少包括：阶段计划与里程碑清单、需求基线、设计说明、测试与验收记录、变更记录。交付物管理有两条要求：一是统一存放位置，项目成员按同一入口查找，避免多处分发造成版本混乱；二是版本管理，需求基线与计划基线在确认后锁定版本，后续修改以新版本记录并注明变更原因。ONES 提供敏捷、瀑布、通用任务协同等多种项目模板，并可灵活定义项目类型与相关组件，便于把上述交付物与阶段结构对应起来管理。
示例：一个混合模式项目的阶段设计
以下为演示情景，用于说明判定结论如何落到阶段安排，不代表真实客户案例。
某企业内部系统升级项目，需在年底前完成上线以配合年度结算，验收要求保留完整的阶段评审记录；核心业务流程已明确，但部分报表与权限细节需在开发中确认。判定表填写结果为：需求确定性中，交付节奏为强约束可分批，变更成本中，合规要求强。组合结论为阶段门控混合：整体按阶段推进并设准出评审，在需求细化与开发测试环节嵌入两周迭代。
据此确定的阶段划分为：启动与需求基线、方案设计、开发与测试、验收与上线。里程碑设在需求基线确认、设计评审通过、测试完成、上线四个节点。需求细化与开发测试采用迭代推进，每两周产出可评审的需求说明或可测试功能；启动、设计评审、验收上线保持顺序交付，按准出条件逐项确认。
阶段衔接上，需求基线确认后向设计阶段移交需求说明与遗留问题清单；设计评审通过后向开发阶段移交设计说明与接口约定。变更处理上，所有变更从统一入口登记，由项目经理组织业务与技术双方评估影响，评估结论进入下一迭代或调整阶段计划，并在变更记录中留痕。该示例的适用边界是：需求主干清晰、存在固定对外节点、需要阶段留痕的项目；若需求方向本身不确定，应提高迭代比重；若变更成本极高且验收标准已锁定，应减少迭代环节、强化阶段门控。实际执行时，阶段数量与迭代周期需按项目规模和团队节奏调整。
完成检查：方法是否落地的验证项
方法执行一段时间后，用以下检查项逐条核对，判断流程是否真正运转，而不只是写在文档里。
- 每个阶段的准出条件是否被实际执行，并有评审记录与结论；
- 阶段衔接评审是否按计划发生，交接物是否齐全并经接收人确认；
- 变更是否全部经统一入口登记，是否完成影响评估并留下记录；
- 迭代环节的产出是否按周期交付，顺序环节是否按里程碑推进；
- 计划基线是否建立，偏差是否有跟踪与说明。
验证指标建议按统一口径统计：阶段准出一次通过率，即首次评审即通过的阶段数占已评审阶段数的比例；变更回流次数，即同一变更因评估不足被退回重评的次数；返工工时，即因衔接断档或需求不清导致的重复工作量；里程碑偏差，即实际完成时间与基线时间的差值。指标按月或按阶段统计，连续两个周期无改善时，按下表方向调整。
| 现象 | 可能原因 | 调整方向 |
|---|---|---|
| 阶段准出一次通过率低 | 准出条件模糊或评审标准不一致 | 细化准出条件，统一评审检查项 |
| 变更回流次数多 | 影响评估缺少技术或业务一方参与 | 补全评估角色，明确评估输出模板 |
| 返工工时偏高 | 阶段交接物不完整或未确认 | 强化交接物清单与接收确认 |
| 里程碑偏差持续扩大 | 迭代范围过大或阶段依赖未理清 | 缩小迭代范围，复核任务前后置依赖 |
检查结果应回到方法选择本身：若偏差主要来自需求不确定性被低估，可提高迭代比重；若来自合规留痕不足，则强化阶段门控与记录要求。方法服务于项目目标，按证据调整比坚持初始选择更有价值。
常见问题
项目进行到一半发现需求不确定性被低估，还能从瀑布切换到混合模式吗？
可以，但切换要有依据和边界。先回看判定表中需求确定性与变更成本的取值，确认偏差来自需求本身变化，而非执行不力。切换时保留已完成的阶段成果与评审记录，把尚未开始或刚开始的环节改为迭代推进，并重新确认阶段准出条件与里程碑基线。已经锁定的验收标准和对外节点保持不变，避免切换方法影响合同承诺。
团队规模较小、一人兼任多个角色时，阶段准出评审怎么保证有效性？
兼任可以，但职责要分别写明，评审结论要独立给出。小团队常见的做法是：项目经理汇总结论，业务与技术角色分别从需求和技术角度给出意见，质量检查项由非本阶段主要执行人核对。若确实无人可独立评审，可引入上级或相邻团队人员参与关键阶段评审。评审记录中写明每个结论的给出人，避免一人既做又评导致检查流于形式。
混合模式中迭代环节的周期应该定多长？
周期取决于迭代环节要产出的可评审物和团队协作节奏，没有统一标准。常见做法是让每个迭代结束时能产出可评审的需求说明或可测试功能，周期与阶段里程碑对齐，避免迭代结束时间落在阶段评审之后。周期过长会削弱迭代的反馈价值，过短则增加评审开销。建议在首个阶段结束后按实际产出情况调整一次，并写入项目计划。
变更入口设好后，紧急变更来不及走完整评估怎么办？
可以设紧急通道，但事后补评估不能省。做法是在变更入口中区分常规与紧急两类：紧急变更由项目经理与技术负责人先行判断影响范围并记录，允许先执行，随后在约定时间内补齐业务意见与完整影响评估，评估结论进入变更记录。紧急通道的使用次数应纳入检查项，频繁使用说明前置评估或需求基线存在问题，需要回头复核方法选择与阶段准出条件。
阶段、里程碑和交付物在协作工具中怎么承载，才能让计划和执行对得上？
关键是让计划结构、交付物和变更记录放在同一处管理。ONES 支持用项目计划创建工作分解结构，按目标、交付物或项目阶段维度分解工作，为任务设置前后置依赖，并用里程碑标记重要时间点与决策点；设置计划与里程碑基线后可对比计划与执行的偏差，通过版本对比追溯变更细节。混合模式下还可在项目计划中关联迭代和研发任务，把顺序推进的阶段与迭代环节放在同一视图中掌握进度。
