4、需求评审会怎么开才不流于形式？会前、会中、会后三步法。
说实话，我见过太多需求评审会变成「批斗会」或者「独角戏」。
要么是产品经理一个人念文档，大家低头玩手机。要么是开发突然跳起来说「这个做不了」，然后吵成一团。
为什么会这样？
因为大家把评审会当成了「通知会」，而不是「对齐会」。我个人习惯把评审会拆成三步：会前、会中、会后。每一步都有明确的目标和动作。
4.1 会前准备：80%的功夫在会外
我有个原则：没有提前发文档的评审会，我直接取消。
这不是摆架子。你想想看，一个复杂的需求，现场给你10分钟读文档，你能消化多少？
我在项目中遇到过最离谱的一次，产品经理在会前5分钟才把PRD发到群里。结果会上大家问的全是基础问题，一个半小时什么都没定下来。
会前必须完成的3件事：
- 提前48小时发出文档：PRD、原型、技术方案，一个都不能少
- 标注评审重点：用高亮标出变更点、风险点、依赖项
- 收集初步反馈：让参会者提前把问题写在文档评论区
我个人习惯在会前做一次「预审」。把文档过一遍，把明显有问题的点先圈出来。这样会上就能直奔主题。
小技巧：在文档开头加一个「变更摘要」表格，列出本次改动的所有模块和影响范围。参会者扫一眼就知道跟自己有没有关系。
4.2 会中控制：别让评审会变成流水账
评审会最怕什么？
怕的是「逐页过文档」。一个人念，一群人听，偶尔有人问一句「这个字段什么意思」。
这不是评审，这是朗读会。
我建议的会中流程：
- 开场定调（5分钟）：主持人说清楚本次评审的目标、范围、决策边界
- 核心逻辑讲解（15-20分钟）：产品经理只讲变更点和争议点，不念文档
- 分模块讨论（30-40分钟）：按模块逐一过，每个模块留5分钟提问
- 风险与依赖确认（10分钟）：明确哪些需要跨团队协调，哪些需要技术预研
- 结论与行动项（5分钟）：当场确认通过/驳回/需修改，指定责任人
我曾经踩过的坑：
有一次评审会，大家讨论一个边缘case讨论了40分钟。最后发现这个case根本不会出现。从那以后，我要求会上必须有一个「时间官」，超时就喊停。争议问题如果5分钟内没有结论，直接挂起，会后单独拉会。
还有一个关键点：记录要同步。我习惯用在线文档实时记录结论，投在屏幕上。大家看着写，有异议当场改。这样会后就不会有人翻脸说「我没同意过」。
4.3 会后跟进：评审结束才是工作的开始
很多团队评审会开完就完了。需求改没改？问题解没解决？没人管。
结果到了开发阶段，才发现需求还有一堆坑。
会后24小时内必须完成的3件事：
| 动作 | 责任人 | 产出物 |
|---|---|---|
| 发出评审纪要 | 主持人 | 包含结论、待办项、时间节点 |
| 更新需求文档 | 产品经理 | 根据评审意见修改PRD |
| 确认遗留问题 | 相关方 | 每个问题都有明确的解决时间和负责人 |
我个人习惯在评审纪要里加一个「状态标记」：
- ✅ 通过：可以直接进入开发
- 🔄 需修改：修改后二次评审或邮件确认
- ❌ 驳回：需要重新设计方案
一个实用的模板：
# 需求评审纪要 - [项目名称]
日期：2024-XX-XX
主持人：[姓名]
参会人：[名单]
## 评审结论
- 整体状态：🔄 需修改
- 通过模块：用户登录、订单列表
- 需修改模块：支付流程（详见下方）
## 遗留问题
| 问题描述 | 责任人 | 解决时间 | 状态 |
|---------|--------|---------|------|
| 支付超时逻辑不清晰 | 张三 | 2024-XX-XX | 进行中 |
| 退款流程缺少异常处理 | 李四 | 2024-XX-XX | 待确认 |
## 下次评审安排
- 时间：2024-XX-XX 14:00
- 范围：支付流程修改版
说白了，评审会不是终点，而是起点。会前把功课做足，会中把节奏控好，会后把闭环做死。这样评审会才能真正帮团队对齐需求，而不是走个过场。
最后说一句：如果你们团队每次评审会都超过2小时，说明会前准备没做到位。试着把时间压缩到1小时以内，你会发现效率反而更高。