阶段准入标准要回答的是：阶段结束时，团队凭什么决定继续、带条件继续还是终止。本文给出一份可直接参照填写的示例，包含阶段目标与交付物、准入检查项与判定口径、评审角色与决策权限、结论与后续动作四部分，并用一个完整样例说明每项怎么写、为什么这样写。示例为演示情景，阈值和角色需结合团队情况调整。
要点总览（TL;DR）
- 阶段准入标准用于阶段结束时的去留判断，由阶段目标与交付物、准入检查项与判定口径、评审角色与决策权限、结论与后续动作四部分组成。
- 检查项要写成可判定的条件，并逐项配证据要求；判定口径包含判断对象、判断标准和完成标志三要素，证据要能当场调出。
- 结论至少区分继续、带条件继续、终止三类；带条件继续必须记录条件内容、责任人和复核时点，否则等同于无条件通过。
- 换阶段时保留“检查项—证据—判定—结论—跟踪”链条，替换交付物、检查项内容、评审角色和终止触发条件；检查项按是否阻断进入下一阶段筛选。
- 示例为演示情景，适用于阶段性继续或终止决策，不覆盖单次发布许可与单需求评审；阈值、角色和检查项数量需结合组织情况调整。
这份示例要解决什么：阶段准入标准的目标与结构
阶段准入标准服务于阶段结束时的去留判断。它与发布审批、单需求评审处理的是不同层面的问题：发布审批决定某一次版本能否对外交付，单需求评审决定某个需求是否进入开发或能否验收，阶段准入标准则决定一个研发阶段整体是否达到进入下一阶段的条件。三者可以共用部分检查项，但决策对象和决策人不同，不能相互替代。
一份可用的阶段准入标准由四部分组成，每部分承担不同的判断任务：
| 组成部分 | 承担的判断任务 | 缺失时的典型后果 |
|---|---|---|
| 阶段目标与交付物 | 明确本阶段要达成什么、应产出哪些成果 | 评审时说不清“完成”指什么，讨论发散 |
| 准入检查项与判定口径 | 把目标拆成可逐项判定的条件，并规定证据 | 凭印象打分，结论难以复核 |
| 评审角色与决策权限 | 规定谁提供信息、谁评审、谁拍板 | 评审开完无人决策，或决策人不掌握信息 |
| 结论类型与后续动作 | 区分继续、带条件继续、终止，并规定各自动作 | 结论只有“通过/不通过”，中间状态无处安放 |
四部分之间存在依赖关系：交付物清单决定检查项的范围，检查项的证据要求决定评审需要哪些角色到场，结论类型决定会后要跟踪什么。填写时应按这个顺序推进，先定目标和交付物，再写检查项，最后确定角色与结论规则。
完整示例：某研发阶段准入标准填写样例
以下为演示情景，用于说明填写方式，不代表任何真实客户案例。设定背景：一个约十五人的产品研发团队，采用迭代式开发，当前处于“方案设计阶段”结束、准备进入“开发实施阶段”的节点，需要召开阶段评审会决定是否准入。
阶段目标与应交付物
阶段目标：完成本期核心功能的方案设计，使开发团队具备直接进入编码的条件。应交付物清单如下：
- 需求说明文档（含范围界定与验收要点）
- 技术方案文档（含关键模块设计、接口约定、风险点）
- 交互与视觉稿（覆盖本期全部页面）
- 测试策略草案（含测试范围与主要验证方式）
- 排期与资源计划（含人力投入与关键里程碑）
准入检查项与判定口径
| 编号 | 检查项 | 判定口径 | 证据要求 |
|---|---|---|---|
| C1 | 需求范围已冻结 | 本期范围清单经产品负责人确认，无待定条目 | 需求文档版本记录与确认记录 |
| C2 | 技术方案覆盖全部核心模块 | 方案文档中每个核心模块均有设计说明与接口定义 | 方案文档评审记录 |
| C3 | 设计稿完整 | 本期页面清单与设计稿一一对应，无缺页 | 页面清单与设计稿对照表 |
| C4 | 主要技术风险已识别并有应对 | 风险清单中每项均标注影响与应对措施 | 风险清单 |
| C5 | 测试策略可执行 | 测试范围与本期需求范围一致，验证方式明确 | 测试策略草案 |
| C6 | 排期与资源匹配 | 排期覆盖全部交付物，人力投入与任务量匹配 | 排期表与资源计划 |
评审角色与决策规则
- 信息提供方：产品经理、技术负责人、设计师、测试负责人，各自对本领域检查项提供证据并说明。
- 评审参与方：上述角色加项目负责人，逐项给出“满足/部分满足/不满足”的判断。
- 决策人：项目负责人。涉及范围变更的检查项，需产品负责人共同确认。
- 决策规则：全部检查项满足则继续；存在部分满足项且不影响开发启动的，可带条件继续；核心检查项（C1、C2）不满足，或存在无法在短期内消除的阻断性风险的，终止本阶段并回到方案设计。
三种评审结论示例
| 情形 | 检查结果 | 结论 | 后续动作 |
|---|---|---|---|
| 情形一 | C1至C6全部满足 | 继续 | 进入开发实施阶段，按排期启动 |
| 情形二 | C1至C5满足，C6排期未覆盖性能测试任务 | 带条件继续 | 开发启动，两周内补齐性能测试排期，由测试负责人跟踪，下次阶段例会复核 |
| 情形三 | C2技术方案缺少核心模块接口定义，且短期内无法补齐 | 终止 | 回到方案设计阶段，补齐接口定义后重新提交评审 |
逐项解释：每个字段为什么这样填
检查项要写成可判定的条件，关键是让不同的人看同一项能得出相同判断。“需求范围已冻结”之所以可判定，是因为它指向一个可核对的对象——范围清单及其确认记录；如果写成“需求基本明确”，评审时就会变成各人理解之争。判定口径应尽量包含判断对象、判断标准和完成标志三要素，例如C3的“页面清单与设计稿一一对应，无缺页”，对象是两份材料，标准是一一对应，标志是无缺页。
证据要求的作用是防止口头确认代替事实。每一条检查项都应指向一份可查阅的材料：文档、记录、清单或对照表。填写时可以自问：如果评审当天提出质疑，我能否当场调出这份材料？调不出，说明证据要求还没写到位。证据不必复杂，但必须与检查项直接对应，C4对应风险清单，C5对应测试策略草案，一一挂钩。
决策权限要与结论类型配套设计。常见的问题是评审会上人人发表意见，散会后无人拍板。示例中把决策人明确为项目负责人，同时规定涉及范围变更时需产品负责人共同确认，这样既保证有人最终负责，又在关键事项上引入必要的共同决策。决策规则要写清什么情况对应什么结论，尤其是终止的触发条件，避免评审沦为形式上的通过。
带条件继续是最容易被写虚的结论。条件必须记录三件事：条件内容（补齐什么）、责任人（谁负责）、复核时点（何时检查）。示例中情形二把这三项都写进了后续动作，条件才有可跟踪性。如果条件只写在会议纪要的一句话里，没有责任人和时点，实际上等同于无条件通过。
评审结论和条件跟踪需要落到可查的记录上。在ONES中，阶段评审的结论可以作为工作项状态流转的依据，带条件继续所记录的条件内容、责任人与复核时点可以挂在对应工作项或评审记录上，下次例会直接按记录复核，减少靠纪要翻找的情况。具体字段设置需结合团队已有的工作项类型调整。
可迁移规律：换一个阶段怎么改
示例中真正可复用的是这条链条：检查项—证据—判定—结论—跟踪。换阶段时，这条链条的结构保持不变，变化的是链条上挂载的具体内容。开发实施阶段结束时，交付物换成可运行版本、测试报告、上线方案，检查项相应改为功能完成度、缺陷收敛情况、上线准备就绪度；评审角色中测试和运维的分量上升；结论规则中终止的触发条件改为阻断性缺陷或上线条件不具备。
| 要素 | 保留 | 随阶段替换 |
|---|---|---|
| 结构 | 四部分框架与检查项—证据—判定—结论—跟踪链条 | — |
| 交付物 | 清单化管理、逐项对应检查项 | 具体交付物名称与范围 |
| 检查项 | 可判定条件加证据要求的写法 | 检查内容、判定口径、阈值 |
| 评审角色 | 信息提供、评审、决策三层分工 | 具体角色与决策人 |
| 结论规则 | 继续、带条件继续、终止三类 | 终止触发条件与条件跟踪方式 |
检查项数量需要控制。示例给出六项，覆盖范围、方案、设计、风险、测试、资源六个方面，基本对应一个设计阶段结束时的关键判断。检查项过多会让评审变成逐条念材料，过少则容易漏掉关键风险。一个实用的做法是先列出所有候选检查项，再按“不满足是否足以阻断进入下一阶段”筛一遍，保留真正影响去留的条目，其余作为参考信息在评审材料中呈现，不进入判定。优先级上，把直接决定能否启动下一阶段工作的检查项定为核心项，其余定为一般项，核心项不满足即触发终止或带条件继续。
适用边界：这套示例在什么情况下需要调整
这套示例适用于阶段性继续或终止决策，即一个研发阶段整体结束、需要判断是否进入下一阶段的场景。它不覆盖单次发布许可——某版本能否对外发布由发布审批和质量门禁决定；也不覆盖单需求评审——某个需求是否进入开发或能否验收，由需求评审流程处理。把三类决策混在一张表里，会导致检查项失焦、决策人不清。
团队规模和研发模式变化时，调整方向不同。小团队可以压缩检查项数量、合并评审角色，由一人兼信息提供与决策，但证据要求不宜省略；多团队协作或跨部门交付时，需要增加接口约定、依赖确认类检查项，并明确跨团队决策人的权限边界。研发模式方面，迭代节奏快的团队可以把阶段评审与迭代评审合并召开，但结论类型和条件跟踪仍应保留；采用瀑布或强阶段门禁的组织，则需要更严格的证据归档要求。
合规要求较高的组织，通常需要在证据要求中补充审计留痕、审批签字或独立复核环节，检查项也可能增加安全、隐私、合规审查类条目。这些调整应基于组织实际承受的监管要求确定，不宜照搬其他组织的阈值。示例中的六项检查项、十五人团队规模、两周补齐排期等取值均为演示设定，实际使用时，阈值、角色分工和终止触发条件需结合本组织的交付节奏、风险偏好和决策习惯确定，并在使用一两个阶段后根据评审实际效果修订。
常见问题
阶段准入标准和发布审批、需求评审有什么区别，能不能合并成一张检查表？
三者决策对象不同：阶段准入标准决定一个研发阶段整体是否进入下一阶段，发布审批决定某一次版本能否对外交付，需求评审决定某个需求是否进入开发或能否验收。可以共用部分检查项，但决策人和结论类型不同。合并成一张表容易导致检查项失焦、决策人不清，建议各自保留独立的判定表和决策规则，只在材料引用上互相衔接。
检查项写多少条合适？有没有可以参考的数量？
没有统一的行业数量口径，示例中的六项是演示设定。实用做法是先列出所有候选检查项，再按“不满足是否足以阻断进入下一阶段”筛一遍，保留真正影响去留的条目，其余作为参考信息呈现在评审材料中、不进入判定。同时把直接决定能否启动下一阶段工作的条目定为核心项，核心项不满足即触发终止或带条件继续。检查项过多会让评审变成逐条念材料，过少则容易漏掉关键风险。
带条件继续的条件由谁跟踪，什么时候算关闭？
条件记录应包含三项：补齐什么、谁负责、何时复核。跟踪责任一般落在条件所属领域的负责人身上，由阶段决策人在下次阶段例会或约定的复核时点检查。条件关闭的判断标准是证据材料已补齐并通过确认，而不是口头说明已完成。如果条件到期未关闭，需要有明确的升级规则，例如重新提交阶段评审或转为终止处理，这条规则应在标准中提前写明。
小团队人手少，评审角色能不能由一个人兼任？
可以合并角色，例如由一人同时承担信息提供与决策，但证据要求不宜省略。角色合并改变的是谁到场，不改变“每项检查项有可查阅材料支撑”这一前提。需要注意的是，当决策人同时是信息提供方时，涉及范围变更或风险接受的检查项最好引入另一位负责人共同确认，避免自我评审。团队规模扩大或跨部门交付时，再按接口约定、依赖确认的需要补充角色。
标准用了一段时间后发现评审流于形式，应该改哪里？
先检查两个环节：一是检查项是否可判定，如果多项写成“基本明确”“大致完成”这类描述，评审就会变成理解之争；二是终止触发条件是否写清，如果标准里只有通过和不通过、没有终止的具体情形，评审容易默认放行。修订时可以回看前几个阶段的评审记录，找出反复出现争议的检查项，改写判定口径和证据要求，并根据实际效果调整核心项范围。建议使用一两个阶段后集中修订一次，而不是每次评审都临时改规则。
