混合管理阶段规则要解决的是顺序开发与迭代执行在同一项目里的共存问题：哪些环节必须按瀑布方式逐级通过，哪些工作可以在阶段内部按迭代推进，两者在交接点如何验收。本文按“切阶段—定字段—管衔接—分角色—做示例—完成检查”的顺序，给出一套可直接填写的阶段规则表和衔接检查表，适用于单个项目层面的规则制定。
要点总览（TL;DR）
- 阶段划分以交付物和决策点为锚：产出构成后续前提、或存在必须由特定角色决策的节点，就设为顺序推进的瀑布阶段；其余工作放进阶段内部的迭代单元。
- 阶段规则固定五个字段——准入条件、准出条件、关键交付物、评审人、变更处理，按“梳理现状→定义字段→试填真实项目→评审定稿”四步制定。
- 阶段衔接靠准入检查与准出检查两道清单，迭代成果在阶段评审前汇总为统一交付物清单，评审会只处理缺口和争议项。
- 规则维护责任落到单一角色，执行中发现不可操作时提交具体问题，确认后的变通做法回写进规则。
- 完成判断标准：字段无空缺、衔接检查可逐条判断、至少一个真实阶段按规则完整走通一次。
先定阶段骨架：哪些环节必须顺序推进
阶段划分的起点是识别“错了代价高、返工成本大”的环节。判断标准可以落在两条上：该环节的产出是否构成后续工作的前提输入，以及该环节是否存在必须由特定角色做出决策才能继续的节点。满足其中一条，就适合设为顺序推进的瀑布阶段；两条都不满足的工作，放进阶段内部的迭代单元处理。
典型需要顺序推进的环节包括：需求范围与验收标准的确认、总体方案或架构的定稿、关键外部依赖（如硬件样件、第三方接口）的到位、上线或交付前的验收。这些环节的共同特征是决策一旦做出，后续变更会牵动多个团队，因此需要明确的评审与签字动作。
阶段数量宜少不宜多。一个中等复杂度的混合项目，控制在4到7个阶段较为常见，原则是每个阶段对应一个可识别的决策点，避免为管理方便而切出没有决策意义的阶段。命名建议统一采用“阶段名+关键交付物”的形式，例如“方案定稿阶段（总体设计说明书）”，这样后续填写准入准出条件时可以直接引用交付物名称。
阶段内部的可迭代单元按交付物可独立验收的最小集合划分。例如在“开发实现阶段”内部，可以按功能模块或用户故事集划出若干迭代单元，每个单元有独立的完成定义，但它们的整体验收仍归入所属阶段的准出评审。划分依据是：单元之间依赖弱、可以并行或滚动推进；单元成果能够单独演示或测试。
完成这一步的产物是一份项目阶段清单，至少包含四列：阶段名称、顺序、关键交付物、决策点（由谁在什么条件下做出什么决定）。这份清单是后续所有规则字段的挂载基础。
阶段规则的核心字段与操作步骤
阶段规则要能被执行，必须落到固定字段上。建议每个阶段定义五个字段，字段一旦定稿保持稳定，避免执行中反复改动导致标准漂移。
| 字段 | 填写内容 | 填写说明 |
|---|---|---|
| 准入条件 | 进入本阶段前必须满足的状态 | 写成可核验的事实，如“上一阶段准出评审通过”“关键外部依赖已到位”，避免“准备充分”这类无法判断的表述 |
| 准出条件 | 本阶段可以结束的标准 | 与关键交付物绑定，说明交付物达到什么状态、由谁确认 |
| 关键交付物 | 本阶段必须产出的文档、样件或系统状态 | 列出名称与版本要求，注明存放位置 |
| 评审人 | 对准出做出判断的角色 | 写角色而非姓名，明确是单人确认还是评审会决议 |
| 变更处理 | 本阶段内发生范围、方案或进度变更时的处理方式 | 说明触发条件、评估人、审批路径和对后续阶段的影响记录方式 |
制定步骤按四步推进。第一步梳理现状：收集当前项目实际在用的评审习惯、交付物清单和决策记录，找出已经在起作用但未成文的规则。输入是历史项目文档和团队访谈记录，输出是一份现状清单，完成标志是团队对“现在实际怎么走”达成一致。
第二步定义字段：按上表逐阶段填写五个字段。输入是阶段清单和现状清单，输出是初版阶段规则表，完成标志是每个阶段五个字段均无空缺。
第三步试填：选一个正在进行的真实项目，用初版规则回溯最近一个已完成的阶段，检查准入准出条件是否真的可判断、评审人是否真的能做出决定。输入是初版规则表和该项目的历史记录，输出是问题清单与修订稿，完成标志是至少一个阶段能够完整走通检查而不产生歧义。
第四步评审定稿：由规则制定者组织阶段负责人和评审人共同确认，输出定稿版本并注明生效日期。完成标志是所有相关角色确认自己负责的字段和动作，规则进入执行状态。
阶段衔接与迭代交接怎么管
阶段衔接的核心是两道检查：进入下一阶段前的准入检查，和结束当前阶段前的准出检查。两道检查都应以清单形式存在，逐项打勾并记录检查人和日期。准入检查关注“前置条件是否真实满足”，准出检查关注“交付物是否达到约定状态”，两者不能合并为一次会议草草通过。
迭代成果向阶段评审汇总时，需要一个统一的交付物清单作为载体。每个迭代单元结束时登记其产出（功能、文档、测试记录），阶段负责人按清单核对是否覆盖了本阶段准出条件要求的全部内容。汇总动作应在阶段评审前完成，评审会上只处理清单中的缺口和争议项，避免把评审会开成逐项汇报会。
衔接处的变更与返工需要明确触发条件。常见情形有三类：准出检查未通过导致阶段延期、下一阶段准入检查发现前置条件不成立、阶段内变更影响到已确认的上游交付物。对每一类，规则中应写明由谁评估影响、是否需要重新走评审、以及如何在计划中记录这次返工。返工记录本身也是后续阶段规则修订的依据。
当阶段与迭代需要在同一项目里并行跟踪时，规则要落到可查看的状态上。ONES 支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解工作，并为任务设置前后置依赖、用里程碑标记决策点；项目计划中也可以关联迭代和研发任务，便于项目经理在同一视图里掌握阶段进度与迭代进展。将阶段准入准出检查对应到里程碑和交付物状态，规则就从文档变成了可跟踪的执行记录。
角色分工与各阶段交付物
规则相关角色分四类。规则制定者负责组织字段定义、试填和定稿，通常由项目管理办公室或项目集负责人承担；阶段负责人对本阶段的交付物和准出条件负责，通常是该阶段主要工作的团队负责人；评审人按阶段规则表中指定的角色对准出做出判断，可以是技术负责人、质量负责人或客户代表；执行角色在阶段内部按迭代单元完成具体工作，并对单元成果的完成定义负责。
| 阶段（示例） | 关键交付物 | 责任人 | 评审人 |
|---|---|---|---|
| 需求确认阶段 | 需求规格说明书、验收标准 | 产品负责人 | 项目负责人、客户代表 |
| 方案定稿阶段 | 总体设计说明书、接口约定 | 技术负责人 | 架构评审组 |
| 开发实现阶段 | 各迭代单元功能与单元测试记录 | 开发团队负责人 | 技术负责人 |
| 集成验证阶段 | 集成测试报告、缺陷收敛记录 | 测试负责人 | 质量负责人 |
| 交付验收阶段 | 验收报告、移交清单 | 项目负责人 | 客户代表 |
规则维护责任应落到单一角色，建议由规则制定者统一保管版本，其他角色提出修改建议而不直接改动。每次修订记录修改原因、影响范围和生效时间，避免多头修改造成执行标准不一致。阶段负责人在执行中发现规则不可操作时，应提交具体问题而非自行变通，变通做法经确认后回写进规则。
示例：一个软硬件协同项目的阶段规则
以下为一个演示情景，用于说明规则如何填写和运行，不代表任何特定企业的实际项目。某团队开发一款带配套软件的硬件设备，项目周期约九个月，硬件打样周期长、软件功能可滚动交付，因此采用混合管理。
阶段划分：需求确认阶段、方案定稿阶段、硬件样机阶段、软件开发阶段、集成验证阶段、交付验收阶段。其中硬件样机阶段基本顺序推进，软件开发阶段内部按功能模块划出四个迭代单元，每个单元两周，单元成果在阶段内滚动验收，整体在集成验证阶段统一评审。
以“软件开发阶段”为例填写规则表：准入条件为方案定稿阶段准出评审通过、开发环境与接口文档就绪；准出条件为四个迭代单元全部完成、单元测试通过率达标、遗留缺陷清单经技术负责人确认；关键交付物为各单元功能说明、单元测试记录、缺陷清单；评审人为技术负责人；变更处理为需求变更由产品负责人评估影响，涉及接口的变更需回到方案定稿阶段补充评审，并在计划中记录返工工作量。
衔接检查的实际走法：硬件样机到位后，先做准入检查确认样机版本与接口文档一致，再启动集成验证阶段的准备工作；软件开发阶段准出前，阶段负责人按交付物清单核对四个单元成果是否齐全，缺口项在评审会上指定补交责任人和期限。若集成验证阶段发现接口不一致需要返工，按变更处理规则回到方案定稿阶段补充评审，返工记录同步更新到阶段规则的问题清单中，作为下一项目修订规则的输入。
在工具承载上，这类阶段与迭代并行的结构可以用 ONES 的项目模板起步：ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并支持按业务需求定义项目类型与相关组件；阶段里程碑、交付物和迭代任务可以在同一项目计划中关联查看。规则表中的准入准出条件仍由团队自行定义，工具承担的是状态记录与偏差对比，例如通过计划和里程碑基线对比识别阶段延期风险，通过版本对比追溯变更细节。
规则落地后的完成检查
规则是否可以执行，用一份检查清单逐项核对即可判断。以下检查项建议在规则定稿后和每个阶段结束时各做一次。
- 阶段清单完整：每个阶段都有名称、顺序、关键交付物和决策点，阶段数量与项目实际决策点匹配，没有为凑数而设的空阶段。
- 字段无空缺：每个阶段的准入条件、准出条件、关键交付物、评审人、变更处理五个字段均已填写，且条件表述可核验。
- 评审人可履职：每个阶段的评审人角色明确，且该角色在项目中有实际决策权限，不存在“挂名评审”。
- 衔接检查可操作：准入与准出检查以清单形式存在，检查项能逐条判断是或否，检查人和日期有记录位置。
- 迭代汇总路径清晰：迭代单元成果有统一的登记方式，阶段评审前能汇总为完整交付物清单。
- 变更处理有路径：三类常见变更情形均有对应的评估人、审批路径和记录方式。
- 规则与实际执行一致：抽取最近一个已完成阶段，按规则回溯检查，实际做法与规则描述一致，或差异已有明确说明和修订计划。
- 维护责任明确：规则版本由单一角色保管，修订有记录，生效时间清晰。
检查中发现的问题按“字段缺失、条件不可判断、角色缺位、执行偏差”四类归集，分别回到对应步骤修订。全部检查项通过，且至少一个真实阶段按规则完整走通一次，即可认为规则制定完成、进入执行状态。
常见问题
项目里只有部分环节需要顺序推进，阶段数量怎么控制？
以决策点为计数依据，而不是以工作类型或团队划分。每个阶段应对应一个可识别的决策点，例如需求范围确认、方案定稿、样机到位、验收通过。一个中等复杂度的混合项目通常落在4到7个阶段。若某个环节没有需要特定角色拍板的节点，它更适合作为阶段内部的迭代单元，而不是独立阶段。
阶段规则定稿后，执行中发现某条准出条件无法判断怎么办？
由阶段负责人提交具体问题，说明是哪条条件、在什么场景下无法判断，交由规则制定者评估。确认需要调整的，修订规则并记录修改原因、影响范围和生效时间，再通知相关角色。执行角色自行变通的做法应避免，确有必要先行变通的，事后回写进规则，保持文档与实际执行一致。
迭代单元做到一半，上游阶段确认的接口需要变更，走什么流程？
按阶段规则表中的变更处理字段执行：先由指定评估人判断影响范围，涉及已确认上游交付物的，回到对应阶段补充评审，并在项目计划中记录返工工作量。返工记录同步进入规则的问题清单，作为下一轮修订的输入。规则中应提前写明这类情形的触发条件、评估人和审批路径，避免临时协商。
阶段规则能否直接套用工具里的项目模板？
模板可以提供阶段结构、里程碑和任务分解的起点，规则表中的准入准出条件、评审人和变更处理仍需团队按项目实际填写。ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并支持按业务需求定义项目类型与相关组件；ONES 的项目计划支持按目标、交付物或项目阶段分解工作，设置前后置依赖并用里程碑标记决策点，可作为阶段规则的承载方式。具体字段定义以团队评审定稿的规则表为准。
规则制定完成后，多久复核一次比较合适？
建议在每个阶段结束时按完成检查清单核对一次，重点看规则与实际执行是否一致、衔接检查是否仍然可操作。项目收尾后做一次完整复核，把返工记录和问题清单归集为修订输入。复核频率随项目复杂度调整，阶段周期长的项目可在阶段中期增加一次抽查。
