研发阶段评审要解决的是“这个阶段能否继续”的决策问题。把评审组织成一次有输入、有角色、有决策、有记录的会议机制，需要先定触发点和决策类型，再明确谁主持、谁决策、谁记录，按固定议程逐项确认目标达成与风险，最后形成书面结论并跟踪遗留问题。以下按组织顺序展开。
要点总览（TL;DR）
- 阶段评审的触发点挂在阶段出口上，用交付物完成度、验证结果和遗留问题关闭情况组合判断，满足条件后由项目负责人发起评审。
- 评审结论收敛为继续、有条件继续、终止三类，并在规则中写明判定依据和批准权限，避免会上临时发挥。
- 主持、决策、汇报、记录、技术或质量评审五类职责分开，材料准入由主持人把关、汇报人准备，决策记录经记录人整理、主持人确认、决策人签批。
- 操作按会前材料预审、会中逐项确认、会后跟踪项闭环三段推进，每个跟踪项落到具体责任人、期限和验证方式。
- 用会前、会中、会后检查清单核对组织质量，决策有书面结论、条件项可跟踪、复核有节点三项同时满足才算完成。
阶段评审组织先定什么：触发点、决策类型与边界
组织阶段评审前，先要把三件事写进流程文件：什么时候必须开评审、评审可以做出哪几种结论、阶段评审与其他评审如何区分。这三项确定后，会议的时间、参与人和材料要求才有依据，否则容易出现“该开的没开、开了也定不了”的情况。
触发点与研发阶段划分对应
阶段评审的触发点应挂在阶段出口上，而不是挂在日历上。常见做法是：研发过程划分为若干阶段（如概念、计划、开发、验证、发布准备），每个阶段结束、下一阶段资源投入前设置一次阶段评审。触发条件可以写成组合判断：阶段交付物达到预定完成度、关键验证活动已有结果、上一阶段遗留的高优先级问题已关闭或已有处置方案。满足触发条件后由项目负责人发起评审申请，评审计划进入排期。
触发点还需要写明例外：阶段目标未达成但业务需要提前进入下一阶段时，仍应召开评审，按“有条件继续”处理，把未达成项转为带责任人和期限的跟踪项，而不是跳过评审直接推进。
三类决策的定义与适用情形
阶段评审的结论建议收敛为三类，并在规则中写明判定依据和批准权限，避免会上临时发挥。
| 决策类型 | 定义 | 适用情形 | 后续动作 |
|---|---|---|---|
| 继续 | 阶段目标达成，风险可控，批准进入下一阶段 | 关键交付物完成、验证结果符合预期、无阻断级遗留问题 | 释放下一阶段资源，遗留低优先级事项按常规跟踪 |
| 有条件继续 | 允许进入下一阶段，但须在限定时间内完成指定整改项 | 存在未关闭的重要问题，但不影响下一阶段启动；或部分目标延后达成 | 列出条件项、责任人、完成期限和验证方式，到期复核 |
| 终止 | 不批准进入下一阶段，阶段工作需返工、调整范围或暂停 | 关键目标未达成且无可行补救方案；出现重大技术或质量风险；外部条件发生根本变化 | 明确返工范围与重新评审时间，冻结下一阶段投入 |
批准权限要与决策类型匹配。例如“继续”可由阶段评审决策人签批，“终止”或涉及范围重大调整的“有条件继续”需要上升到项目指导层或更高管理者确认。权限写清楚，评审结论才具备执行力。
与发布审批、需求评审的边界
三类评审回答的问题不同，流程文件应显式区分。阶段评审回答“是否进入下一阶段”，关注阶段目标达成、资源投入和整体风险；发布审批回答“本次发布是否放行”，关注版本内容、质量门禁和上线准备；需求评审回答“单个需求是否确认”，关注需求本身的价值、范围和可实现性。边界清晰后，阶段评审会上就不必逐条讨论单个需求的细节，只需确认需求集合的整体状态和遗留风险。
评审角色与交付物怎么分工
阶段评审流于形式，常见原因是角色重叠：汇报人同时是决策人，记录人由汇报人兼任，会上没人对材料质量负责。把主持、决策、汇报、记录、技术或质量评审五类职责分开，并明确每类角色在会前、会中、会后的交付物，评审才有制衡。
| 角色 | 会前职责 | 会中职责 | 会后职责 | 主要交付物 |
|---|---|---|---|---|
| 评审主持人 | 确认触发条件满足、确定议程与参会人、检查材料是否达到准入条件 | 控制议程与时间，逐项引导确认，确保每个议题有结论 | 确认会议记录定稿，推动决策发布 | 评审通知、议程、会议记录确认 |
| 决策人 | 了解阶段目标与关键风险，必要时提前阅读材料 | 对继续、有条件继续、终止作出判断并说明依据 | 签批决策结论，对条件项和资源调整负责 | 书面决策结论 |
| 汇报人（项目负责人） | 按模板准备阶段报告，提交交付物清单和风险清单，完成预审问题答复 | 陈述目标达成情况、偏差原因和下一步计划，回答质询 | 承接决策后的任务分派，更新计划 | 阶段报告、交付物清单、风险与遗留问题清单 |
| 记录人 | 准备记录模板，熟悉议程和议题顺序 | 记录讨论要点、结论、条件项和反对意见 | 整理会议记录，录入跟踪项并分派责任人 | 会议记录、跟踪项清单 |
| 技术或质量评审人 | 对关键技术方案、验证结果、质量数据进行专业预审 | 就技术可行性和质量风险给出专业意见 | 对整改项提供验证口径 | 专业评审意见、验证结论 |
材料准入条件由谁把关
评审材料应在会前设定准入条件，由主持人把关、汇报人负责准备。准入条件通常包括：阶段目标与实际的对照说明、关键交付物及其完成状态、验证或测试结果、风险清单及应对措施、上一阶段遗留问题的关闭情况。材料未达准入条件的议题，不进入决策环节，只在会上做风险通报并约定补充评审时间。这样既保护决策质量，也避免会议被材料补交拖长。
决策记录与跟踪项的责任归属
决策记录由记录人整理、主持人确认、决策人签批，三者缺一不可。跟踪项的责任归属要落到具体的人，而不是部门：每个条件项写明责任人、完成期限、验证方式和验证人。汇报人对条件项的执行负责，主持人在下一阶段入口处复核关闭情况。责任归属写进记录，后续复核才有依据。
一次阶段评审的操作步骤
把阶段评审拆成会前、会中、会后三段，每段给出输入、动作、输出和完成标志，组织者可以按清单推进，也便于判断评审是否真正走完。
会前：材料提交与预审
- 输入：阶段计划、交付物清单、验证结果、风险清单、上一阶段遗留问题清单。
- 动作：汇报人按模板提交阶段报告；主持人检查材料是否满足准入条件；技术或质量评审人完成专业预审并反馈问题；汇报人答复预审问题或补充材料；主持人确认议程和参会人，发出评审通知。
- 输出：达到准入条件的评审材料包、预审意见及答复、评审通知与议程。
- 完成标志：材料齐全且预审问题已答复，议程和参会人确认，评审按计划排期。
会中：议程与逐项确认
- 输入：评审材料包、议程、记录模板。
- 动作：主持人按议程推进，先由汇报人陈述阶段目标达成情况和偏差原因，再由技术或质量评审人给出专业意见，随后逐项确认关键交付物状态、风险应对和遗留问题；对每个议题形成明确结论，未达成一致的记录分歧和待补信息。
- 输出：各议题的确认结果、待决事项清单。
- 完成标志：议程内每个议题都有结论或明确的待决安排，无议题被跳过。
会中到会后：决策形成与记录
- 输入：各议题确认结果、决策权限规则。
- 动作：决策人依据确认结果作出继续、有条件继续或终止的判断并说明依据；记录人当场记录结论、条件项和反对意见；主持人与决策人核对记录要点。
- 输出：书面决策结论、会议记录初稿。
- 完成标志：决策类型明确、依据可追溯、条件项有责任人和期限，决策人签批。
会后：遗留问题与跟踪项闭环
- 输入：会议记录、条件项清单。
- 动作：记录人整理会议记录并分派跟踪项；汇报人把条件项纳入下一阶段计划；主持人在约定节点复核关闭情况，未关闭项升级处理。
- 输出：定稿会议记录、跟踪项清单及状态更新。
- 完成标志：所有跟踪项有责任人和期限，到期复核有结论，下一阶段入口处完成关闭情况检查。
当评审的触发、材料提交、决策记录和跟踪项需要在同一处流转时，可以把这些动作放到研发管理工具中承载：阶段评审作为工作项类型设置触发条件和准入检查，材料以文档形式关联到评审，决策结论和条件项记录在评审单上，跟踪项转为任务并保留责任人和期限，下一阶段入口处按状态复核。ONES 可以在项目与工作项层面承载这类评审流程，具体配置方式按团队现有流程设计。
示例：一个阶段评审从发起到闭环
以下为演示情景，用于说明组织方式，不对应真实项目。
情景：某研发项目完成开发阶段，准备进入验证阶段。阶段目标为完成核心模块开发并通过单元测试，交付物包括模块代码、单元测试报告、接口文档和风险清单。
会前：项目负责人提交阶段报告，说明核心模块开发完成，单元测试覆盖率达标，但有一个性能指标未达预期，接口文档有两处待更新。主持人检查材料后认为满足准入条件，安排技术评审人对性能问题做预审。预审反馈该性能问题不影响验证阶段启动，但需要在验证阶段前两周内完成优化。主持人发出评审通知，参会人包括决策人、技术评审人、质量评审人和记录人。
会中：汇报人陈述目标达成情况和性能偏差原因；技术评审人确认优化方案可行；质量评审人确认单元测试结果有效。逐项确认后，决策人作出“有条件继续”的判断：批准进入验证阶段，条件为两周内完成性能优化并更新接口文档，责任人为项目负责人，验证人为技术评审人。记录人当场记录结论、条件项和期限，主持人与决策人核对记录要点。
会后：记录人整理会议记录并录入两个跟踪项；项目负责人把条件项纳入验证阶段计划；两周后主持人复核，性能优化完成并附验证结论，接口文档更新完成，两个跟踪项关闭。验证阶段入口检查通过。
这个示例的关键在于：决策类型与条件项同时形成，条件项有责任人和验证人，复核发生在下一阶段入口处，评审结论真正影响了资源投入和计划安排。
评审组织完成检查
用下面的清单核对一次阶段评审的组织质量。清单分为会前、会中、会后三段，并标出阻断项：阻断项未满足时，评审不应进入决策环节。
| 阶段 | 检查项 | 是否阻断 |
|---|---|---|
| 会前 | 触发条件已满足并有记录 | 是 |
| 会前 | 阶段目标、交付物状态、验证结果、风险清单齐全 | 是 |
| 会前 | 预审问题已答复或已列入待决事项 | 是 |
| 会前 | 主持人、决策人、汇报人、记录人、技术或质量评审人已确认 | 是 |
| 会前 | 议程和参会人已通知 | 否 |
| 会中 | 议程内每个议题有结论或明确待决安排 | 是 |
| 会中 | 决策类型明确且符合权限规则 | 是 |
| 会中 | 条件项有责任人、期限和验证方式 | 是 |
| 会中 | 反对意见和分歧已记录 | 否 |
| 会后 | 会议记录定稿并经决策人签批 | 是 |
| 会后 | 跟踪项已分派并纳入下一阶段计划 | 是 |
| 会后 | 下一阶段入口处完成跟踪项关闭情况复核 | 是 |
完成条件可以概括为：决策有书面结论、条件项可跟踪、复核有节点。三项同时满足，一次阶段评审才算组织完成；任一阻断项缺失，应先补齐再推进下一阶段，避免评审结论悬空。
常见问题
阶段目标没达成，但业务要求提前进入下一阶段，评审该怎么处理？
仍应召开阶段评审，按“有条件继续”处理。把未达成项转为带责任人、完成期限和验证方式的跟踪项，在记录中写明提前进入的理由和风险应对，由决策人签批。跳过评审直接推进，会让下一阶段的资源投入缺少书面依据，后续复核也没有对照点。
阶段评审的决策人和项目负责人可以是同一个人吗？
建议分开。汇报人同时担任决策人，会让评审失去制衡，材料质量和结论判断都缺少独立把关。如果团队规模小、人员确实有限，至少应把记录人独立出来，并明确决策人对结论签批负责；涉及终止或范围重大调整的结论，按权限规则上升到更高管理者确认。
评审材料没准备好，会议要不要照常开？
材料未达准入条件的议题不进入决策环节。可以按计划开会，但只做风险通报并约定补充评审时间，会上不形成继续或终止的结论。这样既保留会议节奏，也避免在信息不全的情况下作出阶段决策。主持人应在会前检查材料，把不满足条件的议题提前告知参会人。
“有条件继续”的条件项到期没完成，怎么办？
由主持人在约定节点复核，未关闭项升级处理：评估对下一阶段的影响，决定是否暂停相关投入、调整期限或重新提交评审。条件项在录入时就应写明责任人和验证人，到期复核有明确结论，避免条件项长期挂起、评审结论实际失效。
阶段评审和发布审批能不能合并成一次会议？
两者回答的问题不同，合并容易让阶段决策被版本细节淹没。阶段评审关注是否进入下一阶段，发布审批关注本次发布是否放行。若时间紧张需要合并，应在议程中分段，先完成阶段决策并形成书面结论，再进入发布放行讨论，两类结论分别记录，避免相互替代。
