2、需求分析与规格定义：用户需求调研方法、产品需求文档（PRD）撰写、功能规格列表、技术选型原则（成本、功耗、性能的权衡）
大家好，我是你们的讲师。今天咱们聊聊物联网项目里最容易被忽视、但也是最关键的一步——需求分析与规格定义。
说实话，我见过太多团队，一上来就急着画板子、写代码。结果呢？做到一半发现需求变了，或者做出来的东西客户根本不买账。嗯，这其实是个大坑。我个人习惯，在动任何一个元器件之前，先把需求这块硬骨头啃下来。
2.1 用户需求调研方法
需求调研，说白了就是搞清楚“谁在用”、“怎么用”、“痛点在哪”。别坐在办公室里拍脑袋，你得走出去。
我常用的几种方法：
- 现场观察法： 直接去用户的使用场景里蹲点。比如做智能农业，我就去大棚里待过两天。看他们怎么浇水、怎么记录数据。你会发现，很多他们嘴上说的需求，和实际行为完全不一样。
- 深度访谈： 找3-5个典型用户，一对一聊。别问“你想要什么功能”，这种问题太虚。要问“你目前最头疼的是什么”、“如果有个东西能帮你解决这个问题，你愿意花多少钱”。
- 问卷调查： 适合收集大样本数据。但注意，问卷设计要短、问题要具体。我曾经犯过错误，问卷搞了30道题，回收率不到10%。后来改成10道选择题，回收率直接翻倍。
- 竞品分析： 把市面上同类产品买回来，拆！看他们的硬件选型、看他们的APP交互。不是为了抄袭，而是为了找到差异化机会。
我的小技巧： 调研时带个录音笔，或者直接录像。回头整理资料时，你会发现很多当时没注意到的细节。比如用户操作时的犹豫、皱眉，这些非语言信息往往比他说的话更真实。
2.2 产品需求文档（PRD）撰写
调研完了，得把结果变成文档。PRD就是整个项目的“宪法”。
怎么写？我一般分三块：
- 背景与目标： 一句话说清楚为什么要做这个产品。比如“解决工厂设备巡检效率低、漏检率高的问题”。
- 用户故事： 用“作为XX角色，我希望XX，以便XX”的格式。举个例子：“作为仓库管理员，我希望手机能实时看到温湿度数据，以便在异常时及时处理”。
- 验收标准： 每条需求都要有明确的、可测试的指标。比如“设备在-20℃到60℃环境下正常工作”、“电池续航不低于6个月”。
避坑指南： 我曾经见过一份PRD，里面写“系统要稳定”。什么叫稳定？每个人理解都不一样。后来我们改成“系统连续运行30天，不出现非预期重启”，这才算把需求说清楚了。
2.3 功能规格列表
PRD是给产品经理和客户看的。功能规格列表，才是给工程师看的“施工图”。
这里我习惯用表格来列，清晰明了：
| 功能模块 | 功能描述 | 优先级 | 备注 |
|---|---|---|---|
| 数据采集 | 每10秒采集一次温湿度，精度±0.3℃ | P0 | 必须实现 |
| 无线通信 | 支持Wi-Fi/BLE双模，数据上报间隔可配置 | P0 | 考虑功耗 |
| 本地存储 | 断网时本地缓存1000条数据 | P1 | 可选，但建议做 |
| OTA升级 | 支持远程固件升级，升级失败自动回滚 | P2 | 量产后再加 |
优先级我分三级：P0（不做产品没法用）、P1（做了更好）、P2（锦上添花）。这样排下来，团队就知道先干什么了。
2.4 技术选型原则：成本、功耗、性能的权衡
这是我最想聊的部分。很多新手工程师选型时，总想用最好的芯片、最大的内存。但做产品不是搞科研，你得算账。
三个核心维度：
- 成本： 不光是BOM成本，还有开发成本、测试成本、认证成本。比如用一颗国产MCU可能只要5块钱，但开发工具链不成熟，工程师多花两周调试，算下来反而更贵。
- 功耗： 电池供电的产品，功耗是命门。我做过一个项目，选了个性能很强的Wi-Fi模块，结果待机电流3mA，电池撑不过一个月。后来换成低功耗蓝牙，待机电流降到5μA，电池用了两年。
- 性能： 够用就行，别追求极致。比如一个温度传感器，精度±0.5℃就够用了，你非要选±0.1℃的，成本翻三倍，客户感知不到。
我的决策框架： 先列出所有候选方案，然后画一个三维坐标图。每个方案在成本、功耗、性能上打分。最后选那个“综合得分最高”的，而不是“单项最强”的。你想想看，一个产品如果成本太高卖不出去，性能再好有什么用？
举个例子，我之前做智能门锁：
- 方案A：用ESP32（成本15元，功耗高，性能强）
- 方案B：用STM32L0（成本8元，功耗低，性能一般）
- 方案C：用国产ASR6501（成本5元，功耗极低，性能够用）
最后选了方案C。为什么？因为门锁不需要高速运算，只需要响应快、待机长。方案C虽然性能一般，但成本低、功耗低，完全满足需求。这就是权衡。
好了，这一章的内容就到这里。记住，需求分析做得好，后面开发少烦恼。下一章我们聊聊硬件设计，到时候见。