需求分析与定义：从模糊到清晰的第一道坎
说实话，很多座舱项目翻车，不是死在代码上，而是死在需求上。我见过太多团队，产品经理扔过来一页「要做个智能座舱」，然后大家就开始撸代码了。结果呢？三个月后才发现，用户真正想要的功能一个没做，做出来的东西没人用。
这一章，我们就聊聊怎么把「老板的一句话」变成「可落地的需求文档」。我个人习惯把这步叫做「从玄学到科学」的转变。
用户画像构建：你的用户到底是谁？
做座舱交互，最怕的就是「我以为」。你以为用户喜欢大屏？你以为用户需要语音控制？别猜，去建画像。
用户画像不是编故事，而是基于真实数据的抽象。我一般会从三个维度切入：
- 人口属性：年龄、性别、职业、收入（决定购买力和审美偏好）
- 驾驶行为：通勤时长、驾驶经验、常用路线（决定交互频率和复杂度）
- 技术接受度：是否习惯用智能设备、对语音/手势的容忍度（决定交互方式）
一个真实的例子：
我之前做某自主品牌的项目，目标用户是「35-45岁、家庭用户、每天通勤1小时以上」。画像出来后我们发现，这群人最在意的不是酷炫的3D仪表，而是「导航能不能少点两步操作」和「孩子在后排能不能安静看动画片」。你看，需求一下子就聚焦了。
画像是活的，不是写完了就锁进抽屉。我建议每个迭代都回头看看画像，用户变了，需求就得跟着变。
场景化需求挖掘：别问「要什么」，问「在什么情况下」
传统需求调研最大的坑是什么？就是直接问用户「你想要什么功能」。用户不是产品经理，他只会说「我想要个更快的车」或者「屏幕能不能再大点」。这没用。
我习惯用场景化挖掘。说白了，就是还原用户的使用情境。举个例子：
| 场景 | 用户行为 | 痛点 | 潜在需求 |
|---|---|---|---|
| 早高峰通勤 | 边开车边看导航，手机支架挡住出风口 | 视线转移频繁，安全隐患大 | HUD导航投射、语音控制路线切换 |
| 周末带娃出游 | 孩子在后排哭闹，驾驶员分心安抚 | 驾驶注意力被分散，情绪烦躁 | 后排娱乐系统、亲子语音交互、情绪安抚模式 |
| 长途驾驶疲劳 | 连续驾驶2小时以上，反应变慢 | 疲劳驾驶风险高，缺乏有效提醒 | 疲劳监测、主动休息建议、香氛/音乐调节 |
你看，每个场景都能挖出具体的需求。而不是笼统地说「做个智能座舱」。场景化挖掘的核心是：时间 + 地点 + 人物 + 行为 + 情绪。把这五个要素写清楚，需求自然就出来了。
我的一个小技巧：
每次做场景挖掘，我都会拉上开发、测试、设计一起「演一遍」。找个会议室，模拟驾驶环境，大家轮流当用户。演着演着，很多隐藏需求就冒出来了。这比开十次评审会都管用。
功能优先级排序：MoSCoW方法，别什么都想要
需求挖出来了，少说也有几十条。但资源有限，时间有限，不可能全做。这时候就需要排序了。
我强烈推荐MoSCoW方法。不是莫斯科，是四个字母的缩写：
- M - Must have（必须有）：没有这个功能，产品无法上线。比如仪表盘显示车速、刹车报警。
- S - Should have（应该有）：很重要，但可以晚一点。比如语音控制空调温度。
- C - Could have（可以有）：锦上添花，有更好，没有也行。比如氛围灯随音乐律动。
- W - Won't have（这次不做）：明确放弃，下次迭代再说。比如车载KTV。
为什么这个方法好用？因为它逼着团队做取舍。我曾经遇到一个项目，产品经理把所有需求都标成「Must have」，结果开发周期排了两年。后来我们用MoSCoW重新梳理，砍掉了40%的功能，项目提前三个月交付。
避坑指南：
我曾经犯过一个错：把「Should have」和「Could have」混在一起，结果开发团队按自己的理解做了优先级，上线后用户最想要的功能反而没做。后来我定了个规矩：每个需求必须标注明确的MoSCoW分类，并且经过三方（产品、开发、测试）签字确认。谁改谁负责。
排序的时候，我一般会画一个四象限图：横轴是「用户价值」，纵轴是「实现成本」。Must have就是高价值、低成本的那些；Won't have就是低价值、高成本的。这样一看，优先级一目了然。
需求文档撰写规范：写清楚，别让人猜
需求文档是团队的「宪法」。写得好，开发、测试、设计各司其职；写不好，就是互相甩锅的导火索。
我总结了一套模板，用了好几年，效果不错：
# 需求文档模板（精简版）
## 1. 需求编号
REQ-2024-001
## 2. 需求名称
HUD导航信息投射
## 3. 场景描述
用户早高峰通勤，车速60km/h，前方500米需右转。
当前导航信息在仪表盘显示，用户需低头查看，存在安全隐患。
## 4. 功能描述
- 在HUD区域投射导航箭头、距离、车道信息
- 箭头颜色随距离变化（500m-绿色，200m-黄色，50m-红色）
- 支持语音播报「前方500米右转」
## 5. 验收标准
- HUD显示延迟 < 100ms
- 箭头颜色变化准确率 100%
- 语音播报与HUD显示同步误差 < 50ms
## 6. MoSCoW分类
Must have
## 7. 依赖项
- HUD硬件驱动接口（由硬件团队提供）
- 导航SDK版本 ≥ 3.2
## 8. 风险点
- HUD亮度在强光下可能不够，需预留亮度调节接口
你看，这样写，开发拿到就知道要做什么，测试拿到就知道怎么测，设计拿到就知道画什么。不会出现「我以为你要做A，结果你做成了B」的情况。
写文档的三个原则：
- 量化：别写「响应要快」，写「响应时间 < 100ms」
- 可测试：每个需求都要能写出验收标准，写不出来的需求就是伪需求
- 版本化：每次修改都要更新版本号，别让团队拿着旧文档干活
嗯，这里要注意一点：需求文档不是写一次就完了。随着项目推进，需求一定会变。我习惯用Git管理需求文档，每次变更都留记录。这样出了问题，能追溯到是谁、在什么时候、为什么改的。
好了，这一章的内容就是这些。从用户画像到场景挖掘，从MoSCoW排序到文档撰写，每一步都是为了把模糊的需求变成清晰的行动指南。记住一句话：需求分析做得好，项目交付少烦恼。