产品方案与原型评审要解决的是方案在进入开发前把目标、流程和边界讲清楚，让问题提前暴露，并把结论变成可追踪的行动项。本文按评审前准备、会中推进、角色分工、结论落地和完成检查的顺序，给出一套可以直接照着组织的流程，适用于产品负责人或项目负责人牵头的中小型评审场景。
要点总览（TL;DR）
- 评审前把对象拆成产品方案、原型、配套材料三类分别准备，并按决策影响面确定参与人，材料不齐不轻易开会。
- 会中按目标与场景、主流程与异常流程、业务规则与数据口径、边界与依赖、风险与待定项五段推进，每个议题只记录通过、有条件通过、退回补充、待决策四种结论。
- 产品负责人、设计、研发、测试、业务方和记录人各自有会前输入与会后交付物，职责以交付物为准。
- 结论清单需包含问题描述、结论类型、负责人、截止时间、关联位置和状态，并与原型、文档版本对应，超期待决策项按约定路径升级。
- 评审是否有效，用会前材料与角色、会中结论类型、会后行动项、复核闭合四项逐条核对。
评审前先定清楚：评什么、谁来评、拿什么评
评审效果很大程度上在会前就决定了。发起人需要先把评审对象拆成三类，分别准备材料，再按决策影响面确定参与人。范围不清、材料不全的评审，往往在会上变成对细节的临时讨论，结论也难以落地。
三类评审对象与对应材料
产品方案回答“做什么、为什么做”，原型回答“用户怎么走通”，配套材料回答“依据是什么、依赖谁”。三类对象缺一类，评审就会出现盲区：只有方案没有原型，流程细节无法验证；只有原型没有方案，评审容易陷入界面讨论；缺少数据口径和依赖说明，研发与测试无法判断可行性。
| 评审对象 | 应包含内容 | 常见缺失 |
|---|---|---|
| 产品方案 | 目标与成功标准、范围与不做清单、业务规则、角色与权限 | 成功标准写成“提升体验”这类无法验证的表述 |
| 原型 | 信息架构、主流程与异常流程、关键页面交互状态（空态、加载、错误、无权限） | 只画正常路径，异常分支留到开发阶段临时决定 |
| 配套材料 | 数据口径与来源、上下游依赖、已知风险、待决策问题清单 | 数据口径口头说明，会后各方理解不一致 |
按决策影响面确定参与角色
参与人应围绕“这次评审要拍板什么”来定。涉及业务流程变更，业务方必须到场；涉及技术约束，对应模块的研发负责人需要参加；涉及验收口径，测试需要提前看到原型。与本次决策无关的岗位可以只接收结论清单，不必全程旁听，否则会议时间会被拉长，讨论也容易发散。
会前材料齐备自检
发起人在发出评审通知时，附上以下自检结果，评审对象和参与人就能提前判断是否具备开会条件：
- 目标与成功标准：能用可观察的指标或业务结果描述，并说明衡量方式。
- 主流程与异常流程：主流程可从头走到尾，异常流程至少覆盖失败、超时、无权限、数据缺失四类情况。
- 边界与不做清单：明确本期范围外的事项，避免会上反复讨论“要不要顺便做”。
- 待决策问题清单：列出需要本次会议拍板的问题，每个问题给出可选方案和发起人的倾向意见。
- 数据口径与依赖：关键字段的定义、来源系统、上下游接口方已确认。
这份自检的结果就是评审范围说明：写清本次评审覆盖哪些模块、哪些问题需要决策、哪些内容留到后续评审。范围说明随材料一起发出，能显著减少会上的范围争议。
评审会的推进顺序：从目标到风险逐段过
评审会漫谈的常见原因是缺少固定推进顺序。建议按“目标与场景—主流程与异常流程—业务规则与数据口径—边界与依赖—风险与待定项”五段推进，每段有明确的输入和输出，主持人按段控场。
开场：对齐目标与决策权限
开场用三到五分钟完成两件事：重申本次评审要解决的问题清单，说明哪些问题本次拍板、哪些只做信息同步。决策权限提前讲明，可以避免会上出现“我回去问问领导”的悬空结论。主持人同时确认记录人，并说明结论会以书面清单形式发出。
五段推进的输入、动作与输出
| 段落 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 目标与场景 | 方案中的目标、目标用户、使用场景 | 业务方确认场景真实性，产品负责人说明优先级依据 | 目标与场景确认，或标记为待决策 |
| 主流程与异常流程 | 原型主路径、异常分支页面 | 按用户操作顺序走查，研发和测试补充遗漏分支 | 流程问题清单，标注影响范围 |
| 业务规则与数据口径 | 规则说明、字段定义、数据来源 | 逐条核对规则触发条件和数据一致性 | 规则确认或修订意见 |
| 边界与依赖 | 不做清单、上下游接口方 | 确认本期范围，识别外部依赖的交付时间 | 范围确认、依赖风险记录 |
| 风险与待定项 | 风险清单、待决策问题 | 逐项给出结论类型和负责人 | 结论清单与行动项 |
结论类型与节奏控制
每个议题结束时，记录人当场记录结论类型，只有四种：通过、有条件通过（附条件）、退回补充、待决策。模糊表态如“再看看”“问题不大”不构成结论，主持人应当场追问并归入四类之一。
节奏控制有两条实用规则：单个议题超过预定时间，转入待办并指定跟进人，不在会上继续展开设计细节；涉及具体交互实现方式的讨论，记录为研发与设计的会后对接事项，不占用全体参会人的时间。会议结束时留出五分钟，由记录人复述结论清单，参会人当场确认，减少会后对结论理解的偏差。
角色分工与各自交付物
“会上都说好、会后没人改”通常源于角色职责没有落到具体交付物。评审闭环中每个角色都应有会前输入和会后产出，职责以交付物为准，不以参会与否为准。
| 角色 | 会前输入 | 会中职责 | 会后交付物 |
|---|---|---|---|
| 产品负责人 | 方案文档、原型、待决策问题清单 | 讲解方案，说明取舍理由，回应质疑 | 按结论修订方案与原型，关闭或升级待决策项 |
| 设计 | 交互说明、关键页面状态 | 说明交互逻辑，记录流程与状态问题 | 修订原型，补充异常状态页面 |
| 研发 | 技术约束与实现成本预估 | 指出可行性风险和技术依赖 | 书面反馈技术约束、依赖交付时间 |
| 测试 | 初步验收口径 | 补充可测性与异常场景 | 更新验收标准，标注不可测的需求点 |
| 业务方 | 业务场景与优先级说明 | 确认场景真实性与优先级 | 确认结论或提出业务侧调整意见 |
| 记录人 | 议程与问题清单 | 记录结论类型与行动项 | 结论清单，含负责人与截止时间 |
这张表可以直接作为评审通知的附件发出，让每个参会人知道自己需要带什么、会上负责什么、会后交什么。研发和测试的书面反馈尤其重要：口头提出的技术风险容易在会后丢失，写成书面意见才能进入结论清单被跟踪。
一个完整示例：从提交到复核走一遍
以下为演示情景，用于说明评审闭环如何运转。某电商团队计划改造订单履约流程，支持部分商品拆单发货，产品负责人牵头组织评审。
提交与预审
产品负责人提交的材料包括：方案文档（拆单规则、发货时效目标、不做清单）、原型（下单、拆单确认、发货跟踪三个主流程及缺货、部分退款两个异常流程）、配套材料（库存数据口径、与仓储系统的接口依赖、待决策问题清单）。待决策问题有两个：拆单是否对用户可见、部分退款后的运费如何计算。
预审由研发和测试提前一天完成，书面反馈三条：仓储接口目前只支持整单发货，拆单需要接口改造，预计影响排期两周；原型中缺货场景没有说明用户能否修改拆单结果；运费规则缺少数据支撑，建议业务方补充历史退款数据。
评审会与结论
会上按五段顺序推进。目标与场景段，业务方确认拆单需求来自大件商品与赠品混合下单的场景，优先级为高。流程段，测试补充了拆单后部分商品取消的场景，产品负责人当场记录为退回补充。规则段，运费问题因缺少数据，结论为待决策，负责人为业务方，时限一周。边界段，确认本期不做跨仓拆单，写入不做清单。风险段，仓储接口改造被列为有条件通过的条件之一。
复核与闭合
一周后复核：产品负责人补充了部分取消场景的原型和规则说明；业务方提交了运费历史数据并给出计算方案，待决策项转为通过；仓储接口改造排期与研发确认后写入依赖清单。记录人逐项核对结论清单，所有行动项均有负责人和完成时间，退回补充项已重新评审通过，本次评审闭合。
评审结论如何落到文档与原型状态
结论只有落到具体载体上才能被跟踪。建议用一张结论清单承载全部行动项，并让清单中的每一项都能指向对应的原型页面或文档章节，复核时按清单逐项验证。
结论清单字段
| 字段 | 填写要求 |
|---|---|
| 问题描述 | 一句话说明问题，避免只写“流程有问题” |
| 结论类型 | 通过、有条件通过、退回补充、待决策四选一 |
| 负责人 | 具体到人，不写部门或“相关同学” |
| 截止时间 | 具体日期，与下次复核时间对齐 |
| 关联位置 | 原型页面编号或文档章节，便于定位修订内容 |
| 状态 | 待处理、处理中、待复核、已关闭 |
版本对应与待决策项升级
原型和方案文档应有版本号，结论清单记录评审时对应的版本。修订后版本更新，清单中关联位置同步更新，复核时以最新版本为准，避免出现“改的是旧版原型”的情况。
待决策项需要设定升级路径：超过截止时间未决策的，由产品负责人升级到对应的业务或技术决策人，并在清单中记录升级时间和新时限。待决策项长期悬置会拖住整个方案，升级机制保证它不会在清单里沉默。
结论关闭的判定标准
一项结论可以关闭，需要同时满足：修订内容已体现在最新版本的原型或文档中；负责人确认完成；复核人验证通过。退回补充项需要重新走一次小范围评审，不能由负责人自行判定关闭。
当评审数量增多，结论清单和行动项需要承载在团队日常使用的协作工具中，才能持续跟踪状态和责任人。ONES 提供工作项与文档的管理方式，可以把评审结论登记为工作项、关联到对应的方案文档，并按状态推进到关闭，让复核时有据可查。具体字段配置和状态流转可按团队现有流程设置。
完成检查：这次评审是否真的有效
评审结束后，用以下清单逐项核对，判断本次评审是否达到目的。任何一项不满足，都应在下次评审前补齐。
- 会前材料齐备：方案、原型、配套材料三类齐全，自检清单中的五项均有对应内容。
- 参与角色到位：与本次决策相关的产品、设计、研发、测试、业务方均已参加或提交书面意见。
- 结论类型明确：每个议题都有四类结论之一，没有遗留模糊表态。
- 行动项完整：每项行动都有具体负责人和截止时间，关联到原型页面或文档章节。
- 待决策项有出口：每个待决策项都有决策人和时限，超时升级路径已约定。
- 复核已闭合：修订内容体现在最新版本中，退回补充项已重新评审，遗留项已升级处理。
- 结论可追溯：结论清单可被未参会人员查阅，能定位到对应版本的材料。
这份清单也可以反向使用：在评审通知发出前先核对前两项，在会议结束前核对中间三项，在复核时核对最后两项。把检查动作分散到评审闭环的各个节点，比事后集中检查更容易发现问题。
常见问题
评审会上业务方或研发负责人临时缺席，评审还能继续吗？
能否继续取决于缺席角色是否涉及本次要拍板的问题。如果评审范围包含业务流程变更或优先级确认，业务方缺席会导致场景真实性和优先级无法当场确认，建议将相关议题调整为待决策或改期。如果涉及技术约束和依赖排期，对应研发负责人缺席时，可将可行性相关议题标记为待决策，并指定书面反馈的截止时间。与本次决策无关的岗位缺席不影响评审推进，但结论清单仍应发给其知悉。
原型还比较粗糙，是否应该等设计细化后再评审？
评审目的不同，对原型精细度的要求也不同。如果本次评审要确认信息架构、主流程和异常分支是否完整，低保真原型或线框图即可满足，过早细化视觉反而会拉长准备周期。如果评审涉及关键页面交互状态和用户操作路径的验证，则需要补充空态、加载、错误、无权限等状态说明。判断标准是：原型能否支撑本次要拍板的问题，能支撑就可以评审，不能支撑则先补充对应部分。
待决策项超过截止时间仍未拍板，应该怎么处理？
待决策项在设定截止时间时，就应同时约定升级路径和升级对象。超过截止时间后，由产品负责人将问题升级到对应的业务或技术决策人，并在结论清单中记录升级时间和新的时限。升级不是重复讨论，而是把决策权交给能拍板的人。如果升级后仍无法决策，需要评估该问题是否阻塞本期范围，必要时调整方案边界，将受影响内容移出本期或标记为有条件通过的条件。
评审结论清单用文档表格管理还是用工作项管理，哪种更合适？
两种方式都能承载结论，选择取决于团队日常协作习惯和跟踪强度。文档表格适合评审频次较低、结论数量不多的团队，编写和查阅门槛低。工作项适合评审频繁、行动项需要持续跟踪状态和负责人的团队，便于按状态筛选和复核。也可以组合使用：用文档记录评审背景和完整结论，将需要跟踪的行动项登记为工作项并关联回文档。ONES 提供工作项与文档的管理方式，可按团队现有流程配置字段和状态。
小团队人手少，是否每个角色都必须单独安排人参加评审？
角色分工的目的是确保每类交付物有人负责，不要求每个角色都由不同的人担任。小团队中一人可能同时承担产品与设计职责，或研发与测试职责，此时可以在评审通知中注明兼任情况，但会前输入和会后交付物仍需逐项落实。需要避免的是所有职责集中在一个人身上且没有书面记录，导致可行性反馈和验收口径缺少独立视角。人手有限时，至少保证研发和业务方有书面意见进入结论清单。
