产品设计研发评审协作要形成固定机制，关键是把每次评审的对象、要回答的决策问题和参与角色先定清楚，再按“方案说明—原型走查—研发可行性确认—结论与待办”四段推进。会前发材料并预读，会中按角色逐项确认，会后把结论落到可追踪的工作项和文档状态上，最后用检查清单核对是否闭环。评审记录与待办也可以在ONES这类协作平台中承接，便于跨轮次回溯。
要点总览（TL;DR）
- 评审协作先定义对象与决策问题：方案评审回答“做不做、做成什么样”，原型评审回答“流程是否走得通、异常是否覆盖”，每个决策问题用通过、有条件通过或退回修改作答。
- 按四段推进：会前发材料并预读，会上依次做方案说明、原型逐屏走查、研发可行性确认，最后当场确认结论与待办。
- 用固定字段的评审记录表留痕：评审对象及版本、决策问题、结论、待办、责任人、截止时间、关联原型版本，待办转为可追踪工作项。
- 角色交付物落到时点：产品经理发起并交付方案材料，设计师交付原型与状态说明，研发给出可行性与风险判断，测试和运营补充验收与规则视角。
- 评审结束后按清单核对闭环：决策问题均有结论、待办均有责任人与截止时间、退回项已安排复评、记录与原型版本对应、未决风险有人跟踪。
评审协作先定什么：对象、决策问题与参与角色
评审协作低效，常见原因在启动前：参会人不知道这次要定什么，材料到会上才第一次看，讨论发散后没有结论形式。启动前先填一张评审定义表，把四件事写清楚，会议才有判断基准。
第一，区分评审对象。方案评审的对象是业务目标、用户场景、功能范围和流程逻辑，回答“做不做、做成什么样”；原型评审的对象是可交互页面与关键状态，回答“流程是否走得通、信息层级是否合理、异常状态是否覆盖”。两类评审可以合并召开，但对象和问题要分开列，避免用视觉细节淹没方案层面的分歧。
第二，把目标写成可判断的决策问题。“讨论一下首页改版”无法判断是否完成；“首页改版后，新用户能否在三次点击内完成核心任务，本期是否纳入搜索入口”才是可判断的问题。每个决策问题应能用“通过、有条件通过、退回修改”之一作答，会上逐条勾掉。
第三，按角色划分确认职责。产品经理对业务目标和范围负责，设计师对流程与交互说明负责，研发对技术可行性和工作量风险负责，测试对验收条件和异常场景负责。每个角色在评审中是确认人，不只是旁听人，需要明确谁对哪类问题给出结论。
第四，确定频次与触发条件。固定节奏可按迭代设置，例如每个迭代一次方案评审、原型定稿前一次走查；触发式评审用于范围变更、关键流程调整、跨团队依赖新增等情况。频次写入团队约定，触发条件写进需求流转规则，减少临时拉会。
| 评审定义表字段 | 填写要求 | 示例 |
|---|---|---|
| 评审对象 | 方案或原型，注明版本 | 订单结算流程方案 V1.2 |
| 决策问题 | 逐条列出，可判断 | 是否支持合并支付；异常订单如何提示 |
| 参与角色 | 必到角色与可选角色分开 | 必到：产品、设计、研发、测试 |
| 结论形式 | 通过/有条件通过/退回修改 | 逐条决策问题给出结论 |
四段式评审流程：从方案说明到结论闭环
四段式流程的价值在于每段都有输入、动作、输出和完成标志，主持人可以按段控场，参会人知道当前在解决哪类问题。
会前：材料准备与预读
输入是评审定义表和完整材料，包括方案文档、原型链接、关键流程图、待确认问题清单。发起人至少提前一个工作日发出材料，并标注需要重点看的页面和问题。完成标志是必到角色确认已预读，预读意见提前以评论或清单形式提交，会上直接处理分歧，不从头讲解。
第一段：方案说明
产品经理按“业务目标—用户场景—范围与不做清单—关键流程—待决策问题”的顺序讲解，控制在约定时间内，例如十五分钟。讲解只覆盖背景和判断依据，细节留给原型走查。输出是参会人对目标和范围形成共同理解，完成标志是没有人对“为什么做、做到哪”提出未记录的分歧。
第二段：原型走查
设计师按主流程逐屏走查，每屏说明页面目标、关键操作、状态变化和异常提示。走查采用“一屏一确认”的方法：先由设计师说明，再由测试补充异常场景，研发标记实现风险，产品经理确认是否符合方案范围。发现的问题当场记录为待办，不展开即兴改稿。完成标志是主流程每一屏都有明确结论或待办。
第三段：研发可行性确认
这一段要问具体问题：关键交互是否有现成技术方案，依赖哪些外部系统或接口，工作量是否超出本迭代容量，是否存在性能、兼容或数据迁移风险，哪些部分需要拆期实现。研发给出可行性判断和风险等级，不能当场判断的列为待评估事项并约定回复时间。完成标志是每个高风险点都有负责人和回复时点。
第四段：结论与待办
主持人逐条复述决策问题的结论，记录人同步填写评审记录表，明确待办内容、责任人和截止时间。会议结束前当场确认结论状态，避免会后各自理解。完成标志是记录表填写完整并当场宣读一遍。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 会前准备 | 评审定义表、方案与原型材料 | 发材料、标注重点、收集预读意见 | 预读意见清单 | 必到角色确认已预读 |
| 方案说明 | 方案文档、范围清单 | 按目标、场景、范围、流程讲解 | 共同理解与分歧记录 | 目标与范围无未记录分歧 |
| 原型走查 | 原型链接、状态说明 | 逐屏确认主流程与异常状态 | 页面级结论与待办 | 主流程每屏有结论 |
| 可行性确认 | 技术依赖清单 | 逐项询问方案、依赖、工作量与风险 | 可行性判断与风险清单 | 高风险点有负责人和时点 |
| 结论与待办 | 会议记录 | 逐条确认结论、指派待办 | 评审记录表 | 记录完整并当场宣读 |
评审记录表怎么填：字段与示例
评审记录表是评审协作的交付物，字段固定后，不同主持人记录的结论可以横向比较和回溯。必填字段包括：评审对象及版本、决策问题、结论、待办、责任人、截止时间、关联原型版本。
结论状态分三种：通过表示决策问题已确认，可进入下一环节；有条件通过表示方向确认，但需完成指定待办或补充材料后才能推进，待办未关闭前不视为最终通过；退回修改表示方案或原型存在需要重新设计的问题，修改后安排复评。状态要写在每条决策问题后面，不用一个总评覆盖全部问题。
以下是一个产品方案评审的填写示例（演示情景）：
| 字段 | 填写内容 |
|---|---|
| 评审对象 | 会员积分兑换方案 V1.0，关联原型 P-032 |
| 决策问题 | 兑换入口放在个人中心还是首页；积分有效期是否本期上线 |
| 结论 | 入口：有条件通过，需补充首页入口的流量影响评估；有效期：退回修改，规则需与运营重新确认 |
| 待办 | 补充流量影响评估；输出积分有效期规则第二版 |
| 责任人 | 流量评估：产品经理；有效期规则：运营负责人 |
| 截止时间 | 流量评估：本周四；有效期规则：下周二 |
待办要转成可追踪的工作项，而不是留在会议纪要里。每条待办应包含动作、对象、责任人和截止时间，并关联到对应的原型版本或方案文档。工作项关闭时回填处理结果，评审记录表同步更新状态，这样下一轮评审可以直接看到上一轮待办的完成情况。
角色分工与交付物：谁在什么时点交什么
职责空转往往因为交付物没有落到具体时点。按角色列出评审前、中、后的交付物，可以把“配合评审”变成可检查的动作。
| 角色 | 评审前 | 评审中 | 评审后 |
|---|---|---|---|
| 产品经理 | 发起评审、填写评审定义表、发出方案文档与待决策问题 | 讲解方案目标、范围与流程，确认业务结论 | 关闭方案类待办，更新方案版本 |
| 设计师 | 交付可交互原型、设计说明与状态清单 | 逐屏走查，说明交互逻辑与异常状态 | 按结论修改原型，标注修改版本 |
| 研发 | 预读原型，标记技术疑点 | 给出可行性评估、依赖与风险提示 | 完成待评估事项并回复结论 |
| 测试 | 梳理验收视角的异常场景 | 补充边界条件与验收关注点 | 将确认后的验收条件纳入测试准备 |
| 运营 | 提供用户反馈与运营规则输入 | 确认规则类问题，如权益、时效、文案口径 | 输出运营规则确认结果 |
| 主持人 | 确认议程与时间盒 | 按四段控场，逐条收敛决策问题 | 核对记录表完整性 |
| 记录人 | 准备记录表模板 | 实时记录结论、待办与责任人 | 发出记录并跟踪待办状态 |
主持人与记录人可由团队成员轮值，但职责要分开：主持人负责推进决策，记录人负责准确留痕。小团队中一人兼任时，建议在会议结束前留出专门时间整理结论，避免边讨论边记录导致遗漏。
评审结论如何落地到协作工具
评审记录表解决“记下来”，协作工具解决“跟下去”。落地时重点做四件事：把评审记录与原型文档关联，把待办转为工作项并指派责任人，让评审状态与版本变更可追踪，保留跨轮次评审的结论以便回溯。
在ONES中，评审记录可以作为文档与对应的原型说明、方案文档放在同一项目空间，评审结论中的待办转为工作项并指派责任人、设置截止时间，工作项状态变化直接反映待办是否关闭。原型或方案更新版本时，在文档中记录版本号和变更说明，下一轮评审引用上一轮记录，形成可回溯的评审链路。具体操作方式以团队实际使用的项目模板和权限配置为准。
- 评审记录文档命名统一包含对象名称与版本号，便于检索。
- 每条待办对应一个工作项，工作项描述中引用评审记录链接。
- 结论为“有条件通过”的评审，待办全部关闭后再更新评审状态。
- 复评时先核对上一轮待办完成情况，再进入新的决策问题。
- 版本变更时同步更新评审记录中的关联原型版本字段。
完成检查：评审协作是否闭环的核对项
评审结束不等于协作完成。用下面的清单逐项核对，可以判断一次评审是否真正闭环。
- 评审定义表中的每个决策问题都有明确结论，没有“会后再议”且无责任人的遗留项。
- 每条待办都有责任人和截止时间，且已转为可追踪的工作项。
- 结论为“退回修改”的事项已安排复评时间，并通知相关角色。
- 评审记录已归档，记录中的原型版本与实际修改后的版本对应一致。
- 会上识别但暂未解决的风险已记录，明确跟踪人和下次检查时点。
- “有条件通过”的事项在条件满足前未进入开发或下一阶段。
- 记录已发给全部参会角色，未到场角色确认已知晓与自己相关的结论。
这套检查可以放在每次评审结束后的固定动作中，由记录人核对、主持人确认。连续几轮评审都通过检查后，团队可以按实际情况简化部分字段，但决策问题、结论、待办责任人和截止时间这四项建议始终保留，它们是评审协作可追踪的基础。
常见问题
方案评审和原型评审合并开一次会，怎么避免讨论失焦？
可以合并召开，但要把两类对象和问题分开列。会议前半段处理方案层面的决策问题，例如业务目标、功能范围、流程逻辑；后半段进入原型走查，只确认页面流程、信息层级和异常状态。主持人按段切换，遇到视觉细节或实现细节先记为待办，留到对应环节或会后处理。合并的前提是材料提前发出，参会人对方案背景已有基本了解。
评审会上研发无法当场判断可行性，结论该怎么记？
把这类问题记为“待评估事项”，而不是悬空的“会后再议”。记录表里写明需要评估的具体问题、评估负责人和回复时点，例如依赖哪个外部接口、工作量是否超出本迭代容量。回复后由记录人回填结论，并判断该决策问题是转为通过、有条件通过还是退回修改。待评估事项未回复前，相关部分不进入开发排期。
“有条件通过”的评审，条件满足后还需要再开一次会吗？
不一定。条件通常是补充材料、完成指定待办或确认某项规则，这类事项可以由责任人在约定时间内完成并回填结果，由主持人或记录人核对后更新评审状态。如果条件涉及方案方向变化或新增关键流程，则需要安排复评。团队可以在评审约定中写明哪些条件走书面确认、哪些必须复评，减少不必要的会议。
小团队人少，主持人和记录人由一人兼任，怎么保证记录质量？
兼任时建议把记录动作集中在两个时点：讨论过程中只记关键词和待办线索，会议结束前留出专门时间逐条整理结论、责任人和截止时间，并当场宣读确认。记录表模板提前准备好，字段固定，避免临场想格式。会后当天发出记录，让参会人补充遗漏。连续几轮后可以按实际情况简化字段，但决策问题、结论、待办责任人和截止时间建议保留。
评审结论落到协作工具后，怎么保证下一轮评审能接上？
关键是让记录、工作项和版本三者互相对应。评审记录文档命名包含对象名称与版本号，每条待办对应一个工作项并在描述中引用记录链接，原型或方案更新版本时同步更新记录中的关联版本字段。复评开始时先核对上一轮待办的关闭情况，再进入新的决策问题。这样跨轮次回溯时，能直接看到每轮结论、待办完成状态和对应的原型版本。
