研发阶段评审要回答的核心问题只有一个：本阶段成果是否足以支撑进入下一阶段。可执行的做法是先划分评审点、明确每个点的准入条件，再确定角色与决策权限，用统一材料包提交并逐项核对，形成继续、有条件继续或终止的结论，最后把结论与遗留项落到工作项中跟踪关闭。本文覆盖评审点、准入条件、角色权限、结论闭环与上线检查，发布审批、质量门禁和单需求评审不在展开范围内。
要点总览（TL;DR）
- 阶段评审的决策问题是本阶段成果是否足以进入下一阶段，结论分为继续、有条件继续、终止三类。
- 评审点按研发阶段设置，常见为概念、计划、开发、验证、发布前，数量与命名按项目类型和风险等级裁剪。
- 准入条件要写成可核对、可判定的条目，材料包包含阶段交付物、验证证据、风险与遗留项清单，并在会前提前分发。
- 决策权限事先明确到结论类型，决策人与提交人分开，决策人缺席时只能形成建议。
- 遗留项要有责任人、期限和关闭标准，并与工作项状态关联，到期未关闭触发升级。
阶段评审要决策什么：先划清评审点与决策边界
阶段评审点的划分依据是研发阶段本身，而不是职能部门的汇报周期。常见做法是在概念、计划、开发、验证、发布前五个位置设置评审点，每个点对应一个明确的决策问题：本阶段约定的成果是否已经具备，下一阶段是否可以启动。评审点数量与命名应结合项目类型、周期和风险等级裁剪，小项目可以合并概念与计划评审，高风险项目可以在开发与验证之间增加设计定型评审。
每个评审点的决策问题要写成一句话，让参会人在会前就知道要判断什么。可参考下表建立自己的评审点清单：
| 评审点 | 决策问题 | 典型输入 |
|---|---|---|
| 概念评审 | 需求价值、目标用户与可行性是否成立，是否值得投入资源进入计划阶段 | 需求说明、初步方案、可行性分析 |
| 计划评审 | 范围、进度、资源与风险应对是否可执行，是否批准进入开发 | 项目计划、资源安排、风险清单 |
| 开发评审 | 核心功能是否按设计完成，技术风险是否已收敛，是否进入验证 | 设计文档、代码或构建产物、自测记录 |
| 验证评审 | 测试覆盖与关键指标是否达标，遗留缺陷是否可接受，是否具备发布条件 | 测试报告、缺陷清单、性能与安全验证证据 |
| 发布前评审 | 发布范围、回滚方案与上线保障是否就绪，是否批准进入发布流程 | 发布清单、回滚预案、上线检查记录 |
边界要事先说清：阶段评审决定的是阶段性继续或终止，单次发布许可由发布审批决定，质量门禁是流水线或检查环节中的自动或半自动拦截规则，单个需求的确认属于需求评审。三者可以引用阶段评审的结论，但不替代阶段评审的决策。把边界写进评审制度，能减少会上讨论跑题和重复决策。
评审准入条件与材料包怎么定
准入条件是评审的判定依据，写法上要满足两个要求：可核对、可判定。可核对指评审人能在材料中找到对应证据；可判定指结论只有满足与不满足两种，不依赖主观感受。“核心功能基本完成”无法判定，“计划内的 12 个功能点全部提交自测记录，自测通过率 100%”可以判定。“质量良好”无法判定，“严重缺陷为 0，一般缺陷关闭率不低于 90%”可以判定。
每个评审点配一张准入条件表，条目控制在可管理的数量内，按交付物、验证证据、风险处置三类组织。材料包与准入条件一一对应，通常包括阶段交付物、验证证据、风险与遗留项清单三部分。材料应在会前提前分发，给评审人留出核对时间；临场才发的材料，评审往往只能听汇报。
| 类别 | 准入条件示例（验证评审点） | 对应材料 |
|---|---|---|
| 交付物 | 设计文档、接口说明已评审并归档 | 文档清单与评审记录 |
| 验证证据 | 关键指标测试全部执行，结果达到约定阈值 | 测试报告、指标对比数据 |
| 风险处置 | 高风险项均有处置结论或明确接受人 | 风险登记表、遗留项清单 |
准入条件不满足时，处理方式要在制度中预先约定，常见有三种：一是材料缺失或证据不足，评审延期，由提交人补齐后重新排期；二是条件部分满足但不影响下一阶段启动，转为“有条件继续”，未满足项进入遗留项跟踪；三是关键条件不满足且影响阶段目标，结论为终止或退回上一阶段。把三种处理方式写清楚，可以避免会上临时争论“算不算通过”。
评审角色、决策权限与会议组织
阶段评审需要四类角色：提交人负责准备材料包并在会上说明阶段成果；评审人负责按准入条件逐项核对并给出意见；决策人对结论拍板；记录人负责记录结论、遗留项和会议要点。角色可以由同一人兼任，但决策人与提交人应分开，避免自评自决。
决策权限要事先明确到结论类型。继续、有条件继续、终止三种结论的拍板人可以是同一人，也可以分级设置，例如有条件继续由项目负责人决定，终止由研发负责人或评审委员会决定。权限矩阵应写进制度并在每次评审前确认决策人是否到场，决策人缺席时评审只能形成建议，不能形成结论。
| 结论类型 | 建议决策人 | 前置要求 |
|---|---|---|
| 继续 | 项目负责人或阶段评审主持人 | 准入条件全部满足 |
| 有条件继续 | 项目负责人，重大条件升级至研发负责人 | 未满足项已明确责任人与期限 |
| 终止或退回 | 研发负责人或评审委员会 | 关键条件不满足，且有明确判定依据 |
会议组织上，材料提前分发是硬要求，通常提前一到两个工作日；会议时长按评审点复杂度控制，会上按准入条件逐项过，不逐页讲材料。记录人在会中同步形成结论草稿，散会前向参会人确认结论类型和遗留项，减少会后返工。
评审结论与遗留项如何闭环
评审结论有三种形态，每种对应不同的后续动作。继续：下一阶段工作项可以启动，评审记录归档。有条件继续：下一阶段可以启动，但未满足项转为遗留项，设定责任人与关闭期限，到期未关闭时触发升级。终止或退回：当前阶段工作项暂停或回退，明确返工范围与再次评审的时间。
遗留项要具备四个要素才算可跟踪：事项描述、责任人、关闭期限、关闭标准。关闭标准要写成可验证的条件，例如“补充完成接口压测报告并经架构师确认”，而不是“尽快处理”。遗留项清单建议与评审记录放在同一处，评审结论与相关工作项状态关联，让下一阶段的工作项能直接看到来自哪次评审、哪条遗留项。
在工具承载上，评审记录可以作为文档或工作项附件归档，遗留项建成独立工作项并关联原评审记录，责任人更新状态、关闭时附上证据，评审主持人按期限核对关闭情况。ONES 的工作项与文档管理可以承载这一流程：评审结论记录在文档中，遗留项作为工作项跟踪，状态变化和关闭证据留在同一处，便于回溯。具体配置方式按团队现有工作项体系设计即可。
一个阶段评审的完整示例
以下为演示情景，用于说明流程，不代表真实项目数据。某团队开发一个内部订单系统，在验证评审点组织阶段评审，决策问题是“测试覆盖与关键指标是否达标，是否具备发布条件”。
材料准备阶段，提交人按准入条件表整理材料包：测试报告覆盖计划内的功能用例与接口用例；性能测试记录显示关键接口响应时间达到约定阈值；缺陷清单列出严重缺陷为 0、一般缺陷剩余 3 个；风险登记表标注一项第三方支付接口联调风险，处置结论为“已与供应商确认联调时间，发布前完成”。材料在会前两天分发。
会上，评审人按准入条件逐项核对。功能与性能证据齐全，判定满足；一般缺陷剩余 3 个，其中 1 个影响对账准确性，判定为未满足但不阻塞发布；支付接口联调尚未完成，判定为关键条件未满足。决策人综合后给出“有条件继续”结论：允许进入发布准备，但支付接口联调必须在发布前完成并补充联调记录，对账缺陷在发布后两周内修复。
记录人将结论写入评审记录，两条遗留项分别建为工作项：联调项责任人为后端负责人，期限为发布前，关闭标准为联调记录归档并经测试确认；对账缺陷责任人为开发负责人，期限为发布后两周，关闭标准为修复上线并通过回归测试。评审主持人在发布前核对第一条遗留项的关闭情况，确认后才放行发布准备。整个过程的关键是：结论有依据、遗留项有责任人和关闭标准、关闭情况可核对。
评审机制上线前的完成检查
机制是否具备运行条件，可以用下面的清单逐项核对。全部满足即可上线试运行，试运行一到两个评审点后再根据实际执行情况调整。
- 评审点清单已确定，每个评审点写明了决策问题，并与发布审批、质量门禁、需求评审的边界做了区分。
- 每个评审点都有准入条件表，条目可核对、可判定，且与材料包内容一一对应。
- 材料包模板可用，包含阶段交付物、验证证据、风险与遗留项清单三部分，并规定了提前分发时间。
- 角色职责表已明确提交人、评审人、决策人、记录人，决策人与提交人分开。
- 决策权限矩阵已明确继续、有条件继续、终止分别由谁拍板，决策人缺席时的处理方式已约定。
- 评审记录模板可用，能记录结论类型、判定依据和遗留项四要素。
- 遗留项有明确责任人和关闭标准，并与工作项状态关联，到期未关闭有升级路径。
- 准入条件不满足时的三种处理方式已写入制度，团队对“算不算通过”有统一口径。
清单核对完成后，建议先在一个项目上试运行，观察评审会是否按准入条件逐项核对、遗留项是否按期关闭，再决定是否推广到全部项目。
常见问题
小项目阶段少、人手紧，评审点可以合并吗？
可以合并，但要保留每个评审点原本要回答的决策问题。例如把概念评审与计划评审合并为一次立项评审，会上仍需分别判断“需求价值与可行性是否成立”和“范围、进度、资源是否可执行”，两项都满足才能进入开发。合并后准入条件表也相应合并，条目按决策问题分组，避免因为合并而漏掉判定依据。
合并的边界是风险：高风险项目在开发与验证之间增加设计定型评审，比压缩评审点更稳妥。合并与否写进评审制度，并说明适用条件，团队按同一口径执行。
评审会上决策人临时缺席，结论还能生效吗？
按本文的权限设计，决策人缺席时评审只能形成建议，不能形成结论。处理方式有两种：一是会议改期，材料保留，重新确认决策人时间；二是由制度中预先指定的代理人到场决策，代理人需具备对应结论类型的拍板权限。两种方式都要在评审制度中写明，不能临场临时授权。
如果会议已经开完才发现决策人缺席，记录人应把会议结果标注为“建议结论”，由决策人在约定时间内书面确认后才转为正式结论，遗留项从正式结论生效时开始计时。
准入条件部分满足时，怎么判断该“有条件继续”还是“终止”？
判断依据是未满足项是否影响阶段目标。未满足项属于交付完整性或证据补充，且不影响下一阶段启动，可以给出“有条件继续”，同时明确责任人与关闭期限；未满足项涉及关键指标、核心功能或高风险项没有处置结论，影响阶段目标成立，应终止或退回上一阶段。
为减少临场争论，建议在准入条件表中把条目分为“关键条件”和“一般条件”两类，关键条件不满足即触发终止或退回，一般条件不满足可转遗留项。分类在评审前完成，会上只做核对。
遗留项到期没有关闭，应该怎么处理？
到期未关闭的遗留项应触发升级，而不是自动延期。常见做法是：到期前由责任人更新进展，到期仍未关闭时由评审主持人升级至决策人，由决策人判断是追加期限、调整下一阶段范围，还是暂停相关工作项。升级路径和时限在制度中预先约定。
遗留项的关闭要有证据，例如补充的报告、测试记录或确认意见，仅把状态改为“已关闭”不足以作为关闭依据。评审主持人按期限核对关闭情况，核对结果作为下一次阶段评审的输入之一。
阶段评审和发布审批、质量门禁之间怎么衔接？
三者管的事情不同：阶段评审决定阶段性继续或终止，发布审批决定单次发布是否许可，质量门禁是流水线或检查环节中的拦截规则。衔接方式是引用关系，发布审批可以引用最近一次阶段评审的结论和遗留项关闭情况，质量门禁的拦截结果可以作为验证评审点的证据之一。
衔接时要注意时间差：阶段评审通过后，发布前仍可能出现新的缺陷或风险，发布审批要基于当时的实际状态判断，不能直接沿用阶段评审结论放行。把这条写进制度，可以避免“评审过了就一定能发”的误解。
