阶段退出标准是一组在阶段结束前可逐项核验的判定条件，用来支撑继续、有条件继续或终止的决策。制定时先明确本阶段要交付什么、由谁验收，再把每项条件写成可观察的证据与通过阈值，配上责任角色、评审时点和未通过时的处置方式，最后用一次真实阶段评审试跑并修订。标准应聚焦阶段性去留判断，单次发布许可和单需求确认分别由发布审批与需求评审承担。
要点总览（TL;DR）
- 阶段退出标准由交付物完整性、质量与验证、风险与遗留问题、决策所需信息四类条件组成，每类都要落到可调取的证据和明确的通过阈值。
- 制定按五步推进：明确阶段目标与关键交付物、确定验收方式与证据载体、设定阈值与判定权、评审删减不可取证条目、试跑后版本化。
- 起草、核验、决策、记录四类角色职责分开写明，质量或技术评审意见独立于阶段负责人提交，决策结论写明依据并留档。
- 评审前完成证据提交与预检，会上逐条核对阻断条件，有条件通过须明确整改项、责任人与复核时点。
- 阻断条件数量保持克制，标准随阶段目标变化修订；单次发布许可和单需求确认不混入退出标准。
先定判定框架：退出标准由哪几类条件组成
一套阶段退出标准如果只写“完成开发”“质量达标”，评审会上就无法逐条核对，决策也容易变成印象判断。可行的做法是先把条件分成四类，再为每类规定证据形式，最后标出哪些是阻断条件、哪些是观察项。
四类条件的划分依据是“决策需要看到什么”：交付物是否齐全、质量是否经过验证、风险是否收敛、决策所需信息是否到位。四类都覆盖，阶段去留判断才有完整输入；只覆盖交付物完整性，容易把“东西交了”误当成“可以进入下一阶段”。
| 类别 | 条件描述示例 | 证据形式 | 阻断与否 |
|---|---|---|---|
| 交付物完整性 | 本阶段规定的设计文档、测试报告、业务计划书均已提交并处于已评审状态 | 文档清单及评审记录 | 阻断 |
| 质量与验证 | 关键需求对应的验证用例已执行，失败项已关闭或有明确处置结论 | 测试执行记录、缺陷清单 | 阻断 |
| 风险与遗留问题 | 高等级风险均有应对方案和责任人，遗留问题已登记并约定处理阶段 | 风险登记表、遗留问题清单 | 高等级风险阻断，中低等级可作观察项 |
| 决策所需信息 | 阶段决策材料包含范围、成本、进度与收益的评估结论 | 决策评审材料 | 阻断 |
写法上，每条条件都应落到“谁在什么载体上能看到什么”。例如把“技术方案基本确定”改写成“整体技术方案与各子系统设计已完成评审，接口一致性问题清单为零或已逐项关闭”，证据就是评审记录和接口问题清单。模糊表述的问题不在于不认真，而在于评审时无法判定通过与否。
阻断条件与观察项要分开标注。阻断条件未满足，阶段不能通过；观察项允许带条件通过，但必须写明整改内容、责任人和复核时点。阻断条件数量应保持克制，如果每条都是硬门槛，评审会容易陷入逐项争论，反而拖慢决策。
制定步骤：从阶段目标推导到可核验条目
制定退出标准可以按五步推进，每一步都有明确输入和输出，避免直接坐在会议室里凭经验列条目。
第一步：明确阶段目标与关键交付物。输入是本阶段的立项材料、业务计划或上一阶段决策结论；动作是列出本阶段必须产出的交付物和必须回答的问题；输出是一份交付物清单。这份清单是后续所有条件的来源，清单外的内容不进入退出标准。
第二步：为每项交付物确定验收方式与证据载体。输入是交付物清单；动作是逐项确认“用什么证明它完成了、由谁看、在哪里看”；输出是“交付物—验收方式—证据载体”对照表。证据载体可以是评审记录、测试报告、问题清单或决策材料，关键是评审时能当场调取。
第三步：设定通过阈值与判定口径，明确谁有权判定。输入是对照表；动作是为每项条件写出通过标准，例如“失败项为零”或“高等级问题全部关闭、中等级问题有处置计划”；同时指定该项条件的判定人；输出是带阈值和判定人的条件草案。阈值要写成可观察的状态，避免“大部分完成”这类需要现场解释的表述。
第四步：评审条件草案，删去无法取证或与阶段去留无关的条目。输入是条件草案；动作是组织阶段负责人、技术或质量角色、决策角色共同过一遍，逐条问“这条能不能取证”“这条是否影响去留判断”；输出是修订后的条件清单。与阶段去留无关的条目，例如日常代码规范细节，应移出退出标准，放回日常质量管理。
第五步：小范围试跑并修订，形成版本化标准。输入是修订后的条件清单；动作是在一次真实阶段评审中试用，记录哪些条目难以判定、哪些证据缺失；输出是带版本号和修订说明的正式标准。阶段目标变化时，标准随之修订，旧版本保留以便追溯。
角色与交付物：谁写、谁审、谁做去留决策
退出标准的制定和执行涉及四类角色，职责不清时最常见的问题是条件写了却没人准备证据，或者评审会上无人有权拍板。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 阶段负责人 | 起草退出条件，组织各交付物责任人准备证据，评审前完成自检 | 条件草案、证据包、自检记录 |
| 质量或技术评审角色 | 核验证据的真实性与完整性，判定质量与验证类条件是否通过 | 证据核验意见、技术条件判定结论 |
| 决策角色 | 依据评审结论作出继续、有条件继续或终止的决定，对例外放行负责 | 阶段决策结论及依据 |
| 记录角色 | 保存评审结论、遗留问题与后续跟踪项，维护标准版本 | 评审纪要、遗留问题清单、标准版本记录 |
四类角色可以由同一人兼任，但职责要分开写明。尤其是决策角色与起草角色重合时，要在评审记录中体现判定依据，避免“自己写条件、自己宣布通过”。质量或技术评审角色的核验意见应独立于阶段负责人提交，这样决策角色看到的是经过核验的证据，而非单方陈述。
示例：一个阶段退出标准条目如何写成
下面以“技术方案评审”为例，展示从模糊要求到可核验条目的改写。假设某研发项目处于计划阶段末，需要判断能否进入开发阶段。
改写前：“技术方案基本完成，具备进入开发阶段的条件。”
改写后（阻断条件）：“整体技术方案及各子系统设计已完成评审，评审记录中遗留的接口一致性问题为零，或剩余问题均已标注责任人与关闭时点并经技术评审角色确认。”
这条条件的证据来源是技术评审记录和接口问题清单；判定人是技术评审角色；通过阈值是“接口一致性问题为零，或剩余问题有责任人与关闭时点且经确认”；未通过时的处置是回到方案修订，修订后重新提交评审，不进入开发阶段。
同一阶段的观察项示例：“部分非关键子系统的设计文档已完成初稿，正式评审安排在开发阶段前两周内完成。”这条不阻断阶段通过，但需在决策结论中记录整改责任人和复核时点。
两类条目组合使用，评审会上的讨论就有明确焦点：先逐条核对阻断条件，再确认观察项的整改安排。阻断条件决定去留，观察项管理后续风险，二者在同一张条件清单中分列标注即可。
评审与决策：让标准在阶段评审会上真正起作用
标准写得再细，如果评审会上才第一次看到证据，会议就会变成补材料现场。有效的做法是把证据提交和预检放在会前，把逐条核对和结论记录放在会上。
评审前，阶段负责人按条件清单提交证据包，质量或技术评审角色完成预检，标出缺失证据和存疑条目。预检结果提前发给决策角色，让会上时间用于讨论有争议的条件，而非逐页翻阅材料。
会上按条件清单逐条核对阻断条件，记录每条的状态：通过、有条件通过或未通过。有条件通过的条目，当场明确整改项、责任人和复核时点；未通过的阻断条件，直接进入终止或延期决策，不进入下一阶段。
决策结论要写明依据，包括通过了哪些条件、哪些条件带条件通过、哪些未通过，以及决策角色作出继续、有条件继续或终止判断的理由。结论与证据包一并留档，供后续阶段追溯和标准修订参考。遗留问题进入跟踪清单，在下一阶段评审时复核闭环情况。
在研发管理工具中承载这套流程时，可以把条件清单作为阶段评审的检查项，证据作为附件或关联工作项提交，评审结论和遗留问题形成可查询的记录。ONES 的 IPD 解决方案中，概念阶段通过评估需求覆盖范围、技术可行性与商业价值，决策项目进入计划阶段或终止；计划阶段的阶段决策评审基于评审结果批准业务计划书；开发阶段的技术评审结果决定产品是否具备转入量产的条件。这些阶段评审与决策节点可以作为退出标准落地的承载点，具体检查项和判定口径仍需按企业实际流程配置。
完成检查：标准是否可用的自检清单
一套退出标准在正式启用前，可以用以下清单逐项核对。任何一项不满足，都建议先修订再投入评审使用。
- 每条条件都能指出证据在哪里、由谁提供，评审时可以直接调取。
- 每条条件都有明确的通过阈值，判定人不需要在会上临时解释标准含义。
- 每条阻断条件都指定了判定人，且判定人与阶段负责人有清晰的责任区分。
- 阻断条件数量克制，观察项有独立的标注和整改跟踪方式。
- 条件清单与阶段目标对应，阶段目标调整时标准有修订记录和版本号。
- 未通过条件的处置方式已写明，包括返工、延期或终止的触发规则。
- 评审结论、遗留问题和复核时点形成可追溯的记录，并在下一阶段评审中复核闭环。
- 标准中不混入单次发布许可或单需求确认类条目，这类判断由发布审批和需求评审承担。
自检通过后，建议先用一次真实阶段评审试跑，观察哪些条目在实际讨论中难以判定，再据此修订。退出标准的可用性最终体现在评审会能否围绕条件快速形成去留结论，而非清单本身写得多完整。
常见问题
阶段退出标准和发布审批、需求评审的边界怎么划？
阶段退出标准回答的是“这个阶段能否结束、项目是否进入下一阶段”，判定对象是阶段性去留。发布审批关注某一次发布是否放行，需求评审关注单个需求是否确认，两者的判定对象和时点都不同。
实际操作中，可以把发布许可类条目从退出标准中移出，交给发布审批流程；把单需求确认类条目交给需求评审。退出标准只保留影响阶段去留的条件，评审会上的讨论焦点才不会被单次发布细节分散。
阻断条件设多少条比较合适？
没有统一数量，判断依据是“未满足时是否必须阻止进入下一阶段”。阻断条件过多，评审会容易陷入逐项争论；过少，则可能让关键风险被观察项掩盖。
可行的做法是先按四类条件列全，再逐条问“这条不满足，阶段还能不能继续”。答案是否定的列为阻断条件，其余列为观察项并写明整改责任人和复核时点。首次使用时通过一次真实评审试跑，观察哪些条目实际引发了争议，再据此调整。
阶段目标中途调整，退出标准怎么处理？
退出标准来源于阶段目标与关键交付物，目标变化时标准应同步修订。建议保留版本号和修订说明，旧版本存档以便追溯当时决策依据。
修订后需重新确认证据载体和判定人是否仍然适用，并在下一次阶段评审前完成预检。若调整发生在评审临近时，可先按原标准核对已满足部分，再对新增或变更条件单独安排复核时点。
评审会上发现证据缺失，应该延期还是带条件通过？
取决于缺失证据对应的条件类型。阻断条件缺少证据，无法判定是否满足，通常应延期评审或按未通过处理，不进入下一阶段；观察项缺少证据，可以带条件通过，但要在结论中写明补齐时限、责任人和复核时点。
为减少会上补材料的情况，评审前应由质量或技术评审角色完成预检，标出缺失证据和存疑条目，提前发给决策角色。预检做到位，会上时间才能用于讨论有争议的条件。
用研发管理工具承载阶段评审，重点看哪些能力？
重点看三件事：条件清单能否作为评审检查项逐条记录状态，证据能否以附件或关联工作项的方式随条件提交，评审结论和遗留问题能否形成可查询、可追溯的记录。
以 ONES 的 IPD 解决方案为例，概念阶段评估需求覆盖范围、技术可行性与商业价值，决策项目进入计划阶段或终止；计划阶段的阶段决策评审基于评审结果批准业务计划书；开发阶段的技术评审结果决定产品是否具备转入量产的条件。这些评审与决策节点可以作为退出标准的承载点，具体检查项和判定口径仍需按企业实际流程配置。
