📚 课程目录第1章需求管理总论

1. 需求管理总论：智能座舱需求管理全景图

各位好，我是老张。在座舱行业摸爬滚打了十几年，我见过太多项目因为需求问题翻车。有的车机量产了才发现语音唤醒逻辑跟用户习惯拧着来，有的HMI动效评审时才发现性能根本跑不动。说白了，这些问题根子都在需求管理上。

今天咱们先搭个全景框架。你心里有了这张图，后面每一章才能找到位置。

智能座舱的需求，不是一堆功能列表那么简单。它是个多维度、多角色、多阶段的系统工程。我个人习惯把全景图分成三个圈：

你想想看，一个语音助手的需求，核心圈要定义“说什么话做什么事”，流程圈要经历“用户调研→写用例→评审→集成测试→客户反馈改需求”，支撑圈得有Jira、Polarion、SVN这些工具兜底。缺一环，后面就乱。

我的经验：全景图不是画完就完的。我每接手一个新项目，第一件事就是把全景图拉出来，跟产品、开发、测试对齐一遍。哪怕花半天时间，也比后期返工省一个月。

V模型在汽车行业用了很多年。为什么？因为它把“验证”和“定义”对应起来了。我见过不少团队把需求文档写完就扔给开发，等到测试才发现需求本身就有问题。V模型的核心思想就是：左侧定义什么，右侧就验证什么。

需求管理在V模型里，就是左侧的“骨架”。没有需求，左侧就是空的，右侧验证也就无从谈起。我记得有一次，一个HUD项目，左侧系统需求里写了“亮度自动调节”，但没定义“自动”的触发条件。结果右侧测试时，开发说根据环境光传感器，测试说根据车速。两边吵了一个星期。你看，这就是需求定义不清晰挖的坑。

小技巧：在V模型里，每个需求条目都应该能追溯到右侧的测试用例。我习惯在需求文档里直接加一列“验证方法”，写清楚是“测试”、“评审”还是“演示”。这样右侧团队拿到需求就知道怎么下手。

核心流程就五个字：获取、分析、定义、验证、变更。咱们一个一个说。

需求从哪来？用户访谈、竞品分析、法规标准、内部 brainstorm、售后反馈……渠道很多。但要注意，获取不是“收集”，而是“挖掘”。用户说“我想要大屏”，背后可能是“我看不清导航信息”。你挖到根上，需求才靠谱。

拿到原始需求后，得分析。分析什么？优先级、可行性、冲突点、依赖关系。我常用的方法是画一个需求依赖图。比如“语音控制天窗”依赖“天窗电机控制接口”和“语音识别引擎”。如果依赖项没到位，这个需求就得往后排。

定义阶段要把“人话”翻译成“技术语言”。用户说“导航要快”，你得定义成“冷启动首次定位时间 ≤ 30秒，热启动 ≤ 5秒”。定义要可量化、可测试、无歧义。嗯，这里要注意，别写“界面美观”这种没法验证的词。

验证不是等到最后才做。每个需求定义完，就要想“我怎么证明它实现了？”我建议在需求文档里直接写验证标准。比如“语音唤醒成功率 ≥ 95%，测试环境：车内40dB背景噪声”。这样开发、测试、产品三方都清楚。

变更不可避免。客户改主意、法规更新、技术方案调整，都会触发变更。但变更要有流程：提交申请→影响分析→评审→批准→更新基线。我曾经见过一个项目，变更不走流程，开发直接改代码，结果测试用例全废了，回归测试跑了三周。血的教训。

避坑指南：我曾经在一个座舱项目中，客户口头说“加一个功能”，开发觉得简单就顺手改了。结果两个月后客户不认账，说“我没说过”。从那以后，我定了一条铁律：任何变更，必须有书面记录和评审签字。口头变更一律不认。

工具链是支撑圈的核心。没有工具，需求管理就是手工作坊。我按阶段给你列一下常用工具：

工具不在多，在于用得透。我个人习惯是：一个核心平台（比如Polarion）管需求条目，一个协作平台（比如Jira）管任务和变更，一个版本控制（比如Git）管文档基线。三个工具打通，基本够用。

我的建议：别一上来就上大而全的工具链。先跑通流程，再上工具。我见过一个团队，买了DOORS license，结果没人会用，最后需求还是写在Excel里。工具是服务流程的，不是反过来。

好了，这一章的全景图、V模型位置、核心流程、工具链，咱们都过了一遍。你心里有个框架，后面每一章就是往这个框架里填细节。记住一句话：需求管理不是文档工作，是工程工作。它决定了你的座舱产品是精品还是烂尾。