混合管理阶段规则要解决的是阶段边界与出口标准问题：把一个项目切成若干阶段，为每个阶段单独确定按瀑布式基线推进还是按迭代推进，并写清每个阶段的出口证据、评审角色和交接条件。本文范围限于单项目层面的规则设计，不涉及组织级流程制度，也不展开敏捷框架本身的实践细节。
要点总览（TL;DR）
- 混合管理阶段规则由四块内容组成：阶段清单与边界、每个阶段的管理方式归属、出口标准与评审方式、角色与交付物及准入条件。
- 阶段划分以交付物形态和不确定性为主要依据：交付物可预先定义、验收标准清晰的阶段倾向瀑布式，需求仍在演进、需要频繁反馈的阶段倾向迭代式。
- 出口标准要写成可检查的条件，每条条件对应一种可归档的证据形式；放行权限、退回路径和例外批准人需事先写明。
- 角色分工区分编制人、确认人、接收人三种身份，跨阶段交接要写明接收方、检查项和确认记录形式。
- 规则定好后用完成检查清单逐项核对，优先补齐出口标准和接收方两项，执行中的调整应回写到规则文档。
混合管理阶段规则由哪几个要素构成
一套可执行的混合管理阶段规则，通常由四块内容组成：阶段清单与边界、每个阶段的管理方式归属、阶段出口标准与评审方式、角色与交付物及准入条件。四块内容相互咬合，缺一块规则就会在执行中变形。例如只写了阶段名称而没有出口标准，阶段评审就会退化为进度汇报；只写了管理方式而没有责任人，迭代阶段容易出现“到期即交付”的默认放行。
阶段清单要回答“项目被切成哪几段、每段的起止以什么为标志”。管理方式归属要回答“这一段按基线推进还是按固定周期推进”。出口标准要回答“拿什么证据证明这一段可以结束”。角色与交付物要回答“谁编制、谁评审、谁接收”。把四块内容落到一张表上，规则就有了可讨论、可修订的载体。
| 阶段名称 | 管理方式 | 出口标准 | 责任人 | 交付物 |
|---|---|---|---|---|
| 需求与方案定义 | 瀑布式 | 需求基线评审通过，方案文档签字 | 项目经理 | 需求规格、方案说明 |
| 核心功能开发 | 迭代式 | 约定周期内产出可运行增量并通过演示验收 | 技术负责人 | 增量版本、演示记录 |
| 集成与验证 | 混合 | 集成测试报告完成，遗留项清单确认 | 质量负责人 | 测试报告、遗留项清单 |
| 上线与移交 | 瀑布式 | 上线检查单全部通过，接收方确认 | 项目经理 | 上线记录、移交确认单 |
这张表是规则的骨架。后续章节分别说明阶段怎么切、出口怎么设、人怎么分工，最后用一个示例把表填完整。
如何划分阶段并给每个阶段定管理方式
阶段划分的主要依据是交付物形态和不确定性，而不是团队习惯或部门边界。交付物可以事先定义清楚、验收标准明确、变更代价高的部分，倾向划为瀑布式阶段；需求仍在演进、需要频繁获取反馈才能收敛的部分，倾向划为迭代式阶段。外部依赖的强弱也影响判定：依赖第三方接口、硬件到货或合规审批的环节，通常需要以里程碑和基线来管理，因为等待和确认本身就是阶段内容。
判定时可以按以下步骤操作。输入是项目目标、交付物清单和已知的外部约束；输出是一张阶段划分判定表。
- 列出项目的主要交付物，按“可预先定义程度”排序，把定义清晰、验收标准可写的交付物归为一组。
- 标出不确定性高的部分，包括需求待验证、技术方案待选型、用户反馈待收集的环节，单独成组。
- 识别外部依赖节点，如硬件到货、第三方接口联调、合规审查，把这些节点作为阶段边界或阶段内的里程碑。
- 为每组确定管理方式：定义清晰且变更代价高的组用瀑布式，以基线文档和阶段评审为出口；不确定性高的组用迭代式，以固定周期和可运行增量为出口。
- 确定衔接点：瀑布式阶段向迭代式阶段交接时，交付基线需求和验收标准；迭代式阶段向瀑布式阶段交接时，交付增量说明、遗留项清单和已知风险。
- 检查阶段粒度：单个阶段建议覆盖数周到数月，短于两周的阶段往往评审成本高于管理收益，长于一个季度的阶段则难以在出口处发现偏差。
| 判定维度 | 倾向瀑布式 | 倾向迭代式 |
|---|---|---|
| 需求稳定性 | 需求已基线化，变更需走审批 | 需求仍在演进，需要频繁反馈 |
| 验收方式 | 按文档和标准逐项验收 | 按可运行增量和演示反馈验收 |
| 外部依赖 | 依赖硬件、审批、第三方节点，等待时间长 | 依赖少，团队可自主安排节奏 |
| 变更代价 | 后期变更代价高，需要前置确认 | 变更可在下个周期吸收 |
阶段过细会让评审和文档工作挤占交付时间，阶段过粗则会让问题在出口处集中暴露。取舍的办法是看每个阶段是否有独立的交付物和独立的验收问题：有，就值得单独成段；没有，就并入相邻阶段。
阶段出口与门禁怎么设：评审项、证据与放行
出口标准要写成可检查的条件，每条条件对应一种证据形式。瀑布式阶段的典型证据包括基线文档及其版本记录、阶段评审记录、验收结论；迭代式阶段的典型证据包括增量演示记录、验收反馈、遗留项清单。证据的作用是让放行结论有据可查，避免评审停留在口头确认。
| 检查项 | 证据形式 | 评审角色 | 放行结论 |
|---|---|---|---|
| 需求基线是否确认 | 基线文档、变更记录 | 业务方、项目经理 | 通过／有条件通过／退回 |
| 阶段交付物是否完整 | 交付物清单、签字记录 | 技术负责人、质量角色 | 通过／退回 |
| 增量是否可演示 | 演示记录、验收反馈 | 业务方、技术负责人 | 通过／退回 |
| 遗留项是否受控 | 遗留项清单及处理计划 | 质量角色、项目经理 | 通过／有条件通过 |
| 下一阶段准入条件是否满足 | 准入检查单 | 下一阶段责任人 | 准入／不准入 |
放行权限要事先写明：谁有权给出“通过”，谁只能给出“有条件通过”，谁有权批准例外。常见做法是阶段责任人对交付物完整性负责，业务方对验收结论负责，项目经理对整体放行负责；涉及范围或基线变更的例外，需要由有权变更决策的角色批准，并记录在案。
未通过时的处理路径同样属于规则内容。退回要写明退回原因、整改责任人和复评时间；有条件通过要写明遗留项、责任人和关闭期限，并约定遗留项在下一阶段的跟踪方式。例外处理不能省略记录环节，否则规则会在几次“特殊情况”之后失去约束力。
当阶段评审和交付物需要长期留痕时，可以把门禁检查项、评审记录和交付物文档放在同一套工作项与文档体系中管理。ONES 的项目计划支持按阶段分解工作并设置里程碑，基线功能可用于对比计划与执行的偏差；评审记录与交付物则可随项目文档归档，便于在交接时调取。具体配置方式以实际产品环境为准。
角色与交付物如何分工
规则落到人，才有执行的可能。混合管理下角色分工的关键是区分三种身份：编制人、确认人、接收人。编制人对交付物内容负责，确认人对交付物是否满足出口标准负责，接收人对下一阶段的准入条件负责。三种身份可以由同一人兼任，但要在规则中写明，避免出现无人确认的交付物。
| 角色 | 瀑布式阶段职责 | 迭代式阶段职责 | 跨阶段交接职责 |
|---|---|---|---|
| 项目经理 | 组织基线评审，维护阶段计划与里程碑 | 协调迭代节奏，跟踪遗留项 | 发起交接，确认准入检查单 |
| 技术负责人 | 编制技术方案，确认交付物完整性 | 保障增量可运行，参与演示 | 向接收方说明技术遗留与风险 |
| 业务方 | 确认需求基线与验收结论 | 参加演示，给出验收反馈 | 确认业务侧准入条件 |
| 质量角色 | 核查评审证据，出具质量结论 | 核查增量质量，维护遗留项清单 | 确认质量相关准入项 |
跨阶段交接是最容易出空缺的环节。规则中要写明接收方是谁、接收时检查什么、确认动作以什么形式留下记录。例如迭代阶段向集成验证阶段交接时，接收方需要检查增量说明、遗留项清单和已知风险三项内容，确认后在交接记录上签署结论；缺少任一项，交接不成立。
示例：一个软硬件结合项目的阶段规则
以下为演示情景，用于说明规则如何组合使用，不代表真实项目实践。某软硬件结合项目包含硬件采购与到货、嵌入式软件开发、平台侧功能开发、联调验证和上线移交。按交付物形态和不确定性划分，得到如下阶段规则。
| 阶段 | 管理方式 | 出口证据 | 责任人 | 交付物 |
|---|---|---|---|---|
| 方案与需求定义 | 瀑布式 | 需求基线评审记录、方案签字 | 项目经理 | 需求规格、总体方案 |
| 硬件到货与验收 | 瀑布式 | 到货验收单、硬件测试记录 | 硬件负责人 | 验收报告 |
| 平台功能开发 | 迭代式 | 每周期增量演示记录、验收反馈 | 技术负责人 | 增量版本、演示记录 |
| 软硬件联调 | 混合 | 联调测试报告、遗留项清单 | 质量负责人 | 联调报告、遗留项清单 |
| 上线与移交 | 瀑布式 | 上线检查单、接收方确认单 | 项目经理 | 上线记录、移交确认单 |
关键阶段的出口证据各有侧重。方案与需求定义阶段以基线文档和评审记录为出口，硬件到货阶段以验收单和测试记录为出口，平台功能开发阶段以每个周期的增量演示和验收反馈为出口，联调阶段以测试报告和遗留项清单为出口。
一次门禁未通过的处理可以这样展开：平台功能开发阶段某周期演示中，业务方发现关键流程与需求基线不一致，评审给出“退回”结论，退回原因记录为“流程与基线不符”，责任人为技术负责人，复评时间定在下一周期演示。技术负责人调整实现后，在复评中补充演示记录，业务方确认后放行。该周期的遗留项同时进入遗留项清单，由项目经理跟踪至联调阶段关闭。
规则在执行中需要调整。常见调整包括：外部依赖延期导致阶段边界后移，此时应更新阶段计划和里程碑，并重新确认出口时间；迭代阶段发现需求需要变更基线，应走变更审批并同步更新需求文档版本。调整动作本身也要留下记录，便于后续对比计划与执行的偏差。
在工具承载上，ONES 的项目计划支持按阶段分解工作、设置任务依赖和里程碑，并可关联迭代与研发任务，使瀑布式阶段与迭代式阶段在同一项目下衔接；基线功能可用于对比计划与执行偏差，帮助在阶段出口处识别风险。这些能力的具体使用范围以实际产品配置为准。
规则落地后的完成检查
规则定好之后，用一份检查清单判断它是否可执行、可验证。以下条目逐项核对，全部满足再进入执行。
- 每个阶段都有明确的出口标准，且每条标准对应一种可获取的证据形式。
- 证据能够归档，评审记录、交付物版本和放行结论可以按阶段追溯。
- 每个阶段的编制人、确认人、接收人都已写明，没有空缺，也没有同一交付物出现两个确认人。
- 跨阶段交接的准入检查项已列出，接收方的确认动作有记录形式。
- 门禁评审的参与角色和放行权限已写明，例外处理的批准人已指定。
- 未通过时的退回路径已写明，包括退回原因记录、整改责任人和复评时间。
- 阶段变更和需求变更的处理路径已写明，变更后阶段计划和基线如何更新有约定。
- 阶段粒度经过检查，没有短到评审成本过高的阶段，也没有长到无法在出口发现偏差的阶段。
检查中发现空缺时，优先补齐出口标准和接收方两项，这两项直接决定阶段能否真正关闭。规则不是一次写完就固定不变，项目执行中的调整应回写到规则文档，使下一轮项目可以直接复用。
常见问题
阶段划分得比较粗，只在项目首尾设两个门禁，可以吗？
可以，但要看项目的不确定性分布。如果项目交付物定义清晰、外部依赖少、变更代价可控，阶段少一些能降低评审和文档成本。风险在于问题会在出口处集中暴露，此时应至少保证每个有独立交付物和独立验收问题的部分单独成段，并在阶段内设置里程碑跟踪进度。阶段粒度没有统一标准，判断依据是能否在出口处及时发现偏差。
迭代式阶段里出现需求变更，需要走瀑布式的变更审批吗？
取决于变更是否触及已基线化的内容。迭代阶段内部的需求调整，如果仍在基线范围内，可由阶段责任人按迭代节奏吸收，并在演示和验收反馈中体现；一旦变更影响已确认的基线需求、验收标准或阶段出口条件，就应走变更审批，同步更新需求文档版本和阶段计划。规则中要事先写明这条分界线，否则团队会在两种处理方式之间反复摇摆。
门禁评审给出“有条件通过”后，遗留项由谁跟踪、什么时候关闭？
规则中应写明遗留项的责任人和关闭期限，并约定跟踪方式。常见做法是由项目经理维护遗留项清单，责任人按约定时间提交整改结果，质量角色核查后关闭；跨阶段的遗留项要随交接记录一并移交，由接收方确认跟踪责任。遗留项长期挂账会让门禁失去约束力，因此关闭期限和升级路径需要在规则里写清楚。
小团队人手有限，编制人、确认人、接收人能否由同一人兼任？
可以兼任，但要在规则中写明兼任关系，并保留确认动作的记录。兼任的风险是确认环节流于形式，尤其是编制人同时担任确认人时，出口标准容易被自我放宽。可行的做法是把业务方或质量角色保留为独立确认方，至少让验收结论由编制人之外的角色给出；接收人兼任时，交接检查项仍需逐项核对并留下记录。
阶段规则定好之后，项目执行中调整了阶段边界，规则文档要不要同步改？
要改。阶段边界、出口时间或管理方式发生调整时，应更新阶段计划和里程碑，并把调整原因、批准人和影响范围记录到规则文档中。这样下一轮项目可以直接复用修订后的版本，也能在复盘时对比计划与执行的偏差。调整记录本身是规则的一部分，缺少记录会让规则在多次例外之后逐渐失效。
