程序员如何做「需求评审」：不是过流程，是价值把控
需求评审是产品开发的入口。
入口把控不好，后面全是坑。
一、需求评审的目的
1. 明确需求
确保团队对需求理解一致。
不是"产品说是这样"，是"大家都理解是这样"。
2. 发现问题
- 需求不合理的地方
- 需求遗漏的地方
- 技术实现困难的地方
3. 评估可行性
技术能不能做？要多久？成本多少？
4. 确定优先级
资源有限，需求无限。确定先做哪个。
二、需求评审的参与者
1. 产品经理
讲需求。
2. 开发
评估技术可行性。
3. 测试
提前了解需求，准备测试方案。
4. 设计（如果涉及 UI）
评估 UI 实现成本。
三、需求评审看什么
1. 需求完整性
- 用户是谁
- 想解决什么问题
- 核心流程是什么
- 边界情况是什么
2. 需求合理性
- 这个需求真的必要吗
- 用户真的需要这个吗
- 有更简单的方案吗
3. 技术可行性
- 能不能做
- 要多久
- 有没有依赖
4. 优先级
- 这个需求值多少分
- 资源够不够做
四、开发在评审中的职责
1. 问问题
不理解的地方要问清楚。
不要猜，不要假设计算。
2. 提风险
发现技术风险要说出来。
不要等产品上线了再说"这个有风险"。
3. 给建议
从技术角度给更好的方案建议。
不是拒绝，是优化。
4. 控成本
评估开发成本，让产品知道投入产出比。
五、常见错误
❌ 不问问题
"产品经理说的肯定对"——不一定。
❌ 评审时不说
"这个有风险，但先这样吧"——后面会后悔。
❌ 评审后才发现问题
评审的时候不认真，评审完才发现做不了。
❌ 需求频繁变更
评审通过了，过两天又要改。
六、一句话总结
需求评审 = 明确需求 + 发现问题 + 评估可行性 + 确定优先级，开发要问问题、提风险、给建议、控成本。