混合管理阶段规则要解决的是：一个项目里哪些阶段按瀑布式阶段门推进，哪些阶段允许迭代，阶段之间凭什么条件转换，以及每个阶段由谁负责、交付什么。本文围绕单项目的阶段划分、方式选择、门禁条件和角色交付四件事展开，给出一套可直接填写的规则表与检查清单；组织级流程制度不在讨论范围。
要点总览（TL;DR）
- 阶段划分以交付物和风险集中点为依据，每个阶段以一个可验收的完成物收尾，周期约半年的项目通常划四到六个阶段。
- 逐阶段判断管理方式：需求稳定、变更少、外部依赖明确用瀑布式阶段门；细节待探索、需频繁验证用迭代；两者兼有则结合使用，同一项目不同阶段可以不同。
- 准入条件检查前置交付物、资源和审批，退出条件检查交付物完成度、评审结论和遗留问题处理，条件要写成可核验条目并指明核验方式。
- 规则中写明项目负责人、阶段负责人、评审人、干系人四类角色的职责与对应交付物，避免出现无人交付的条目。
- 规则在项目启动会上逐项确认，阶段转换时按检查表校验并留痕，用完成检查清单核对阶段、方式、门禁、角色、记录是否齐全。
先划分阶段：按交付物与风险切分项目
阶段划分的起点是交付物，而非时间。把项目最终要交出的东西逐层拆开，找到那些“完成之后才能稳定开展下一步”的节点，这些节点天然构成阶段边界。风险集中点同样重要：某类技术验证、外部接口联调、合规审查如果失败代价高，就值得单独设为一个阶段，让问题在投入扩大前暴露。
切分时按以下顺序操作：
- 列出项目全部主要交付物，包括硬件样机、软件版本、文档、验收报告等。
- 识别交付物之间的依赖关系，确定哪些必须先完成。
- 标出风险集中点，即不确定性高、返工成本大的工作。
- 把交付物与风险点合并成阶段，每个阶段以一个可验收的完成物收尾。
阶段数量与粒度需要取舍。阶段太少，门禁形同虚设，问题积累到后期才暴露；阶段太多，评审开销压过实际工作，团队疲于准备材料。一个可操作的判断是：每个阶段至少包含一项独立可验收的交付物，且阶段时长足以让评审有意义。对于周期在半年左右的项目，四到六个阶段通常较为合适；周期更长或风险更高的项目可以适当增加，但每个阶段仍应保持“有明确完成物”这一底线。
阶段边界必须对应明确的完成物，例如“硬件设计冻结”“软件首个可演示版本通过内部验收”“系统联调完成”。边界写成“设计阶段结束”这类表述，评审时无法判断是否真的结束。划分完成后形成一份阶段划分清单：
| 阶段名称 | 主要交付物 | 边界条件（完成标志） |
|---|---|---|
| 需求与方案定义 | 需求规格、总体方案 | 方案评审通过，需求基线确定 |
| 详细设计与原型 | 设计文档、关键模块原型 | 原型验证通过，设计冻结 |
| 开发与集成 | 可运行版本、集成记录 | 功能自测通过，集成问题清单关闭 |
| 验证与验收 | 测试报告、验收材料 | 验收评审通过，遗留问题有处理结论 |
逐阶段选择管理方式：瀑布、迭代与混合的判定
阶段划分完成后，逐个阶段判断管理方式。判定依据集中在三点：需求稳定性、变更频率、外部依赖。
- 需求稳定、变更少、外部依赖明确：适合瀑布式阶段门。工作可以一次规划到位，按计划推进，阶段末集中评审。
- 需求方向清楚但细节待探索、需要频繁验证：适合迭代推进。以短周期产出可评估的版本，根据反馈调整下一步。
- 阶段内既有确定性工作又有探索性工作：采用两者结合，确定性部分按计划推进，探索性部分以迭代方式收敛，阶段末统一过门。
同一项目的不同阶段可以采用不同方式，这是混合管理的核心。例如需求定义阶段用迭代方式与业务方反复确认，开发阶段对核心模块用迭代、对外部接口对接用瀑布式计划控制，验证阶段用阶段门集中评审。方式选择服务于该阶段的不确定性程度，而非全项目统一标签。
混合阶段之间的衔接需要专门设计信息传递。迭代阶段结束时，输出的应是下一阶段可直接使用的稳定产物，例如冻结的需求基线、确认的接口规格；瀑布阶段向迭代阶段交接时，应给出清晰的约束条件和验收标准，让迭代团队知道边界在哪里。衔接点上的信息如果只存在于口头沟通，阶段转换就会出现理解偏差。
| 阶段 | 管理方式 | 判定理由 |
|---|---|---|
| 需求与方案定义 | 迭代推进 | 需求细节需与业务方多轮确认，变更频率高 |
| 详细设计与原型 | 混合 | 关键模块需迭代验证，整体设计按计划推进 |
| 开发与集成 | 迭代为主 | 功能实现需持续反馈，外部接口按约定计划控制 |
| 验证与验收 | 瀑布式阶段门 | 验收标准明确，集中评审后进入交付 |
定义阶段进入与退出条件
每个阶段都要有可检查的准入与退出标准，让阶段转换有据可依，避免靠口头确认推进。准入条件回答“能不能开始”，通常包括三类：前置交付物是否到位、资源是否就绪、必要的审批是否完成。退出条件回答“能不能结束”，包括交付物完成度、评审是否通过、遗留问题是否有明确处理结论。
条件要写成可核验的条目，而非程度描述。“需求文档完成”不如“需求文档经评审通过并形成基线”可检查；“测试基本完成”不如“计划内测试用例执行完毕，未关闭缺陷均有责任人和处理计划”可判断。每条条件还应指明核验方式：查文档、看演示、对清单，还是评审会决议。
条件未满足时的处理方式需要提前约定，常见有三种：
- 带条件通过：遗留问题不影响下一阶段主体工作，列出问题清单、责任人和关闭期限，允许进入下一阶段并跟踪。
- 有条件返工：关键交付物未达标，退回本阶段补齐后重新评审，明确返工范围和时限。
- 调整计划：外部条件发生实质变化，经项目负责人与关键干系人确认后调整阶段目标或时间，并记录变更原因。
三种处理方式应在规则中写明适用情形和决定人，避免每次转换临时争论。阶段门检查表可按以下结构填写：
| 检查项 | 类型 | 核验方式 | 判定结果 |
|---|---|---|---|
| 上一阶段交付物已归档并确认 | 准入 | 查文档库 | 通过 / 不通过 |
| 阶段所需人员与资源已到位 | 准入 | 对资源清单 | 通过 / 不通过 |
| 阶段交付物达到完成标准 | 退出 | 评审会 | 通过 / 带条件通过 / 返工 |
| 遗留问题已登记并有处理计划 | 退出 | 查问题清单 | 通过 / 不通过 |
角色分工与各阶段交付物
规则要落到人身上才可执行。混合管理阶段规则中通常涉及四类角色：项目负责人、阶段负责人、评审人、干系人。
- 项目负责人：对整体阶段划分和规则负责，主持阶段转换决策，处理跨阶段问题，维护规则表的有效性。
- 阶段负责人：对本阶段的交付物和执行负责，组织本阶段工作，准备阶段门材料，提出转换申请。
- 评审人：按阶段门检查表逐项核验，给出通过、带条件通过或返工结论，对评审结论负责。
- 干系人：提供需求和资源支持，参与关键评审，接收阶段结果和遗留问题通报。
每类角色对应明确的产出。项目负责人产出阶段规则表和转换决策记录；阶段负责人产出阶段计划、交付物和阶段门申请材料；评审人产出评审结论和问题清单；干系人产出需求确认、资源承诺和验收意见。职责与交付物要一一对应，避免出现“大家都负责、实际无人交付”的条目。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 项目负责人 | 制定与维护阶段规则，主持转换决策 | 阶段规则表、转换决策记录 |
| 阶段负责人 | 组织阶段执行，准备门禁材料 | 阶段计划、交付物、门禁申请 |
| 评审人 | 核验门禁条件，给出结论 | 评审结论、问题清单 |
| 干系人 | 确认需求，提供资源，参与验收 | 需求确认记录、验收意见 |
规则需要在项目中承载阶段状态、交付物和评审记录时，可以把阶段作为计划中的里程碑或工作项节点，用前后置依赖表达阶段顺序，用文档关联保存阶段门材料。ONES 的项目计划支持按交付物或项目阶段分解工作、设置任务依赖并用里程碑标记决策点，项目计划和里程碑基线可用于对比计划与执行偏差；ONES Wiki 支持文档关联任务，便于把评审记录与对应工作项放在一起。阶段门评审是否有专门的审批配置，需结合实际版本核验。
示例：一个软硬件结合项目的混合阶段规则
以下为演示情景，用于说明规则表如何填写，不代表真实客户案例。某软硬件结合项目周期约八个月，交付一套带配套软件的采集设备。项目划分为四个阶段，各阶段管理方式与门禁条件如下。
| 阶段 | 主要交付物 | 管理方式 | 准入条件 | 退出条件 | 负责人 |
|---|---|---|---|---|---|
| 需求与方案定义 | 需求规格、系统方案 | 迭代推进 | 项目立项完成，业务方接口人确定 | 需求基线确认，方案评审通过 | 系统工程师 |
| 硬件设计与软件原型 | 硬件设计文件、软件原型 | 混合 | 需求基线生效，关键器件选型确认 | 设计冻结，原型演示通过 | 硬件负责人、软件负责人 |
| 开发与联调 | 设备样机、软件版本、联调记录 | 迭代为主 | 设计文件归档，样机物料到位 | 联调问题清单关闭，版本自测通过 | 项目经理指定的阶段负责人 |
| 验证与验收 | 测试报告、验收材料 | 瀑布式阶段门 | 联调完成，测试环境就绪 | 验收评审通过，遗留问题有处理结论 | 质量负责人 |
评审安排上，需求与方案定义阶段末安排一次方案评审会，评审人为项目负责人、业务方代表和技术负责人；开发与联调阶段末安排联调结果评审，重点核验问题清单关闭情况；验证与验收阶段按验收标准组织正式评审。每次评审形成结论记录，带条件通过的问题进入遗留问题清单，指定责任人和关闭期限，在下一阶段门禁时复核。
这张表就是规则表的核心内容：阶段、交付物、管理方式、准入、退出、负责人六列齐全，项目启动时逐项确认，阶段转换时逐项校验。
规则落地与完成检查
规则制定完成后，落地分三步。第一步，在项目启动会上确认规则表：逐条过一遍阶段划分、管理方式、门禁条件和角色分工，由项目负责人和关键干系人当场确认，确认结果记录在项目启动材料中。第二步，阶段转换时执行校验：阶段负责人提交门禁申请和交付物，评审人按检查表逐项核验，结论和遗留问题写入记录，未满足条件的按约定方式处理。第三步，项目负责人定期复核规则表的有效性，阶段目标或外部条件发生实质变化时更新规则并记录变更原因。
规则执行到位与否，可用以下清单逐项核对：
- 阶段划分清单是否覆盖全部主要交付物，每个阶段是否有明确完成物；
- 每个阶段是否标注了管理方式及判定理由，混合衔接点的信息传递是否有约定；
- 每个阶段是否都有准入和退出条件，条件是否可核验、是否指明核验方式；
- 条件未满足时的处理方式是否写明适用情形和决定人；
- 四类角色是否都有明确职责和对应交付物，是否存在无人负责的条目；
- 阶段门检查表和评审记录是否实际填写并归档，遗留问题是否有人跟踪；
- 规则表是否在项目启动时确认，阶段转换时是否逐项校验并留痕。
清单中任何一项缺失，规则就存在执行断点。补齐这些条目，混合管理阶段规则才能从文档变成项目里可运行的管理机制。
常见问题
阶段划分得比较粗，只设两三个阶段，会有什么问题？
阶段过少时，阶段门能拦截的问题有限，缺陷和风险容易积累到后期才暴露，返工代价更大。判断粒度是否合适，可以看每个阶段是否至少包含一项独立可验收的交付物，以及阶段时长是否足以让评审有意义。如果某个阶段内部同时包含探索性工作和确定性交付，可以考虑拆开，让不确定性高的部分单独设门。
同一个阶段里既有按计划推进的工作，又有需要反复试错的工作，门禁条件怎么定？
这类阶段适合采用两者结合的方式：确定性部分按计划推进并设定明确的完成标准，探索性部分以短周期产出可评估的结果，阶段末统一过门。门禁条件可以分两层写，一层针对确定性交付物的完成度，一层针对探索性工作的收敛结论，例如原型验证是否通过、关键方案是否选定。两层条件都满足才允许进入下一阶段，探索性工作未收敛时按带条件通过或返工处理。
阶段门评审没有通过，但项目进度压力很大，可以先进下一阶段再补吗？
这属于规则中应提前约定的处理情形。常见做法是带条件通过：遗留问题不影响下一阶段主体工作时，列出问题清单、责任人和关闭期限，允许进入下一阶段并在下次门禁时复核。如果关键交付物未达标，则应退回本阶段补齐后重新评审。哪种情形适用哪种处理、由谁决定，需要在规则中写明，避免每次转换临时争论。进度压力本身不构成跳过门禁的理由，否则规则会逐步失效。
规则制定后，项目中途外部条件发生较大变化，阶段规则要不要改？
需要评估后决定。如果变化影响到阶段目标、交付物或外部依赖，项目负责人应组织关键干系人复核规则表，调整相应阶段的划分、管理方式或门禁条件，并记录变更原因。调整后的规则同样要在阶段转换时校验。规则保持稳定有利于执行，但外部条件实质变化时固守原规则会让门禁失去意义，关键是变更要有记录、有确认人。
在项目管理工具里承载阶段规则，需要关注哪些配置点？
可以关注三个配置点：阶段能否作为计划中的节点表达，例如用里程碑标记阶段边界、用前后置依赖表达阶段顺序；阶段门材料能否与对应工作项关联保存，便于评审时集中查阅；计划与执行偏差能否对比查看，支撑阶段转换时的判断。以 ONES 为例，项目计划支持按交付物或项目阶段分解工作、设置任务依赖并用里程碑标记决策点，项目计划和里程碑基线可用于对比计划与执行偏差，ONES Wiki 支持文档关联任务，便于把评审记录与工作项放在一起。阶段门评审是否有专门的审批配置，需结合实际版本核验。
