新能源汽车控制器V流程与量产工程 - 第1节
1. 课程导入
说实话，我刚入行那会儿，觉得需求分析就是「客户说啥我做啥」。结果呢？做了三个月，客户说「这不是我要的」。嗯，白干了。
需求分析，说白了就是搞清楚两件事：用户到底想要什么，以及我们到底要做什么。它不是简单的「记录需求」，而是把模糊的、矛盾的、甚至不切实际的想法，翻译成可执行的产品方案。
核心定义：需求分析是将用户期望转化为系统行为的过程。它连接了「问题空间」和「解决方案空间」。
需求分析在项目中的位置
我习惯把产品开发流程画成一条线：
你看，需求分析卡在中间。前面是需求收集，后面是系统设计。它像个翻译官——把客户的「方言」翻译成工程师的「普通话」。
我的经验：需求分析阶段花的时间越多，后期返工越少。我做过一个项目，需求分析做了3周，开发只用了4周，一次上线成功。另一个项目需求分析只用了3天，结果开发做了3个月，上线后改了半年。
二、常见的需求陷阱与误区
这些年我踩过的坑，十个手指头数不过来。下面这几个是最常见的，你想想看，是不是也遇到过？
陷阱一：把「解决方案」当「需求」
客户说：「我要一个红色的按钮，放在页面右上角。」
这是需求吗？不是。这是解决方案。真正的需求是：「用户需要快速找到退出功能。」
| 类型 | 错误示例 | 正确示例 |
|---|---|---|
| 用户说 | 「我要一个下拉菜单」 | 「我需要选择省份」 |
| 需求本质 | 具体控件 | 业务功能 |
| 分析后 | 直接做下拉菜单 | 评估：下拉菜单、弹窗选择、输入联想，哪种更好？ |
避坑指南：我曾经接手一个项目，客户要求「用表格展示所有数据」。我们做了，结果用户根本看不完。后来才发现，用户真正需要的是「按条件筛选出关键数据」。一个搜索功能就解决了，比表格好用十倍。
陷阱二：需求「我以为」
「这个功能用户肯定喜欢。」「这么简单，不用问了吧。」——这些话我听过太多次了。结果呢？做出来没人用。
为什么会这样？因为你以为的需求，和用户真正的需求，中间隔着一条河。
- 你以为用户想要更多功能 → 实际上用户想要更简单的操作
- 你以为用户会看帮助文档 → 实际上用户根本不看
- 你以为这个流程很合理 → 实际上用户的操作习惯完全不同
我的习惯：每次做需求分析，我都会问自己三个问题：
- 这个需求是谁提出来的？是用户还是老板？
- 这个需求解决了什么具体问题？
- 如果不做这个功能，用户会怎样？
三个问题问完，一半的需求会被砍掉或重新定义。
陷阱三：需求「大而全」
「我们要做一个平台，包含所有功能。」——这种需求我见一个怕一个。说白了，这是需求范围失控的前兆。
我建议的做法是：先做核心流程，再做边缘功能。用MVP（最小可行产品）思维来切分需求。
| 阶段 | 包含内容 | 时间占比 |
|---|---|---|
| MVP | 核心业务闭环，能跑通就行 | 40% |
| V2.0 | 优化体验，补充常用功能 | 30% |
| V3.0 | 高级功能、报表、配置化 | 30% |
核心原则：需求分析不是「把需求都记下来」，而是「判断哪些需求现在做，哪些以后做，哪些不做」。
陷阱四：忽略「非功能性需求」
很多团队只盯着功能需求——「能下单」「能支付」「能查询」。但真正让项目死掉的，往往是那些看不见的东西。
- 性能：用户量上来后，系统会不会崩？
- 安全性：数据会不会泄露？
- 可维护性：三个月后，新来的同事能看懂代码吗？
- 可扩展性：下个版本加功能，会不会要重构？
我曾经... 做过一个电商项目，功能全做完了，上线第一天，100个人同时下单，数据库直接挂了。原因？需求分析时没人提过「并发量」这个事。后来花了两个星期重构，老板差点把我开了。
三、需求分析的核心产出
说了这么多坑，那需求分析到底要产出什么？我一般要求团队交付以下三样东西：
- 需求清单（Backlog）：按优先级排列的功能列表
- 用户故事（User Story）：描述用户使用场景和期望结果
- 原型/线框图：可视化的界面示意，用来和用户确认
这三样东西，缺一不可。需求清单告诉你「做什么」，用户故事告诉你「为什么做」，原型告诉你「做成什么样」。
一个小技巧：每次做完需求分析，我都会把产出物拿给用户看，让他签字确认。不是我不信任用户，而是——白纸黑字，后面扯皮的时候有个依据。你想想看，是不是这个道理？
四、本章小结
需求分析不是什么高深的理论，它就是把话说清楚、把事想明白的过程。记住三个关键词：
- 翻译：把用户的话翻译成技术语言
- 过滤：把不靠谱的需求过滤掉
- 排序：把需求按优先级排好队
做到这三点，你的项目已经成功了一半。剩下的，就是执行了。