需求评审方法实践
# 需求评审方法实践
PRD评审、技术方案评审、风险识别——评审不仔细，开发两行泪
# 一、需求评审不是 PRD 朗读会
❌ 常见场景：
产品经理投屏 PRD，逐页念过去。
工程师坐着听，偶尔问一句"这个字段从哪里取"。
没有人提出反对意见。没有人在算开发成本。没有人在想边界条件。
评审结束——"都没问题吧？好，开始开发。"
→ 两周后开发到一半发现逻辑无法闭环，需求变更从头开始。
1
2
3
4
5
6
2
3
4
5
6
评审的目的不是"确认需求"——是"在写代码之前把所有疑问都炸出来"。 评审结束后还有疑问的，是评审没做好。
# 二、PRD 评审——工程师该问的 7 个问题
1. 这个需求解决谁的什么问题？（有没有数据？）
→ PRD 上写"用户需要 XX 功能"→ 追问：多少用户？什么场景？有没有工单/数据？
2. 异常路径怎么处理？
→ PRD 只写了正常路径 → 追问："如果支付中途网络断了呢？""如果商品下架了呢？"
3. 和现有功能有没有冲突？
→ 新需求加了一个"自动取消订单"→ 老功能里有个"手动取消"→ 两个同时触发怎么办？
4. 优先级是什么？不做会怎样？
→ 不是所有需求都是 P0。如果资源不够，这个功能和另外 3 个比，谁先做？
5. 数据从哪来？更新频率？
→ "这个页面要展示推荐商品"→ 推荐结果从哪个接口取？实时还是离线？多久更新一次？
6. 边界数据——最大、最小、为空、重复
→ "用户可以填备注"→ 最长多少字？可以空吗？重复提交同一内容怎么处理？
7. 上线后怎么判断做对了？
→ 验收标准是什么？"用户满意度提升"不可测量——"使用率 > 20% 且投诉率不升"可测量
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
评审时你少问一个问题，开发中就可能多花两天。
# 三、技术方案评审——不要只给一个方案
# 3.1 方案对比表
技术方案不是写"我做了什么"——是写"我为什么选了这个而不是别的"。
方案对比表（必须有）：
| 维度 | 方案A：MQ异步 | 方案B：线程池 | 方案C：不处理 |
|---|---|---|---|
| 可靠性 | 消息持久化 | 重启丢失 | N/A |
| 复杂度 | 引入新组件 | 纯代码 | 无 |
| 性能影响 | +50ms | +5ms | 0 |
| 开发成本 | 2 天 | 0.5 天 | 0 |
| **结论** | ✅ 推荐 | 备选 | 不可接受 |
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
没有对比的方案不是方案——是通知。
# 3.2 评审时要确认的 5 个风险
风险 1：数据一致性
→ "订单状态改了，但库存没扣——这种不一致会持续多久？最终能一致吗？"
风险 2：性能影响
→ "这个新接口调用链上多了 3 次 RPC——P99 预估多少？测试过吗？"
风险 3：下游影响
→ "你改了用户表的字段——哪些下游服务依赖这个表？通知过吗？"
风险 4：回滚复杂度
→ "如果上线后发现有问题——回滚是纯代码回滚，还是需要回滚数据库？"
风险 5：灰度方案
→ "有没有灰度计划？怎么确认上线后一切正常？"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
评审最大的价值不是挑刺——是让写方案的人自己发现没想过的问题。 你在评审会上问一句"数据库迁移有回滚脚本吗"——对方一愣——你帮他避免了一个生产事故。
# 四、需求变更——评审没做好的代价
需求变更的两种类型：
类型 1：合理的变更
"竞品突然上线了一个功能，我们必须跟进。"
→ 接受，但要重新排优先级：新需求和正在做的功能谁更重要？
类型 2：评审不充分的变更
"开发中发现 PRD 没写这个逻辑，现在要补。"
→ 这是评审的锅。评审时应该发现的问题没发现，现在用开发时间买单。
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
减少类型 2 的唯一办法：评审时多花 30 分钟，开发时省 3 天。
# 五、工程师在评审中的话语权
很多工程师在评审会上沉默——觉得自己"只管实现"。但你沉默的代价是：
产品经理说"这个功能很简单吧" → 你不说话 → 他默认"一天能做完"
→ 你实际上需要 5 天 → 延期 → 产品经理觉得你做慢了
→ 下次他更不会问你的意见，因为"上次问你也没说"
1
2
3
2
3
在评审中建立话语权就一句话：用数据说话，而不是用情绪。
❌ "这个做不了，太复杂了。"
→ "太复杂"是主观评价，产品经理听不懂。
✅ "这个功能需要对接 3 个外部接口、改 2 个数据库表、新增 1 个页面。
乐观估计 5 天。如果我们只做核心路径（砍掉 A 和 B），3 天就够了——你觉得 A 和 B 必须这次做吗？"
→ 你把"复杂"翻译成了"时间 + 范围"，产品经理可以和你商量。
1
2
3
4
5
6
2
3
4
5
6
# 六、小结
评审三阶段：
1. PRD 评审 → 问 7 个问题，确认"做什么"没有歧义和遗漏
2. 技术方案评审 → 对比表 + 5 个风险点，确认"怎么做"没有坑
3. 需求变更 → 区分"合理变更"和"评审不到位导致的变更"
一句话原则：
评审多花 30 分钟，开发省 3 天。你在评审会上问的每一个问题，都是在为未来的自己省时间。
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
行动清单：
- [ ] 下次审 PRD，带着 7 个问题的清单去——哪怕只挑了其中 3 个问
- [ ] 下次写技术方案，不要只给一个——至少给一个对比表（2-3 个方案）
- [ ] 下次评审会上有异议，用"时间 + 范围"的语言表达，而不是"太复杂"
上次更新: 2026/06/15, 14:32:53
