4、需求分析入门：区分「想要」和「需要」

做工程师那会儿，我最怕听到一句话：「用户说他要这个功能。」

你想想看，用户说要一个红色的按钮，你就给他一个红色的按钮。结果做出来，他不用。为什么？因为他真正需要的是「在紧急情况下能快速找到停止键」。红色按钮只是他以为的解决方案。

这就是「想要」和「需要」的区别。我花了整整三年才搞明白这件事。

4.1 为什么工程师总在这上面栽跟头？

我们工程师有个通病：喜欢直接解决问题。用户说「我要A」，我们就开始设计A、实现A、测试A。完美交付，然后用户说「这不是我要的」。

问题出在哪？出在我们把「用户说的」当成了「用户需要的」。

我个人习惯把需求分成三层：

层次	定义	例子
表面需求	用户嘴上说的	「我要一个导出Excel的功能」
真实需求	用户实际要解决的问题	「我需要把数据发给财务做对账」
底层需要	用户没说的动机	「我每周要花3小时手动对账，太累了」

我在项目中遇到过最典型的案例：客户要求给APP加一个「夜间模式」。开发了两个月，上线后使用率不到5%。后来一聊才知道，他真正需要的是「在暗光环境下看报表不刺眼」。一个简单的「亮度自适应」就能解决，根本不用重绘整个UI。

4.2 区分「想要」和「需要」的三个方法

方法一：追问「为什么」五次

这是丰田生产系统的经典方法。别觉得幼稚，真的管用。

举个例子：

1. 用户：「我要一个搜索框」
2. 追问：「为什么需要搜索框？」
3. 用户：「因为我要快速找到历史订单」
4. 追问：「为什么需要快速找到历史订单？」
5. 用户：「因为我要查上个月的退款记录」
6. 追问：「为什么需要查退款记录？」
7. 用户：「因为财务要核对退款金额」
8. 追问：「为什么财务要核对？」
9. 用户：「因为月底对账发现少了3000块」

看到没？真正的需要是「对账准确性」，而不是「搜索框」。解决方案可能是自动对账系统，而不是一个搜索功能。

方法二：区分「功能」和「收益」

用户描述需求时，通常说的是功能。你要把它翻译成收益。

用户说的（功能）	翻译后的（收益）
「加一个批量删除」	「减少重复操作，节省时间」
「做数据可视化大屏」	「让管理层一眼看到关键指标」
「支持多语言」	「拓展海外市场，增加用户量」

我建议你每次接到需求，先写两列：左边是用户原话，右边是你理解的收益。如果收益不清晰，说明需求还没挖透。

方法三：观察行为，而不是听他说什么

用户说的和做的，往往是两回事。

我记得有个项目，用户说「我们需要一个强大的报表系统」。结果我们去现场观察，发现他们每天就用三个固定报表。其他几十个报表功能，从来没人点过。

为什么会这样？因为「强大」听起来很专业，但实际工作流只需要那三个。用户想要的是「看起来很厉害的系统」，但需要的是「每天能稳定出那三张表」。

4.3 避坑指南：工程师常见的三个误区

4.4 实战：一个需求分析模板

说了这么多，给个能直接用的东西。我每次接需求都会填这个表：

需求分析卡片
━━━━━━━━━━━━━━━━━━━━━━━━━━
需求来源：________（用户/老板/竞品/数据）
用户原话：________
━━━━━━━━━━━━━━━━━━━━━━━━━━
【第一层】表面需求：________
【第二层】真实需求：________
【第三层】底层需要：________
━━━━━━━━━━━━━━━━━━━━━━━━━━
验证方法：
1. 这个需求覆盖多少用户？____%
2. 不做会怎样？________
3. 有没有更简单的方案？________
━━━━━━━━━━━━━━━━━━━━━━━━━━
最终决策：□ 做  □ 不做  □ 暂缓
理由：________

这个模板看起来简单，但能帮你过滤掉至少一半的伪需求。我团队现在全员用这个，需求评审会的效率提高了不少。

4.5 小结

区分「想要」和「需要」，说白了就是别当传话筒。用户说「我要一匹马」，你别真去牵一匹马回来。你得搞清楚，他是要去隔壁村，还是要去隔壁省。

去隔壁村，给他一辆自行车就够了。去隔壁省，得给他买张高铁票。

嗯，这个道理我用了好几年才真正想明白。希望你不用走那么多弯路。