混合管理阶段规则要解决的是同一项目里瀑布与敏捷如何分段共存的问题。本文用一个虚构的示例项目，给出一份已填写的阶段划分与关卡表，逐项说明字段填写理由，并提炼换项目时的调整顺序与适用边界。
要点总览（TL;DR）
- 混合管理阶段规则的核心是一张阶段规则表：每个阶段声明管理方式、进入条件、关键交付物、评审关卡和变更处理，阶段交界处用关卡评审决定是否放行。
- 阶段按交付物形态切分，不按日历时间切分；示例分需求定义、方案设计、迭代开发、验收上线四段，前两段和最后一段计划驱动，开发段迭代驱动。
- 判断某阶段用计划驱动还是迭代驱动，看需求明确度、节点外部约束和阶段内变更频率三项，取主导因素。
- 换项目时按“先列交付物、再定阶段、再标方式、再设关卡、最后写变更规则”的顺序调整，阶段数量一般控制在四到六个。
- 这套规则面向单项目方法组合；纯瀑布或纯敏捷项目无需混合规则，组织级流程制度和强监管外部验收节点需另行设计。
示例目标：这份阶段规则要解决什么问题
先交代示例情景。以下背景为演示用途，不代表任何真实客户实践：某企业计划上线一套内部业务系统，项目周期约五个月，由一名项目经理、一名产品负责人、六名研发与测试人员组成。项目前半段需要完成需求确认与方案设计，后半段进入功能开发与验收上线。客户方对上线时间有明确要求，但部分功能细节在启动时尚未完全确定。
这个情景集中暴露了混合管理中常见的三类问题。
- 阶段边界不清。需求、设计、开发、验收混在一起推进，团队说不清当前处于哪个阶段，也无法判断某个交付物是否已经完成。结果是评审没有对象，进度汇报只能凭感觉。
- 方法混用无规则。有人按瀑布方式要求先写全文档再开发，有人按敏捷方式直接拉迭代，两种节奏互相干扰。方法选择取决于个人习惯，缺少统一声明。
- 关卡评审缺失。阶段之间没有正式的检查点，问题被带到下一阶段才暴露，变更也没有统一的处理入口。
针对这三类问题，示例要产出两件东西：一张阶段规则表，固定每个阶段的划分、管理方式、进入条件、交付物、关卡与变更处理；一份关卡清单，明确每个交界处评审什么、由谁评审、评审结论如何影响后续阶段。规则表回答“怎么分段、每段怎么管”，关卡清单回答“段与段之间怎么交接”。
完整示例：一个项目的混合阶段规则表
下表为示例数据，阶段名称、交付物与评审角色均可按实际项目替换。四个阶段按交付物形态划分，前两个阶段偏计划驱动，第三个阶段偏迭代驱动，最后一个阶段回到计划驱动。
| 阶段 | 管理方式 | 进入条件 | 关键交付物 | 评审关卡 | 阶段内变更处理 |
|---|---|---|---|---|---|
| 一、需求定义 | 计划驱动 | 项目立项通过，产品负责人与业务方到位 | 需求规格说明、需求优先级清单、验收标准初稿 | 需求基线评审：业务方确认范围，形成需求基线 | 变更走需求变更申请，评估对范围与工期的影响后更新基线 |
| 二、方案设计 | 计划驱动 | 需求基线已确认 | 技术方案文档、接口定义、测试方案、排期计划 | 设计评审：技术负责人确认方案可行，测试负责人确认可测性 | 设计变更需说明对已确认需求的影响，重大调整回到需求基线复核 |
| 三、迭代开发 | 迭代驱动 | 设计评审通过，迭代待办已拆分到可开发粒度 | 每个迭代可运行的功能增量、迭代评审记录、缺陷清单 | 迭代评审与阶段出口评审：功能增量通过验收标准，遗留缺陷有明确处理计划 | 迭代内变更在迭代边界统一吸收；影响范围超出当前迭代的，提交阶段出口评审决定 |
| 四、验收上线 | 计划驱动 | 阶段出口评审通过，遗留缺陷达到可上线标准 | 验收报告、上线方案、回滚预案、用户操作手册 | 上线评审：业务方、技术负责人、运维共同确认上线条件 | 上线前变更走上线评审；上线后问题按回滚预案处理并记录 |
配套的关卡清单按阶段交界处逐条列出，示例包含三个关卡：
- 需求基线评审（阶段一至阶段二）。核对需求规格说明是否覆盖业务方确认的范围，验收标准是否可验证，遗留待定项是否已登记并指定负责人。结论为通过、有条件通过或不通过，有条件通过需列出关闭条件与期限。
- 设计评审（阶段二至阶段三）。核对技术方案与需求基线的一致性、接口定义是否完整、测试方案是否覆盖关键验收标准。评审通过后，迭代待办才允许进入开发。
- 阶段出口评审（阶段三至阶段四）。核对功能增量是否达到验收标准、遗留缺陷的数量与严重程度、下一阶段上线方案是否就绪。此关卡同时确认验收上线阶段是否需要调整计划。
跨阶段变更的处理原则写在规则表之外、作为表的附注：任何跨越阶段边界的变更，都回到最近一个关卡重新确认，不在阶段内部自行消化。这样做的目的是让方法切换点与决策点重合，避免阶段方式已经改变而评审还停留在旧口径上。
逐项解释：每个字段为什么这样填
阶段边界为什么按交付物切分
示例按“需求规格说明—技术方案—功能增量—验收报告”这条交付物链条划分阶段，没有按“第一个月做什么、第二个月做什么”来切。原因在于关卡评审需要一个可检查的对象：交付物是否达标可以逐条核对，时间节点是否到达只能说明日历翻页。按交付物切分后，阶段边界天然就是交接点，评审有据可依，责任也容易落到具体角色。
按时间切分还会带来一个副作用：当某个阶段提前或延后完成时，整张表的时间假设失效，规则需要频繁重写。按交付物切分则不受日历影响，阶段顺序保持稳定。
哪些阶段用计划驱动，哪些用迭代驱动
判断依据可以归纳为三点：需求是否已明确到可排期、交付节点是否被外部约束固定、阶段内变更的频率与影响范围。
- 需求定义阶段面对的是尚未收敛的范围，但它的产出是一份需要业务方签字确认的基线文档，交付形态是确定的，因此采用计划驱动，用评审把关范围收敛。
- 方案设计阶段同理，技术方案与接口定义需要一次性确认，返工成本高，适合计划驱动。
- 迭代开发阶段的需求已经拆到可开发粒度，但实现细节和优先级仍会随反馈调整，变更频率高且影响多局限在单个迭代内，适合迭代驱动，用迭代边界吸收变更。
- 验收上线阶段的节点由业务方和运维窗口固定，动作序列明确，回到计划驱动更便于控制。
这三点判断不要求全部满足才选某种方式，而是看主导因素。需求明确、节点固定占主导时偏计划驱动；需求待探索、需要多轮反馈占主导时偏迭代驱动。
进入条件与关卡评审为什么成对设置
规则表中每个阶段都同时有进入条件和评审关卡，两者是一对：上一个阶段的关卡评审结论，就是下一个阶段的进入条件。这样设计让关卡不只是“检查”，而是“放行”动作，评审不通过时下一阶段无法启动，规则才有约束力。
进入条件写得具体，评审才有可操作性。示例中“设计评审通过，迭代待办已拆分到可开发粒度”比“设计完成”更可核验，因为它指向了具体的状态和产物。
变更处理为什么随阶段方式变化
计划驱动阶段的变更走申请与基线对比，是因为这类阶段的产出已经过正式确认，变更需要留下影响评估记录；迭代驱动阶段的变更在迭代边界统一吸收，是因为迭代本身就是变更的容器，逐条审批会拖慢节奏。跨阶段变更单独回到关卡处理，则是因为它同时影响交付物和方法选择，超出单个阶段的处理权限。
规则表确定后，落地时需要让阶段与关卡在协作工具中有对应的承载。以 ONES 为例，可以用项目计划按交付物或项目阶段维度分解工作、设置任务前后置依赖，用里程碑标记关卡评审这类决策点；设置计划与里程碑基线后，可对比计划与执行的偏差并追溯变更细节；迭代开发阶段则可在项目计划中关联迭代与研发任务，掌握研发进度。ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并支持按业务需求定义项目类型与相关组件，便于把上述阶段规则配置成项目结构。具体配置方式需结合团队实际流程确认。
可迁移规律：换一个项目怎么改这张表
换项目时，建议按以下顺序调整，每一步都有明确的完成标志。
- 先列交付物，再定阶段。把项目最终要交出的东西和中间必须确认的产物列出来，相邻两个交付物之间就是一个阶段。完成标志：每个阶段都能说出“交出什么才算完成”。
- 给每个阶段标注管理方式。用需求明确度、节点约束、变更频率三项逐一判断，在表中写明计划驱动或迭代驱动，并附一句判断理由。完成标志：没有阶段处于“方式待定”状态。
- 设置关卡并写清评审内容。在每个阶段交界处设一个关卡，列出评审项、评审角色和结论类型。阶段数量一般控制在四到六个，关卡过密会增加协调成本，过疏则问题暴露太晚。完成标志：每个关卡都有可核对的评审项清单。
- 写变更规则。分别写明阶段内变更和跨阶段变更的处理路径，并与该阶段的管理方式对应。完成标志：任何一类变更都能在表中找到处理入口。
- 与项目计划和看板衔接。把阶段与关卡映射到项目计划的结构、里程碑和任务状态上，迭代驱动阶段映射到迭代与看板。完成标志：团队在工具中能看到当前阶段和下一个关卡。
- 约定维护方式。规则表不是一次定死的文件，阶段调整、关卡增减都应更新表格并保留变更记录，评审记录与规则版本对应。完成标志：规则表有明确的更新责任人和更新时机。
调整时优先改动交付物和阶段划分，这两项确定后，管理方式与关卡通常随之明确。反过来先定方法再凑阶段，容易出现阶段边界与方法不匹配的情况。
适用边界：哪些情况不适合这套阶段规则
这套规则面向单项目层面的方法组合，帮助项目团队把阶段、方式、关卡和变更写成一份可执行的约定。以下情况需要区别对待。
| 情况 | 是否适用 | 说明 |
|---|---|---|
| 单项目内瀑布与敏捷分段共存 | 适用 | 本文示例的直接适用场景 |
| 需要替代组织级研发流程制度 | 不适用 | 组织级制度涉及多项目协同、角色权限与合规要求，需单独设计 |
| 纯瀑布或纯敏捷项目 | 无需混合规则 | 单一方法项目按对应方法管理即可，增加阶段规则反而增加负担 |
| 强监管、外部验收节点固定的项目 | 需额外约束 | 外部验收节点应作为硬关卡写入规则，并补充合规检查项，不能只依赖项目内部评审 |
| 需求与范围在项目中途大幅变化 | 需重新评估 | 阶段划分依赖交付物稳定，范围剧变时应先重定交付物，再调整规则表 |
还有一点需要说明：规则表需要随项目实际调整。示例中的阶段数量、关卡密度和变更路径都是一般实践下的建议值，不是统一标准。项目进入执行后，如果发现某个关卡长期没有实质评审内容，可以合并或简化；如果某类变更反复绕过关卡，说明规则与实际不符，应修改规则而不是默许例外。规则变更时同步更新阶段规则表与关卡清单，并保留变更记录，才能让这套约定持续可用。
常见问题
阶段规则表和项目计划、任务看板之间是什么关系？
规则表是约定层，项目计划和看板是执行层。规则表确定阶段、关卡和变更路径后，需要把这些结构映射到日常协作工具中：阶段对应计划的分组维度，关卡对应里程碑或评审节点，迭代驱动阶段对应迭代与看板。映射完成后，团队在工具里就能看到当前处于哪个阶段、下一个关卡是什么。如果规则表只停留在文档里而没有落到计划结构上，阶段边界很快会重新模糊。
关卡评审长期没有实质内容，可以取消吗？
可以先判断原因再决定。如果该关卡对应的交付物本身已经简化，评审项确实没有可核对的内容，可以合并到相邻关卡，并同步更新规则表。如果评审项仍然存在但没人认真执行，问题出在执行而非规则设计，取消关卡只会让问题更晚暴露。判断标准是：这个关卡是否还在拦截真实的风险。规则表允许调整，调整后保留变更记录即可。
项目中途需求范围大幅变化，阶段规则表要怎么处理？
阶段划分依赖交付物相对稳定，范围剧变时应先重定交付物清单，再调整阶段和关卡，最后才改管理方式标注。顺序反过来容易出现阶段边界与方法不匹配。如果变化只影响某个阶段内部的优先级，按该阶段的变更规则处理即可；如果变化跨越阶段边界，回到最近一个关卡重新确认后续安排，这也是示例中跨阶段变更的处理原则。
外部验收节点固定的项目，这套规则需要补什么？
把外部验收节点作为硬关卡写入规则表，位置放在验收上线阶段之前，评审项中补充合规检查和外部交付要求，评审角色加入负责对外交付的岗位。这类关卡通常不允许“有条件通过”，结论只有通过或不通过，避免把外部约束转化为内部弹性。其余阶段的规则可以沿用示例结构。
规则表定好后，怎么在协作工具里承载阶段与关卡？
常见做法是用项目计划按交付物或项目阶段维度分解工作，用里程碑标记关卡评审这类决策点，并为计划与里程碑设置基线，便于对比计划与执行的偏差、追溯变更细节；迭代开发阶段则在项目计划中关联迭代与研发任务。以 ONES 为例，ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并支持按业务需求定义项目类型与相关组件，可用来把阶段规则配置成项目结构，具体配置方式需结合团队实际流程确认。
