4、需求管理协作：需求获取、需求分析、需求评审、需求变更管理中的团队配合
说到需求管理，我脑子里立刻浮现出几年前的一个项目。
那是一个ADAS控制器项目，客户是欧洲一家Tier1。我们团队花了三个月写需求文档，结果评审会上被客户怼得体无完肤——「你们写的不是需求，是你们自己的臆想」。嗯，那次之后我才真正明白，需求管理不是一个人闷头写文档，而是一群人的协作艺术。
4.1 需求获取：别坐在工位上等需求
很多团队有个误区：需求是客户给的，我们等着就行。
其实不是。需求获取是个主动出击的过程。我个人习惯在项目启动前，拉着系统工程师、测试工程师、甚至生产线的工艺工程师一起，跟客户开一个「需求澄清会」。会上我会问三个问题：
- 这个功能到底解决什么问题？——别只听客户说要什么，要理解他为什么需要
- 有没有边界条件？——比如温度范围、电磁环境、使用寿命
- 你们内部测试过类似功能吗？——这能帮我们避开一些已知的坑
举个例子。有一次客户说「需要支持OTA升级」。我们系统工程师直接写了个「支持远程固件升级」的需求。结果测试工程师问了一句：「升级过程中断电怎么办？」——好家伙，这一问引出了三个子需求：断点续传、回滚机制、升级失败后的状态恢复。
你想想看，如果测试没参与，这些细节可能要到集成测试阶段才发现。那时候改起来，成本至少翻五倍。
4.2 需求分析：把「人话」翻译成「技术话」
需求分析说白了就是翻译工作。客户说「我要车跑得快」，你得翻译成「电机输出扭矩≥XXX Nm，0-100km/h加速时间≤X秒」。
但这里有个关键点：翻译不是一个人能完成的。
我建议的做法是：
- 系统工程师负责把客户需求拆解成功能需求
- 软件工程师负责把功能需求拆解成软件需求
- 硬件工程师负责把功能需求拆解成硬件需求
- 测试工程师负责验证每个需求是否可测试
这个过程中，最容易出问题的是「需求传递失真」。我记得有个项目，客户说「报警声音要清晰」。系统工程师写成了「蜂鸣器频率2kHz」。软件工程师实现了2kHz方波。结果测试时发现——声音是有了，但尖锐得让人想砸车。
为什么会这样？因为「清晰」不等于「2kHz」。客户想要的可能是「在60dB环境噪音下，报警声能被清晰辨识」。这涉及到频率、声压级、调制方式等多个参数。
4.3 需求评审：别让评审变成「走过场」
需求评审，很多团队的做法是：发一封邮件，附上文档，让大家在三天内提意见。结果呢？没人看，或者看了也不说。
我个人的做法是：开评审会，而且必须面对面。
评审会我一般这样组织：
| 角色 | 职责 | 关注点 |
|---|---|---|
| 需求作者 | 逐条讲解需求 | 确保大家理解一致 |
| 系统工程师 | 检查需求完整性 | 有没有遗漏的功能？ |
| 软件/硬件工程师 | 检查可实现性 | 技术上能不能做？成本是否可控？ |
| 测试工程师 | 检查可测试性 | 每条需求都能设计测试用例吗？ |
| 项目经理 | 检查优先级和资源 | 需求是否与项目计划匹配？ |
评审会上，我要求每个人必须至少提一个问题。如果没人提问，我会点名：「老王，你觉得这条需求有没有歧义？」——逼着大家思考。
另外，评审记录一定要保留。我习惯用工具（比如Jama或Doors）记录每条需求的评审意见和修改历史。这样以后出了问题，可以追溯是谁在什么时间提出了什么意见。
4.4 需求变更管理：变更是常态，不变才是意外
做汽车电子的人都知道，需求变更是家常便饭。客户今天说要加个功能，明天又说要改个参数。如果你没有一套规范的变更管理流程，项目迟早会失控。
我经历过最惨的一次：项目中期，客户要求增加一个「自动泊车辅助」功能。项目经理觉得「加就加吧，反正代码量不大」。结果呢？这个功能涉及到超声波传感器驱动、路径规划算法、人机交互界面——三个模块都要改。最后项目延期了两个月，成本超支了30%。
从那以后，我坚持用ASPICE的变更管理流程：
- 变更请求：任何变更都必须以书面形式提出，说明变更原因和期望效果
- 影响分析：评估变更对成本、进度、质量、安全的影响
- 变更控制委员会（CCB）评审：由项目经理、系统工程师、测试经理、客户代表共同决策
- 变更实施：批准后，更新需求文档、设计文档、测试用例
- 变更验证：实施完成后，验证变更是否达到预期效果
变更管理中最容易被忽视的是「沟通」。很多团队只关注技术层面的变更，忘了通知相关方。比如需求变了，测试用例没更新；或者软件改了，硬件接口没同步。这些都是血的教训。
我建议在变更流程中加一个「通知清单」：谁需要知道这个变更？系统工程师？测试工程师？生产部门？供应商？——确保所有人都同步。
4.5 团队配合的底层逻辑
说了这么多，其实核心就一句话：需求管理不是一个人的事，是一群人的事。
我见过太多团队，系统工程师闷头写需求，软件工程师闷头写代码，测试工程师闷头写用例。结果到了集成阶段，发现需求对不上、接口对不上、测试用例也覆盖不全。
为什么会这样？因为大家各自为战，没有形成协作闭环。
我个人总结了一个「需求管理协作三角」：
- 系统工程师是「翻译官」——把客户需求翻译成技术语言
- 开发工程师是「实现者」——把技术语言变成可运行的代码/硬件
- 测试工程师是「验证者」——确保实现的结果符合需求
这三个角色必须紧密配合，缺一不可。而且配合不是一次性的，而是贯穿整个项目生命周期。
1. 我这周做了什么跟需求相关的事？
2. 我遇到了什么问题？
3. 我需要谁的支持？
这样能确保问题不过夜，需求不走偏。
最后说一句：需求管理做得好不好，直接决定了项目是「顺风顺水」还是「鸡飞狗跳」。别等到集成测试时才发现需求有问题——那时候改起来，成本高得让你心疼。
嗯，今天就聊到这里。下一章我们聊聊「架构设计中的团队协作」，那也是个容易踩坑的地方。