判断产品原型评审是否充分，可以用一组可核验的准出条件代替主观感觉：关键角色到齐并确认过方案、核心流程与异常分支都有原型覆盖、待决问题收敛到可接受数量且都有负责人和期限、高风险假设已有验证结论或明确的开发前验证安排、评审记录与结论可追溯。全部条件满足且无阻断项，才判定可以进入开发；存在未关闭的阻断项时，即使评审会开过多次，也仍属未充分。
要点总览（TL;DR）
- 判断原型评审是否充分，看的是准出条件是否满足：阻断项清零、关键流程与关键角色覆盖到位、待决问题收敛且有负责人和期限、高风险假设有验证结论或开发前验证安排、评审记录可追溯。
- 用四个指标支撑判定：原型覆盖率、角色覆盖率、问题收敛率、未关闭阻断项数量。前两个通常要求100%，收敛率可设阈值，阻断项必须为0。
- 指标分母在评审启动前冻结，取数依赖评审记录、问题清单、原型版本与变更记录、角色确认记录；无记录按未覆盖或未关闭计，不视为已通过。
- 判定按四步执行：核对原型与关键流程清单、统计指标、逐项核对阻断项、给出通过/带条件通过/不通过结论并记录依据。
- 指标达标只说明评审过程完整，不证明方案正确；参与者同质化、问题定义过粗会抬高指标，进入开发后仍需持续验证。
评审充分性要回答的准出问题
“评审是否充分”容易被理解成会议开得够不够、讨论时间长不长。真正需要判定的是原型方案本身：它覆盖了哪些业务范围、哪些关键问题已经形成结论、哪些问题还悬着。把这个问题转化为准出问题，判定才有统一口径。
准出判断的对象包括两部分。一是原型覆盖的方案范围，即本次要进入开发的功能涉及哪些关键流程、角色和异常分支，原型是否逐一对应。二是待决事项，即评审中提出的问题是否都有明确去向：已关闭、已转为开发前任务、或经确认不影响开发。会议次数、参会人数、讨论时长可以作为过程信息记录，不进入准出结论。
准出问题清单建议按阻断与非阻断两类组织：
| 类别 | 准出问题 | 判定要求 |
|---|---|---|
| 阻断项 | 核心流程是否存在未出原型的关键环节 | 必须全部覆盖，缺一项即不通过 |
| 阻断项 | 关键角色是否确认过与其相关的方案 | 应参与角色全部确认，缺席需有书面委托或补充确认安排 |
| 阻断项 | 是否存在未关闭的高风险假设 | 有验证结论，或已排定开发前验证任务并明确负责人与期限 |
| 阻断项 | 未关闭的阻断级评审问题数量 | 必须为0 |
| 非阻断项 | 一般性评审问题是否收敛 | 可带条件放行，但每项须有负责人和关闭期限 |
| 非阻断项 | 文案、交互细节等低风险待定项 | 可转入开发过程中迭代，需登记在案 |
区分两类问题的意义在于：阻断项决定能否进入开发，非阻断项决定进入开发后需要带着哪些待办。把所有问题都当成阻断项，评审会无限延长；把所有问题都当成非阻断项，风险会直接流入开发。
用哪些指标衡量评审覆盖与收敛
准出问题需要落到可计算的指标上，才能在不同项目之间保持一致的判断。建议使用四个指标，两个衡量覆盖，两个衡量收敛。所有指标的分母都应在评审启动前确定，避免事后调整分母让结果看起来更好。
| 指标 | 公式 | 分母口径 | 时间窗 | 单位 |
|---|---|---|---|---|
| 原型覆盖率 | 已出原型的关键流程数 ÷ 应覆盖的关键流程数 | 评审前确认的关键流程清单，含主要异常分支 | 截至准出判定时 | 百分比 |
| 角色覆盖率 | 已确认方案的关键角色数 ÷ 应参与角色数 | 评审前确认的应参与角色清单，含业务、技术、运营等相关方 | 截至准出判定时 | 百分比 |
| 问题收敛率 | 已关闭的需处理问题数 ÷ 评审提出且需处理的问题数 | 剔除重复、无效和明确不处理的问题后的有效问题数 | 本次评审周期内 | 百分比 |
| 阻断项数量 | 未关闭阻断项计数 | 不设分母，直接计数 | 截至准出判定时 | 个 |
原型覆盖率和角色覆盖率的目标值通常设为100%，因为关键流程缺失或关键角色未确认会直接影响开发输入完整性。问题收敛率不要求100%，但需要设定一个可接受阈值，例如90%以上，且剩余问题全部为非阻断项并已登记负责人和期限。阻断项数量是硬条件，必须为0。
指标定义要写清楚“关键流程”和“关键角色”的认定方式。关键流程一般指直接承载核心业务目标、涉及跨系统交互或存在复杂异常处理的流程；关键角色指对方案有确认权或依赖方案开展下游工作的角色。认定清单在评审启动会上确认并冻结，后续新增需走变更记录。
数据从哪里取、证据怎么留
指标能否复核，取决于数据来源是否稳定。建议从四类记录取数：评审记录、问题清单、原型版本与变更记录、角色确认记录。每类记录都要能对应到具体版本和时间，避免用口头结论替代书面证据。
- 评审记录：记录每次评审的参与角色、讨论议题、形成的结论和遗留事项，作为角色覆盖率和问题来源的依据。
- 问题清单：逐条记录问题描述、提出人、严重级别、负责人、期限和关闭状态，作为问题收敛率和阻断项计数的依据。
- 原型版本与变更记录：标明每次评审对应的原型版本，记录评审后修改了哪些页面或流程，作为原型覆盖率的依据。
- 角色确认记录：关键角色对相关方案的确认意见，可以是评审会签、书面回复或系统内的确认状态，作为角色覆盖率的依据。
定性证据同样需要留痕。高风险假设的验证结论应写明验证方式、样本范围、结论和剩余风险；开发前验证安排应写明验证任务、负责人、完成时间和验证不通过时的应对方案。这些内容无法用指标概括，但属于准出判断的必要输入。
缺失数据的处理原则是：无记录不视为已通过。某角色没有确认记录，角色覆盖率按未覆盖计；某问题没有关闭记录，按未关闭计；某流程没有原型版本对应，按未覆盖计。缺失本身应作为待补事项登记，补齐后再重新判定。评审问题清单、原型版本和结论记录如果分散在多个工具里，复核成本会明显上升。ONES 可以在工作项中承载评审问题、在文档中留存评审结论与原型版本说明，让问题状态和准出依据在同一处可查，便于判定时直接取数。
判定步骤：从取数到给出准出结论
为了让不同评审主持者得到一致结论，判定过程建议固定为四步，每步留下记录。
第一步，核对原型与关键流程清单的对应关系。取出评审前冻结的关键流程清单，逐项确认是否有对应原型、原型版本是否为最新、异常分支是否有体现。输出一张对照表，标记覆盖、部分覆盖和未覆盖。
第二步，统计覆盖类与收敛类指标。按上一节的公式计算原型覆盖率、角色覆盖率、问题收敛率和未关闭阻断项数量。计算时注明数据截止时间，避免用评审中途的快照得出最终结论。
第三步，逐项核对阻断项是否清零。阻断项包括未覆盖的关键流程、未确认的关键角色、未关闭的高风险假设和未关闭的阻断级问题。逐项确认状态，任何一项未清零即判定不通过。
第四步，给出结论并记录依据。结论分三种：通过，所有阻断项清零且覆盖类指标达到目标值；带条件通过，阻断项清零但存在已登记负责人和期限的非阻断遗留项；不通过，存在未清零的阻断项。结论记录应包含判定时间、数据截止时间、各指标数值、阻断项核对结果、遗留项清单和判定人。
结论记录格式可以简化为一段固定结构：判定结论、指标快照、阻断项核对表、遗留项及期限、下次复核时间。这样后续追溯时不需要重新翻找散落的会议记录。
一个判定示例：从指标到准出结论
以下为演示情景，数字用于说明计算方法，不代表通用达标线。
某功能模块计划进入开发，评审前冻结的关键流程清单共8条，应参与关键角色5个。评审周期内提出需处理问题24条，截至判定时已关闭22条，其中阻断级问题3条已全部关闭，剩余2条为非阻断项，均已指定负责人和两周内关闭期限。原型方面，8条关键流程中7条有完整原型，1条异常分支流程仅有文字描述、未出原型。角色方面，5个关键角色中4个已确认，技术负责人尚未给出确认意见。
| 指标 | 计算 | 结果 | 对照要求 |
|---|---|---|---|
| 原型覆盖率 | 7 ÷ 8 | 87.5% | 未达100%，存在阻断项 |
| 角色覆盖率 | 4 ÷ 5 | 80% | 未达100%，存在阻断项 |
| 问题收敛率 | 22 ÷ 24 | 91.7% | 达到设定阈值，剩余为非阻断项 |
| 未关闭阻断项 | 直接计数 | 2个（未覆盖流程、未确认角色） | 要求为0，未满足 |
按四步判定：第一步对照发现1条流程未覆盖、1个角色未确认；第二步指标如上；第三步阻断项核对有2项未清零；第四步结论为不通过。补齐该异常分支原型并取得技术负责人确认后重新判定，若其余条件不变，原型覆盖率和角色覆盖率均达到100%，阻断项清零，问题收敛率保持91.7%且剩余2项为非阻断遗留项，结论可改为带条件通过。
分母为零的情况需要单独说明。假设该模块不涉及某类外部系统对接流程，相关流程清单为空，此时原型覆盖率的分母为0，不能按100%处理，应记为“未定义/未评估”，并在判定记录中说明该类流程不适用。如果是因为清单尚未梳理导致分母为零，则应先补齐清单再判定，不能跳过。
解读与限制：指标达标不等于方案无风险
覆盖率和收敛率反映的是评审过程的完整性：关键内容是否被看过、关键角色是否表过态、提出的问题是否被处理。它们不直接证明方案本身正确。一个流程有原型、有确认记录，仍可能在真实业务量、权限边界或异常并发下暴露设计缺陷。
指标还可能被过程因素抬高。评审参与者如果来自同一职能、背景相近，角色覆盖率看起来很高，但缺少业务、技术、运营等不同视角的交叉检验，问题发现能力有限。问题定义过粗也会让收敛率虚高：把多个子问题合并成一条记录，关闭一条就减少一个分子，实际遗留的细节并未处理。判定时应抽查问题清单的颗粒度，确认关闭理由是否具体。
单次指标达标不能替代开发过程中的持续验证。原型评审解决的是方案层面的方向性和完整性问题，进入开发后仍需通过技术方案评审、联调验证、验收测试等环节持续检验。高风险假设即使已有验证结论，也要明确结论的适用范围，避免把一次小样本验证当成普遍成立的依据。
因此，准出结论应同时记录指标结果和判定人的判断依据。指标用于保证判定过程一致、可复核，判断依据用于说明指标之外的风险考量。两者结合，才能让“可以进入开发”这个结论既不过度依赖主观感觉，也不被数字掩盖真实风险。
常见问题
评审会上大家都说没问题，但没人留下书面确认，能算角色覆盖到位吗？
不能。角色覆盖率的分母是评审前确认的应参与角色清单，分子是已确认方案的关键角色数，确认需要可追溯的记录，例如评审会签、书面回复或系统内的确认状态。口头表态没有记录时，按未覆盖计。补齐方式有两种：请该角色补充书面确认，或在评审记录中写明其意见并请其确认记录内容。两种情况都应更新角色覆盖率后再判定。
问题收敛率已经达到90%以上，但剩下的问题里有阻断级问题，可以放行吗？
不可以。问题收敛率衡量的是需处理问题的关闭比例，阻断项数量是独立的硬条件，必须为0。剩余问题中只要存在未关闭的阻断级问题，无论收敛率多高，结论都应为不通过。收敛率达标只说明一般性问题处理得比较充分，可以支持带条件通过的判断，前提是剩余问题全部为非阻断项且已登记负责人和关闭期限。
某个模块的关键流程清单还没梳理完，原型覆盖率的分母是0，怎么判定？
分母为0时不能按100%处理，应记为“未定义/未评估”，并在判定记录中说明原因。如果该类流程确实不适用，例如模块不涉及外部系统对接，可以注明不适用；如果是清单尚未梳理导致分母为0，应先补齐关键流程清单再判定，不能跳过。两种情况都要在结论记录中留下说明，便于后续复核。
带条件通过之后，遗留项由谁跟踪、什么时候复核？
带条件通过时，每个遗留项都应有负责人和关闭期限，判定记录中列明。跟踪方式可以是在问题清单中保留未关闭状态，按期限检查关闭情况。建议设定一个复核时间点，例如开发进入联调前或遗留项期限到期时，重新核对遗留项状态；如果出现新的阻断级问题，应回到准出判定流程重新评估，而不是默认此前的结论继续有效。
原型评审通过了，开发过程中发现方案有严重缺陷，说明之前的判定错了吗？
不一定。原型评审判定的是方案层面的完整性和方向性，覆盖率和收敛率反映评审过程是否充分，不保证方案在真实业务量、权限边界或异常并发下没有缺陷。开发过程中的技术方案评审、联调验证和验收测试是另外的检验环节。出现严重缺陷时，值得回看的是评审时高风险假设的验证范围是否足够、参与角色是否覆盖了相关视角，据此调整后续评审的准出条件和验证安排。
