产品方案评审要回答三个问题：方案是否值得做、能否落地、风险是否可控。做法上，会前明确范围与材料，会中按目标、方案比较、原型与可用性、风险与交付的顺序逐项收敛，会后把问题分级、指派、跟踪并复评。核心产物是评审结论记录、问题清单和待办跟踪，会议纪要只是过程留痕。
要点总览（TL;DR）
- 评审前先做准入判断：方案说明、可讨论的原型、备选方案取舍理由、评审范围声明四项齐全再开会，材料提前一到两个工作日发出。
- 会议按目标与范围、方案比较、原型与可用性、风险与交付四段推进，每段设时间上限，意见当场归为阻塞、改进建议、待确认项三类。
- 角色分工写进会前材料：方案提出者陈述答疑，设计、研发、测试、业务方各按关注点提问，决策者当场拍板方案是否推进与范围取舍。
- 会后按阻塞、重要、建议三级跟踪，每条问题有责任人和时限；出现阻塞项时方案修改后必须复评，复评只核对未关闭项和受影响部分。
- 评审是否有效看四点：材料与范围会前明确、关键问题有结论或责任人、阻塞项复评前关闭、记录与方案版本可追溯。
评审前要准备什么：材料、范围与准入条件
评审能否开出效果，很大程度上在会前已经决定。组织者需要在发出会议邀请前完成一次准入判断：材料是否足以支撑讨论，范围是否说清楚。四项输入缺一项，建议先补齐再开会，否则会议容易变成听汇报或临时补信息。
第一项是方案说明。它应包含背景（为什么现在做）、目标（希望改变什么业务结果）、用户场景（谁在什么情况下使用）、范围边界（本次覆盖哪些端、哪些流程、哪些暂不纳入）。目标要写成可判断的表述，例如“结算页下单转化率提升”比“优化用户体验”更容易在评审中被检验。
第二项是可讨论的原型或方案示意。最低程度是能让人看懂主流程和关键页面状态：入口在哪、主路径怎么走、异常和空状态如何处理。静态线框图即可，不要求视觉稿。若关键交互仍停留在口头描述，评审中的分歧往往无法定位，建议先补一版可指认的示意。
第三项是方案比较材料。至少给出一个备选方案及取舍理由，说明为什么选当前方案：成本、改动范围、上线节奏、对现有用户的影响。只有一个方案的评审容易变成论证会，比较材料能把讨论拉回权衡本身。
第四项是评审范围声明，明确本次评什么、不评什么。例如“本次评审结算页信息结构与交互流程，不评审视觉风格与具体文案措辞”。范围声明同时约束参会人的提问边界，减少跑题。
| 准入项 | 最低要求 | 不满足时的处理 |
|---|---|---|
| 方案说明 | 背景、目标、用户场景、范围边界齐全 | 补齐后再排期 |
| 原型或示意 | 主流程与关键状态可指认 | 先出线框再评审 |
| 方案比较 | 至少一个备选方案及取舍理由 | 补充比较材料 |
| 范围声明 | 写明评什么、不评什么 | 组织者会前确认 |
准入清单可以由方案提出者自检、组织者复核，两项都通过再发出会议邀请。材料提前一到两个工作日发出，让参会人有时间阅读并带着问题进会。
评审会怎么开：议程、提问顺序与结论形成
评审会按固定顺序推进，能让讨论从“值不值得做”逐步落到“怎么做、有什么风险”，避免一上来就陷入页面细节。建议议程分四段：目标与范围、方案比较、原型与可用性、风险与交付。每段设定时间上限，由主持人控场。
第一段由方案提出者用几分钟讲清目标、用户场景和范围，参会人只确认理解是否一致，不展开细节争论。第二段讨论备选方案与取舍，提问集中在“为什么选这个”“放弃的方案代价是什么”“有没有更小的验证方式”。第三段进入原型，按主流程逐屏走查，关注信息是否完整、操作路径是否顺畅、异常状态是否覆盖。第四段由研发、测试提出技术实现、依赖、数据迁移和交付节奏方面的风险。
每项议题预设提问要点，可以让讨论有抓手。例如目标段问“成功怎么衡量”，比较段问“改动范围与收益是否匹配”，原型段问“新用户能否独立完成主任务”，风险段问“哪些依赖不在本团队控制内”。时间分配可按议题重要性调整，一般目标与比较合计不超过三分之一，原型与风险占主要时间。
讨论中产生的意见要当场归类，这是结论收敛的关键。建议分三类：
- 阻塞问题：不解决就不能进入开发，例如主流程存在断点、合规要求未满足、关键技术依赖未确认。必须指定责任人和复评时间。
- 改进建议：不影响方案成立，可排期优化，例如文案措辞、次要页面的信息密度。记录后纳入后续迭代。
- 待确认项：需要补充信息才能判断，例如数据口径、外部接口能力。明确由谁在什么时间前给出答案。
结论记录建议采用固定格式：方案名称与版本、参会角色、评审范围、结论（通过／有条件通过／退回修改）、阻塞问题清单、改进建议清单、待确认项及责任人、复评时间。结论当场宣读一遍，参会人确认无异议后散会。主持人在会末明确下一步动作和负责人，避免“会后再说”。
角色怎么分工：谁提方案、谁提问、谁拍板
评审常见的问题是参加的人多、负责的人少。解决办法是给每个角色定义清楚职责和交付物，会前随材料一起发出。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 方案提出者（通常为产品经理） | 准备材料、陈述方案、现场答疑、会后修改方案 | 方案说明、原型、比较材料、修改后的方案版本 |
| 设计 | 评估交互流程与信息结构，指出可用性问题 | 交互问题清单与修改建议 |
| 研发 | 评估技术可行性、改动范围、依赖与工期 | 技术风险项与实现约束说明 |
| 测试 | 评估可测性、异常场景覆盖、验收口径 | 测试关注点与验收条件建议 |
| 业务或运营方 | 确认业务规则、目标口径与实际使用场景 | 业务规则确认与目标指标口径 |
| 决策者 | 对方案是否推进、范围取舍、资源投入拍板 | 评审结论（通过／有条件通过／退回） |
| 记录人 | 记录结论、问题分级、责任人与时限 | 评审结论记录与问题清单 |
| 跟踪人 | 会后跟进问题状态，组织复评 | 问题跟踪表与复评安排 |
决策者的拍板范围要事先说清：哪些事项当场定，哪些需要向上升级。一般方案是否推进、范围是否裁剪、是否追加资源由决策者当场定；涉及跨部门资源协调或预算的事项，明确升级路径和时限，例如“三个工作日内提交至产品委员会”。记录人与跟踪人可以由同一人担任，但职责要分开写：记录保证信息准确，跟踪保证问题关闭。
角色分工的另一层含义是提问分工。产品关注目标与价值，设计关注流程与体验，研发关注可行性与成本，测试关注异常与验收。会前把关注点告知各角色，会上按议程顺序发言，能减少重复提问和相互打断。
反馈怎么闭环：问题分级、跟踪与复评
评审的价值取决于会后问题是否被真正解决。闭环从问题分级开始，按影响程度分三档：
| 级别 | 判断标准 | 处理要求 |
|---|---|---|
| 阻塞 | 不解决则方案无法进入开发或存在明显业务、合规风险 | 指定责任人，复评前必须关闭 |
| 重要 | 影响核心流程体验或交付质量，但不阻断启动 | 明确责任人与完成时限，纳入当前版本计划 |
| 建议 | 优化类意见，不影响方案成立 | 记录归档，排入后续迭代评估 |
每条问题都要有责任人、完成时限和验证方式。责任人由问题所属领域确定，例如交互问题归设计、技术风险归研发，避免统一压给方案提出者。时限结合复评时间倒推，复评前无法完成的，提前说明并调整结论。
复评的触发条件建议明确写进结论记录：出现阻塞问题时，方案修改后必须复评；只有重要和建议类问题时，可由决策者授权方案提出者确认修改后直接推进，不必再开全会。复评范围聚焦未关闭的阻塞项和修改影响到的部分，不重复全量评审。
闭环完成的判断依据是：阻塞项全部关闭并经确认，重要项已指派并有明确时限，待确认项已有结论，方案版本更新并留痕。满足这些条件，本次评审才算结束。评审记录、问题清单和方案版本需要放在团队可访问的位置，便于后续追溯和交接。在ONES中，这类评审材料可以用文档承载方案说明与结论记录，问题清单和待办则以工作项形式指派责任人、跟踪状态，复评时直接查看未关闭项，减少在聊天记录里翻找的成本。
示例：一次电商结算页改版方案评审
以下为演示情景，用于说明流程如何落地，不代表真实项目结果。
背景与范围。某电商团队计划改版结算页，目标是减少下单流程中的中途退出。方案提出者准备了方案说明（背景、目标、用户场景、覆盖范围）、两版线框原型、与“仅优化按钮位置”备选方案的比较，以及范围声明：本次评审结算页信息结构与主流程交互，不评审视觉风格和促销文案。材料提前两天发出，准入检查通过。
评审中的典型问题。按议程推进后，会上提出若干问题并当场分级：
- 阻塞：新地址填写流程在未登录状态下缺少引导，主流程存在断点，由产品经理负责修改，复评前关闭。
- 阻塞：优惠券选择与金额展示的规则依赖后端接口改造，研发确认排期未定，由研发负责人三个工作日内给出结论。
- 重要：订单金额明细的展示层级不够清晰，由设计负责在当前版本内调整。
- 建议：提交按钮的文案措辞可后续 A/B 验证，记录归档。
结论与后续动作。决策者给出“有条件通过”：两个阻塞项关闭后进入开发，重要项随版本交付。记录人当场整理结论记录和问题清单，明确责任人与时限，复评时间定在五个工作日后。
闭环与复评。复评时，地址引导已补充并通过确认，接口排期已明确并纳入计划，两个阻塞项关闭；重要项已完成调整。复评只核对了阻塞项和受影响部分，未重复全量讨论。方案版本更新留痕，评审结束。
完成检查：评审是否有效的判断标准
评审结束后，可用以下清单逐项核对，判断本次评审是否达到目的：
- 会前是否完成准入检查：方案说明、原型、比较材料、范围声明四项齐全。
- 参会角色是否覆盖产品、设计、研发、测试和业务方，决策者是否到场或明确授权。
- 议程是否按目标、方案比较、原型与可用性、风险与交付的顺序推进，各议题是否在时间上限内收敛。
- 每条意见是否归类为阻塞、重要或建议，并写明责任人与时限。
- 评审结论是否当场形成并记录，结论类型（通过／有条件通过／退回）是否明确。
- 阻塞项是否在复评前全部关闭，复评是否只聚焦未关闭项和受影响部分。
- 评审记录、问题清单和方案版本是否可追溯，后续接手的人能否据此了解决策依据。
如果清单中有多项未满足，说明流程中某一环存在缺口：材料不足回看准入环节，结论不清回看议程与记录格式，问题未关闭回看跟踪与复评规则。按环节修正，比每次评审后笼统总结“下次注意”更能持续改善评审质量。
常见问题
方案还没定稿，只有大致思路，可以开评审会吗？
可以开，但要调整评审目标。如果思路尚未形成可指认的原型，建议先做一次小范围的方向讨论，参会人限定在方案提出者、设计和研发负责人，目标是确认方向是否值得继续投入，不形成开发结论。
等主流程和关键状态能用线框指认、并有一个备选方案作比较后，再进入正式评审。把方向讨论和方案评审混在一起，容易出现会上争论方向、细节来不及看的情况。
评审会上意见分歧较大，当场定不下来怎么办？
先判断分歧属于哪一类。如果是信息不足导致的，归为待确认项，明确由谁在什么时间前补充数据或结论，复评时再定；如果是目标或范围本身有分歧，说明会前范围声明没有对齐，应由决策者当场明确本次推进的目标和边界，超出边界的意见记录为后续议题。
确实需要更高层级决策的事项，当场写明升级路径和时限，例如三个工作日内提交产品委员会，避免会议无限延长。
小团队人少，角色分工表里的角色凑不齐，流程还能用吗？
可以合并角色，但职责要保留。常见做法是产品经理兼任方案提出者和记录人，研发负责人兼任技术评估和决策者，测试关注点由研发在评审中一并提出。
合并时注意两点：记录与跟踪的职责分开写，保证问题有人跟进；决策者与方案提出者尽量不由同一人担任，否则方案是否推进缺少独立判断。团队规模扩大后再逐步拆分角色。
复评一定要再开一次会吗？
不一定。结论记录里可以预设触发条件：存在阻塞项时，方案修改后必须复评；只有重要和建议类问题时，可由决策者授权方案提出者确认修改结果后直接推进。
复评形式可以是短会，也可以是书面确认，关键是核对未关闭的阻塞项和修改影响到的部分，并留下确认记录。复评范围不重复全量评审，否则会拉长周期。
评审记录和问题清单放在哪里比较合适？
选择团队日常已经在用的位置，保证参会人和后续接手的人都能访问。常见做法是方案说明、结论记录放在文档中按版本留痕，问题清单和待办以工作项形式指派责任人和状态，复评时直接筛选未关闭项。
在ONES中，评审材料可以用文档承载，问题与待办以工作项跟踪，便于把结论和后续动作放在同一处追溯。具体模板和字段设置按团队现有流程配置即可。
