程序员如何做「需求分析」：不是传话筒，是桥梁
很多程序员觉得需求是 PM 的事，自己只管实现。
但不懂需求的程序员，只能做执行者；懂需求的程序员，才能做创造者。
一、需求分析的目的
1. 理解真实需求
用户说"要一匹更快的马"，真实需求是"要更快到达目的地"。
2. 评估技术可行性
技术上能不能实现，成本有多高。
3. 给出技术方案
根据需求给出最好的技术实现方式。
4. 避免返工
需求不清楚就开始做，做完发现不是想要的。
二、需求分析的方法
1. 5W1H 分析法
- What：做什么
- Why：为什么做
- Who：谁用
- When：什么时候用
- Where：在哪用
- How：怎么做
2. 需求拆解
- 大需求拆成小需求
- 每个小需求要独立、可测试
3. 优先级排序
- MoSCoW：Must/Should/Could/Won't
- KANO：基本型/期望型/兴奋型
4. 需求验证
- 原型图确认
- 用例场景演练
- 用户故事地图
三、和 PM 协作
1. 主动沟通
- 不懂就问，不要猜
- 给出技术视角的建议
- 解释技术约束
2. 管理期望
- 不要过度承诺
- 给出真实的时间和风险
3. 提供选择
- 给出多个方案
- 讲清楚每个方案的利弊
4. 记录决策
- 需求变更要记录
- 双方确认
四、技术方案配合
1. 评估技术方案
- 这个需求用什么技术实现最合适
- 有没有更简单的方案
2. 提前发现风险
- 性能风险
- 安全风险
- 兼容性风险
3. 规划扩展性
- 这次的需求，会不会影响未来的需求
- 留好扩展接口
五、常见错误
❌ 不问就开始做
"我以为是这样"——结果可能完全不对。
❌ 只做不想
PM 说什么就做什么，不思考为什么。
❌ 过度设计
为了显示技术能力，做了很多不需要的功能。
❌ 不记录变更
需求变了好几次，没有记录，最后分不清哪个是最终版。
六、一句话总结
需求分析 = 理解真实需求 + 评估可行性 + 给出方案 + 避免返工，核心是做好需求方和技术方的桥梁。