混合管理阶段规则的核心，是把项目拆成若干阶段，逐阶段写明采用哪种管理方式、阶段之间靠什么交付物衔接、满足什么条件才能进入下一阶段。本文给出一份虚构示例项目的阶段规则表：需求与方案阶段顺序推进，开发阶段按迭代推进，验收与上线阶段回到阶段门评审，并逐项解释每条规则的写法与判断依据，便于读者改写后用于自己的项目。
要点总览（TL;DR）
- 混合管理阶段规则要回答四件事：阶段怎么分、每阶段用什么管理方式、阶段间靠什么交付物衔接、满足什么条件进入下一阶段。
- 示例项目把需求与方案设为顺序推进、开发设为两周一迭代、验收与收尾回到阶段门评审，混合点落在需求确认与迭代承接的交界处。
- 阶段门条件写成“载体＋确认人＋通过标准”，例如高优先级缺陷清零、验收清单全部通过或有书面豁免，评审才有据可查。
- 换项目时按产出特征调整：需整体确认、变更代价高的阶段用顺序推进，可切分、需边做边调的阶段用迭代，规则变更要标版本并通知责任人。
- 这份示例只覆盖单项目层面，组织级流程制度、敏捷框架运作规则、强监管场景的检查项需另行设计。
示例要解决什么问题：阶段规则该写到什么颗粒度
本文使用一个虚构的示例项目：某企业内部的合同管理系统升级，由一名项目经理负责，团队约十人，包含产品、设计、开发和测试角色，计划周期约四个月。项目需要先明确业务规则和数据口径，再进入功能开发，最后统一验收上线。这一背景为示例设定，用于演示规则写法，不代表任何真实客户或真实项目。
一份可用的混合管理阶段规则，至少要回答四类问题。第一，项目分成哪几个阶段，每个阶段的起止以什么为标志。第二，每个阶段采用哪种管理方式，是顺序推进、迭代推进，还是以阶段门评审为主。第三，阶段之间靠哪些交付物衔接，上一阶段的什么产物是下一阶段的输入。第四，进入下一阶段需要满足哪些条件，由谁确认，出现例外时怎么处理。这四类问题对应规则表的四组列，缺一项，规则就难以执行。
颗粒度的判断标准是“项目成员能否直接照做”。写到“开发阶段要保证质量”无法执行；写到“开发阶段每个迭代结束提交可运行版本和迭代验收记录，由项目经理确认后进入下一迭代”就可以执行。规则中出现的角色名称、交付物名称、评审动作，应当是团队日常使用的说法，避免另造一套术语。规则条目数量以覆盖关键控制点为限，通常每个阶段三到六条，过多会让规则本身成为负担。
完整示例：一份混合管理阶段规则表
下表为示例项目的完整阶段规则，标注为虚构情景，可直接参照其结构填写自己的项目。表中“阶段门条件”指进入下一阶段前必须满足的条件，“责任人”指该阶段交付物的主要责任角色。
| 阶段 | 管理方式 | 关键交付物 | 责任人 | 阶段门条件 |
|---|---|---|---|---|
| 需求与方案 | 瀑布顺序推进，前一活动完成并经确认后进入下一活动 | 需求规格说明、业务规则清单、数据口径说明、总体方案与接口清单 | 产品负责人主责，技术负责人参与方案评审 | 需求规格与业务规则经业务方书面确认；方案中的接口与数据口径经技术负责人确认；未决问题清单中的高优先级事项已关闭或有明确处理计划 |
| 开发 | 按两周一迭代推进，迭代内自组织安排任务 | 每个迭代的可运行版本、迭代验收记录、缺陷清单、接口联调记录 | 开发负责人主责，测试负责人参与迭代验收 | 进入验收阶段前，全部计划迭代完成；高优先级缺陷清零；接口联调记录完整；需求变更已登记并评估影响 |
| 验收与上线 | 阶段门评审，按验收清单逐项确认 | 验收测试报告、上线方案与回退方案、用户操作说明、上线确认单 | 测试负责人主责验收，项目经理主责上线组织 | 验收清单全部通过或有书面豁免；上线方案与回退方案经技术负责人和业务方确认；上线窗口与相关方对齐 |
| 收尾 | 阶段门评审，完成即关闭项目 | 项目总结、遗留问题清单、文档归档记录、资源释放确认 | 项目经理主责 | 遗留问题均已指派责任人和处理时限；文档完成归档；相关系统权限与资源完成交接 |
例外处理条款写在规则表下方，与表格配套使用：阶段门条件未全部满足时，由项目经理提出例外申请，写明未满足项、影响评估和补偿措施，经业务方与技术负责人共同确认后方可进入下一阶段；例外事项须登记在遗留问题清单中并设定关闭时限。回退条款规定：开发阶段发现需求规格存在重大遗漏，导致已完成的迭代成果需要返工时，暂停迭代，回到需求与方案阶段补充确认，补充内容经确认后重新排入迭代计划。
逐项解释：每条规则为什么这样写
需求与方案阶段采用顺序推进，原因在于这一阶段的产出是后续所有工作的共同输入。业务规则和数据口径一旦在开发中途反复变化，返工成本会沿开发、测试、验收逐级放大。顺序推进配合书面确认，把不确定性集中在前段解决。这里的“顺序”指活动之间的依赖关系，不要求所有文档一次成型，允许草稿并行讨论，但进入下一阶段前必须有确认版本。
开发阶段改为迭代推进，是因为功能实现的工作可以切分，且需要根据联调情况和用户反馈逐步调整。混合点正出现在两个阶段的交界处：上游用确认过的需求规格和接口清单锁定范围，下游用迭代承接实现，迭代计划只能从已确认的需求中选取内容。需求如需变更，走变更登记并评估对迭代计划的影响，而不是在迭代内直接插入。这样既保留了迭代的灵活性，又避免范围失控。
阶段门条件写成可核验的交付物和状态，而非“需求清晰”“质量达标”这类主观判断，是为了让评审有据可查、结论一致。可核验的条件通常具备三个特征：有明确的载体（文档、记录、清单）、有明确的确认人、有明确的通过标准（全部通过、清零、已关闭）。示例中“高优先级缺陷清零”“验收清单全部通过或有书面豁免”都属于此类写法。
例外与回退条款的作用是让规则在边界情况下仍然可用。没有例外条款，团队遇到条件未满足时只能绕过规则，规则随即失效；没有回退条款，上游问题会在下游持续累积。两条条款都要求留下书面记录和责任人，使例外成为可追踪的管理动作，而非口头放行。
责任人与审批角色的设置遵循“交付物有人主责、阶段门有人确认”的原则。主责人负责产出交付物，确认人负责判断条件是否满足，两者可以重合也可以分开。示例中需求阶段由产品负责人主责、业务方确认，是因为业务规则的解释权在业务方；上线阶段由项目经理组织、技术负责人和业务方共同确认，是因为上线风险同时涉及技术和业务。角色设置应贴合团队实际分工，避免设置无人承担的审批环节。
当这些规则落到工具中执行时，阶段门评审、交付物归档与阶段状态流转需要有统一的承载位置。ONES 支持按项目配置阶段与工作项状态，需求、迭代任务、缺陷和验收记录可以在同一项目内关联管理，阶段门评审的结论和例外事项可作为记录留存，便于在阶段切换时核对条件是否满足。这一衔接适合希望把规则表从文档转为可执行流程的团队，规则本身仍由团队根据项目特点制定。
可迁移规律：换一个项目怎么改这份示例
阶段数量和名称应随项目类型调整。示例项目以需求确定性较高为前提，因此把需求与方案合并为一个阶段；如果项目涉及硬件采购或外部合规审批，可以拆出独立的采购或审批阶段；如果项目周期很短，可以合并验收与收尾。调整时保持一条原则：每个阶段有独立的产出和独立的进入条件，合并阶段意味着合并条件，拆分阶段意味着新增条件。
管理方式与阶段特征的匹配思路可以概括为：产出需要整体确认、变更代价高的阶段，适合顺序推进加阶段门；产出可以切分、需要边做边调整的阶段，适合迭代推进；涉及多方确认和风险释放的节点，适合阶段门评审。同一项目内不同阶段采用不同方式，正是混合管理的体现，不必追求全项目统一。
交付物与阶段门条件的通用写法是“载体＋确认人＋通过标准”。填写时先列出该阶段必须产出的东西，再为每项指定确认角色，最后写明通过的具体状态。条件数量控制在关键项上，把次要检查项放入阶段内的日常检查，避免阶段门变成逐项打勾的形式。
规则变更需要版本管理。建议在规则表上标注版本号和生效日期，变更时记录变更内容、原因和影响范围，并通知所有阶段责任人。项目进行中调整阶段门条件，应同步评估已完成的阶段是否需要补充确认，避免新旧规则混用造成判断分歧。
适用边界：这份示例在哪些情况下不适用
这份示例面向单项目层面的阶段规则，用于回答一个项目内部如何划分阶段、如何衔接。组织级的研发流程制度、跨项目的资源调度规则、项目组合的优先级管理，属于更高层级的管理设计，需要单独制定，不能直接由本示例替代。
示例也不覆盖敏捷框架本身的运作规则。迭代长度、站会、回顾会等 Scrum 或看板实践的具体规则，应由团队采用的框架决定；示例只说明开发阶段采用迭代推进，以及迭代与上游确认成果、下游验收之间的衔接方式。
在需求高度不确定的项目中，把需求与方案阶段设为顺序推进并书面确认，可能导致前段停滞。此类项目可以缩短该阶段，改为以最小可行范围确认加后续迭代补充的方式推进，并把确认条件相应放宽。在强监管或强合规场景中，阶段门条件需要纳入监管要求的检查项和留痕要求，条件数量和确认层级都会增加，示例中的条件设置只能作为起点。
示例为虚构情景，不含真实客户、实测数据和量化成效，表中出现的周期、团队规模和缺陷标准均为演示设定。读者在套用时，应结合自身项目的规模、风险承受能力和协作习惯重新设定具体数值和角色，并在项目启动时与相关方对齐后再执行。
常见问题
阶段门条件没全部满足，但业务方要求按期上线，怎么处理？
按示例中的例外条款走：由项目经理提出例外申请，写明未满足项、影响评估和补偿措施，经业务方与技术负责人共同确认后进入下一阶段，并把例外事项登记到遗留问题清单，设定关闭时限和责任人。关键是让放行成为有记录的决策，事后能追溯是谁确认的、补了什么措施。
如果未满足项涉及上线回退能力或数据安全，建议不适用例外条款，先补齐再上线。
开发阶段迭代进行中，业务方提出新需求，是插进当前迭代还是排到后面？
示例的写法是走变更登记并评估对迭代计划的影响，从已确认的需求中选取迭代内容。实际操作中可以分两种情况：影响当前迭代目标实现的新需求，评估后调整迭代范围并同步测试；不影响当前目标的需求，登记后进入下一迭代的候选列表。无论哪种，都要留下变更记录，避免需求在迭代内被口头插入导致范围失控。
团队规模很小，比如只有三五个人，还需要按四个阶段写规则吗？
阶段数量可以压缩，但每类问题仍要有人回答。小团队可以把需求与方案、验收合并到相邻阶段，保留开发迭代和上线前的一次确认；也可以把阶段门从正式评审改为清单自查加一次短会确认。判断标准是控制点是否覆盖了返工代价最高的环节，人数多少只影响评审形式的正式程度。
规则表制定后，项目中途发现阶段划分不合理，能改吗？
可以改，但要按版本管理：标注新版本号和生效日期，记录变更内容、原因和影响范围，通知所有阶段责任人。已经完成的阶段如果受变更影响，需要评估是否补充确认，避免新旧规则混用造成判断分歧。建议把规则变更放在阶段交界处执行，减少对进行中工作的干扰。
这份示例能直接当作公司的研发流程制度使用吗？
不建议。示例面向单项目的阶段规则，回答一个项目内部如何划分阶段和衔接；组织级的流程制度还涉及跨项目资源调度、项目组合优先级、流程标准化与审计要求，需要单独设计。示例更适合作为制度落地到具体项目时的填写参照。
