程序员如何做「需求评审」：不是吵架，是对齐
需求评审是开发团队和需求方对齐的重要会议。
开得好能提前发现问题，开不好就是走过场。
一、需求评审的目的
1. 理解需求
所有人都对需求有共同的理解。
不是各理解各的。
2. 发现问题
- 技术上能不能实现
- 有没有遗漏的场景
- 有没有冲突的需求
3. 评估成本
开发团队评估工作量。
让需求方知道成本。
4. 达成共识
需求方和开发方对最终方案达成一致。
二、评审前的准备
1. 需求文档
评审前 1-2 天发出需求文档。
让评审者有时间看。
2. 确定参会人
- 产品
- 开发
- 测试
- UI（如果涉及界面）
3. 明确评审重点
这次评审重点是什么？是整体方案还是细节？
三、评审会议怎么开
1. 产品讲解
产品讲解需求背景和目标。
不是念文档，是讲清楚"做什么"和"为什么"。
2. 开发提问
开发针对需求提问。
技术可行性、边界条件、依赖关系。
3. 逐条讨论
有争议的地方重点讨论。
达成一致后记录结论。
4. 明确结论
评审结束前，明确：
- 通过
- 需要修改后再次评审
- 取消
四、评审中的常见问题
1. 需求不清晰
"这个按钮点完显示什么？"——需求描述不完整。
2. 场景遗漏
正常流程有，异常流程没写。
3. 技术约束
需求听起来简单，技术实现很复杂。
4. 依赖不清
"这个需要 XX 系统先上线"——依赖关系没说清楚。
五、评审后跟踪
1. 会议记录
记录讨论的结论和待确认事项。
2. 分配任务
评审中发现的问题，分配负责人。
3. 确认时间
确认需求定稿时间，开发开始时间。
六、一句话总结
需求评审 = 评审前准备 + 产品讲解 + 开发提问 + 逐条讨论 + 明确结论 + 评审后跟踪，核心是对齐和发现问题。