需求评审：先把问题说清，再讨论方案
评审的目标不是挑错，而是在开工前确认问题真实、范围清楚、验收可测。
适用场景
适用于产品需求、内部系统改造、流程变更等需要多方协作才能落地的需求。评审要把「用户遇到什么问题」与「我们打算怎么解决」分开讨论，先确认前者有证据，再判断后者是否值得做。如果需求只是文案调整、配置修改这类低风险小改动，可以由负责人快速确认，不必组织完整评审。
涉及角色
- 需求提出人
- 评审主持人
- 开发 / 设计 / 测试代表
- 决策人
前置输入
开始之前先把这些材料放到同一个位置。缺哪一项，先补哪一项，不要让步骤表替你承担信息缺口。
- 需求背景与用户问题的证据（数据、反馈、现场记录）
- 需求说明：范围、优先级与明确不做什么
- 验收标准与衡量方式
- 相关原型、数据口径或竞品参考
步骤表
步骤 · 动作 · 产出 · 负责人 · 时限| 步骤 | 动作 | 产出 | 负责人 | 时限 |
|---|---|---|---|---|
| 1 | 提交需求材料，至少包含问题证据、范围与验收标准 | 需求说明与验收标准 | 需求提出人 | 评审前 2 天，1 小时 |
| 2 | 预审材料是否齐全，不齐退回补充，不占用会议时间 | 预审结论：通过 / 退回 | 评审主持人 | 评审前 1 天，20 分钟 |
| 3 | 会上先确认问题与影响，再进入方案讨论 | 问题确认记录 | 评审主持人 | 会中 30 分钟 |
| 4 | 逐条确认范围、优先级、验收标准与风险 | 评审结论 | 全体参会人 | 会中 40 分钟 |
| 5 | 输出评审纪要，标注已决定、待补充与不做的内容 | 评审纪要 | 评审主持人 | 会后 1 天，30 分钟 |
| 6 | 冻结需求版本，后续变更走同一入口并评估影响 | 冻结版本与变更规则 | 需求提出人 | 开发前 10 分钟 |
在手机上可左右滑动查看完整表格；负责人和时限建议换成你们团队的真实角色与节奏。
关键检查点
每一步之间停一下，用这几条判断是否真的可以进入下一步。检查点不通过时，补信息比赶进度更省时间。
- 问题有证据：数据、用户反馈或现场记录，而不是「我觉得」。
- 验收标准可测：写成可观察的结果，避免「体验更好」这类表述。
- 范围里写清了这次不做什么，以及为什么不做。
- 优先级只有一个第一，其余排序明确。
- 变更规则提前约定：谁提出、谁评估、多久内回复。
常见失败模式
| 常见表现 | 怎么调整 |
|---|---|
| 把方案当需求，例如「做一个看板」却没有说明要解决什么。 | 先写问题陈述和现状数据，方案部分至少给两个可选路径。 |
| 评审会上大家第一次看到材料，只能现场读。 | 设置预审环节，材料不齐直接退回，不安排会议。 |
| 验收标准写「好用」「快」，上线后无法判断是否达标。 | 改成可测指标：完成时间、错误率、转化率或明确的通过条件。 |
一页纸 SOP
下面的清单可以整段复制或下载，贴进团队文档、打印出来或放进任务工具。 跑过几次后，把不适用的条目删掉，把反复卡住的地方补成一条新的检查点。
可整段复制 勾选项可直接改成你们团队的检查清单
# 需求评审 SOP（一页纸）
## 提交前
- ☐ 用一句话写清用户问题，并附数据或反馈证据
- ☐ 写清这次做什么、不做什么
- ☐ 给验收标准，确保可以被测试或观察
- ☐ 标注优先级与期望上线时间
## 评审前 1 天
- ☐ 主持人预审材料是否齐全
- ☐ 不齐则退回补充，会议改期
- ☐ 材料发给参会人，要求提前阅读
## 评审会
- ☐ 前 10 分钟只确认问题与影响
- ☐ 再讨论方案，至少比较两个路径
- ☐ 逐条确认范围、优先级、验收标准
- ☐ 记录已决定、待补充、不做的三类结论
## 会后 1 天
- ☐ 发评审纪要，明确下一步负责人
- ☐ 冻结需求版本，标注版本号
- ☐ 说明变更入口与影响评估方式
## 开发前
- ☐ 确认需求、设计、测试三方理解一致
- ☐ 把验收标准转成测试用例或检查清单
复制与下载都在浏览器本地完成，不会上传内容，也不需要登录。