一、需求分析与立项：从市场调研到PRD撰写，以及项目立项评审流程
说实话，很多嵌入式团队翻车，不是死在技术难点上，而是死在需求没搞清楚就开干。
我见过太多项目，硬件画了三个月板子，结果发现市场需求早就变了。或者软件写了大半年，才发现客户要的根本不是这个功能。嗯，这些坑我都踩过。
所以今天咱们聊聊，需求分析与立项到底该怎么搞。
1.1 市场调研：别拍脑袋，要拍数据
很多人觉得市场调研是销售的事，跟研发没关系。大错特错。
你想想看，如果你连产品卖给谁、解决什么问题、竞争对手做到什么程度都不清楚，你怎么定技术方案？怎么选芯片？怎么定成本目标？
我个人习惯，市场调研至少要做这三件事：
- 目标用户画像——谁在用？用在什么场景？痛点是什么？
- 竞品分析——市面上已有的方案，优缺点是什么？价格区间？
- 技术可行性预研——现有团队能力能不能做？关键器件好不好买？
1.2 需求收集：别等客户说，要替客户想
客户往往说不清楚自己要什么。你问他「需要什么功能」，他可能会说「越快越好」「越便宜越好」。这等于没说。
我做过一个工业控制项目，客户说「要稳定」。结果我们按军工级标准设计，成本翻了三倍。客户一看报价，直接跑了。
后来我才明白，他说的「稳定」其实是「别老坏，修得起」。而不是「永远不坏」。
需求收集的常用方法：
- 访谈法——直接跟客户聊，记录原始需求
- 观察法——看客户怎么用现有设备，发现隐性需求
- 问卷法——批量收集，适合标准化产品
- 原型法——做个简易Demo，让客户试用反馈
核心原则： 需求要分层次。
必须做的（Must-have）→ 应该做的（Should-have）→ 可以做的（Could-have）→ 这次不做的（Won't-have）
这就是经典的MoSCoW法则。我每次立项前都会拉一张这样的表，贴在白板上。
1.3 产品需求文档（PRD）怎么写
PRD不是写小说，别搞一堆形容词。什么「用户体验流畅」「界面美观大方」——这些在评审会上会被喷死。
PRD要的是：可量化、可验证、可测试。
我常用的PRD模板结构：
| 章节 | 内容 | 示例 |
|---|---|---|
| 1. 项目背景 | 为什么要做这个产品？市场机会在哪？ | 「目前市面缺少低成本、低功耗的温湿度采集终端」 |
| 2. 功能列表 | 所有功能点，按优先级排列 | 「P0: 数据采集；P1: 远程报警；P2: 历史曲线」 |
| 3. 性能指标 | 具体数字，不能模糊 | 「采样周期 ≤ 1s；待机功耗 ≤ 10μA」 |
| 4. 接口定义 | 硬件接口、通信协议、数据格式 | 「UART 115200bps，Modbus RTU」 |
| 5. 约束条件 | 成本、尺寸、认证、环境要求 | 「BOM成本 ≤ 35元；工作温度 -20~70℃」 |
| 6. 验收标准 | 怎么才算做完？怎么才算通过？ | 「连续运行72小时无死机；精度 ±0.5℃」 |
1.4 项目立项评审：别走过场，要真刀真枪
很多公司的立项评审就是走个形式。PPT一放，领导点点头，就过了。然后项目做到一半发现做不下去，又得重新立项。
我建议立项评审至少要有这三关：
第一关：技术可行性评审
硬件方案能不能实现？关键芯片供货周期多久？软件框架有没有风险？
说白了，就是问一句：这东西到底能不能做出来？
第二关：商业可行性评审
成本能不能控制住？定价有没有竞争力？销量预估靠不靠谱？
说白了，就是问一句：这东西能不能赚钱？
第三关：资源与计划评审
团队人手够不够？时间节点合不合理？有没有并行项目冲突？
说白了，就是问一句：我们有没有能力按时交付？
评审会上的「一票否决」项：
- 关键器件处于「停产」或「严重缺货」状态
- 核心技术团队不具备相关经验，且无法外聘
- 成本目标与市场售价之间没有利润空间
- 时间节点明显不合理（比如3个月要做完别人1年的活）
这三条只要中一条，我建议你直接打回去重新调研。
1.5 立项后的第一件事：输出《项目章程》
评审通过后，别急着开工。先写一份《项目章程》。
这东西就像项目的「宪法」。以后所有争议，都拿它来裁决。
项目章程至少包含：
- 项目名称与编号
- 项目目标（一句话说清楚）
- 项目范围（做什么 & 不做什么）
- 关键里程碑与交付物
- 项目预算与资源
- 项目经理与核心成员
- 风险登记册（初步识别）
小结
需求分析与立项，是整个嵌入式研发流程的「地基」。地基没打好，后面盖多高的楼都得塌。
我见过太多团队，急着写代码、画板子，结果做到一半发现需求是错的，又推倒重来。浪费的时间、金钱、士气，远远超过前期多花两周做调研。
所以，别急。先把需求搞清楚，把立项评审做扎实。后面的事，反而会顺很多。
下一章，咱们聊聊系统架构设计。说白了，就是怎么把需求变成一张能落地的技术蓝图。