3. 需求获取技术：在嵌入式场景下怎么用
需求获取这事儿，说白了就是搞清楚客户到底想要什么。我在嵌入式这行干了十几年，见过太多项目翻车，根源往往不是技术不行，而是需求没问对。你想想看，一个硬件方案定下来，改一次就是几万块的打板费，软件架构搭错了，后面重构的代价更是吓人。
所以这一章，咱们就聊聊五种主流的获取技术——用户访谈、问卷调查、文档分析、原型法、观察法。每种我都会结合嵌入式场景，说说怎么用、有什么坑。
核心观点：嵌入式需求获取，不能只靠一种方法。硬件约束多、用户场景杂，必须组合使用。我个人习惯是「文档分析打底 + 访谈定方向 + 原型验证关键点」。
3.1 用户访谈——最直接，但也最容易跑偏
用户访谈，就是面对面聊。嵌入式项目里，访谈对象通常有三类：
- 最终用户——比如产线上的操作工、设备维护人员
- 客户决策者——比如产品经理、技术总监
- 领域专家——比如懂电机控制的工程师、懂通信协议的老手
我建议你每次访谈前，先列一个访谈提纲。别太死板，但核心问题不能漏。比如问操作工：「你现在调这个参数，要按几个按钮？」问决策者：「这个产品的目标成本是多少？」问专家：「这个协议在丢包率超过1%时，系统怎么处理？」
小技巧：访谈时多问「为什么」。用户说「我要一个报警灯」，你追问「为什么需要报警灯？是怕什么情况？」——结果发现他真正需要的是「当温度超过85度时，系统能自动降频」，而不是一个灯。
我曾经在一个工业控制项目里，访谈了三个不同工厂的操作工。第一个说「界面要简单」，第二个说「按钮要大」，第三个说「颜色要醒目」。你猜怎么着？他们都在同一个车间干活，但用的设备型号不同，屏幕尺寸和安装位置都不一样。所以访谈时，一定要问清楚使用环境。
3.2 问卷调查——量大，但深度有限
问卷调查适合收集量化数据。比如你想知道「用户对当前系统响应时间的满意度」，或者「用户最常用的三个功能是什么」。嵌入式场景下，问卷通常发给两类人：
- 客户方的产品团队——他们能代表市场声音
- 内部测试人员——他们用过原型，有直观感受
设计问卷时，有几个坑要避开：
- 问题别太技术——用户不懂「中断优先级」「DMA传输」，你要翻译成「设备会不会卡顿」「数据保存快不快」
- 选项要互斥——比如「您每天使用设备的时间：A. 1小时以下 B. 1-3小时 C. 3-5小时 D. 5小时以上」，别出现重叠
- 留一个开放题——「您还有什么想说的？」——往往能挖出意外信息
注意：问卷回收率通常不高。我见过一个项目，发了200份问卷，只收回37份。所以别把问卷当唯一手段，它只能辅助验证。
3.3 文档分析——最省成本，但容易过时
文档分析，就是翻看已有的资料。嵌入式项目里，常见的文档包括：
| 文档类型 | 能获取什么信息 | 常见问题 |
|---|---|---|
| 产品规格书 | 功能列表、性能指标、接口定义 | 写得太理想，实际做不到 |
| 竞品分析报告 | 市场定位、功能对比、价格区间 | 数据可能过时半年以上 |
| 历史项目文档 | 架构设计、问题记录、经验教训 | 没人更新，和代码对不上 |
| 行业标准/协议规范 | 通信协议、电气特性、安全要求 | 版本更新快，要核对 |
我个人习惯是，拿到文档先看版本号和修改日期。有一次我接手一个项目，文档上写着「支持Modbus RTU」，结果代码里用的是Modbus TCP。一问才知道，文档是两年前的，中间改过方案但没人更新文档。嗯，这坑我踩过。
3.4 原型法——让需求「看得见摸得着」
原型法在嵌入式里特别重要。因为很多用户说不清楚自己要什么，但你做个东西给他看，他马上就能说「不对，这里应该这样」。原型可以分两种：
- 低保真原型——纸面草图、Axure线框图、甚至PPT。适合早期确认交互逻辑
- 高保真原型——跑在开发板上的Demo，带真实硬件接口。适合验证关键技术点
我建议你在关键决策点做原型。比如：
- 触摸屏的菜单层级是否合理？——做个低保真原型，让用户点几下
- 电机响应速度能否满足要求？——搭个高保真原型，实测一下
- 通信协议在干扰环境下是否稳定？——用开发板跑个Demo，模拟现场
经验之谈：原型不是最终产品，别在上面花太多时间。我见过一个团队，花了两周做了一个精美的UI原型，结果用户说「我要的不是这个」。两周白干了。所以原型要「快」——快速搭建、快速验证、快速迭代。
3.5 观察法——看用户怎么「用错」
观察法，就是去现场看用户操作。你会发现很多用户自己都没意识到的需求。比如：
- 用户明明有「自动模式」，但他每次都手动切换——说明自动模式不好用
- 用户把设备放在角落里，屏幕反光看不清——说明亮度不够
- 用户用螺丝刀捅复位孔——说明复位按钮位置不合理
我曾经去一个工厂观察设备操作。操作工是个老师傅，他每次启动设备前，都要先按一个「测试按钮」，等三秒，再按「启动」。我问为什么，他说「不测试一下，万一设备坏了呢？」——你看，这是用户自己加的一个安全流程，但产品里根本没有这个功能。后来我们在新版本里加了一个「启动前自检」选项，老师傅特别满意。
观察法要点：别打扰用户。你站在旁边看就行，别指手画脚。等用户操作完了，再问「刚才那个步骤，为什么这么做？」
3.6 五种方法怎么选？一张图说清楚
下面这张SVG图，总结了五种方法在嵌入式场景下的适用阶段和产出物。你可以把它贴在项目白板上，随时提醒团队。
3.7 组合策略——别只用一招
实际项目中，我通常这样组合：
- 第一步：文档分析——先看已有的规格书、竞品资料，建立基本认知
- 第二步：用户访谈——找3-5个关键用户，深挖痛点
- 第三步：原型法——针对核心功能做快速原型，让用户「摸到」
- 第四步：观察法——去现场看用户怎么用原型，发现设计缺陷
- 第五步：问卷调查——把验证过的需求，发给更大范围的人确认优先级
避坑指南：我曾经在一个项目里，只做了访谈和问卷，没做原型。结果开发到一半，用户说「不对，我要的不是这个」。返工花了三周。从那以后，我坚持「关键功能必须做原型验证」。
好了，这五种方法就聊到这儿。记住一句话：需求获取不是一次性活动，而是贯穿项目始终的对话。你用得越多，越能理解用户真正想要什么。