第一章：需求分析——如何从市场噪音中提取真实需求，避免伪需求陷阱

做嵌入式产品这么多年，我见过太多项目死在需求阶段。说实话，需求分析这个环节，看着简单，实际上坑最多。你想想看，市场上一堆声音，客户说想要这个，老板说要做那个，销售又带回来一堆“用户反馈”——这里面到底哪些是真需求，哪些是伪需求？

我个人习惯，拿到一个需求清单后，先不急着动手。先问自己三个问题：这个需求解决了谁的什么问题？用户愿意为它买单吗？我们现有的技术方案能不能做？这三个问题过一遍，至少能筛掉一半的伪需求。

1.1 伪需求的三大典型特征

我在项目中遇到过不少伪需求，总结下来，它们通常有这三个特征：

• 模糊不清：比如“让设备更智能”——什么叫更智能？具体指标是什么？说不清楚的需求，大概率是伪需求。
• 技术驱动而非用户驱动：团队里有人觉得“这个芯片性能强，我们加上去”——但用户真的需要吗？
• 无法量化：没有具体的性能指标、功耗要求、成本约束。说白了，就是拍脑袋想出来的。

1.2 从市场噪音中提取真实需求的方法

怎么从一堆噪音里找到真实需求？我分享几个自己常用的方法：

方法一：5W1H 追问法

拿到一个需求，用五个问题追问到底：

问题	示例
Who（谁在用？）	是终端用户还是运维人员？
What（做什么？）	具体要完成什么任务？
Where（在哪用？）	室内还是室外？工业环境还是消费场景？
When（什么时候用？）	持续运行还是间歇使用？
Why（为什么需要？）	解决了什么痛点？有没有替代方案？
How（怎么实现？）	技术可行性如何？成本能接受吗？

举个例子，有人提需求说“设备要支持远程升级”。你追问一下：谁需要远程升级？是用户自己升级，还是售后人员操作？升级频率多高？升级失败怎么办？这么一问，真实需求就出来了——可能不是远程升级本身，而是“减少现场维护成本”。

方法二：用户场景还原

我建议团队做需求分析时，一定要做场景还原。别坐在办公室里想，去现场看看用户怎么用你的产品。

记得有一次，客户说“我们的工业网关需要支持4G全网通”。听起来很合理对吧？结果我们去现场一看，那个工厂在地下二层，4G信号根本覆盖不到。真实需求其实是“支持有线网络+本地存储，断网时能缓存数据”。

方法三：需求优先级矩阵

把所有需求列出来，用两个维度打分：用户价值和技术实现难度。我习惯用这个矩阵：

用户价值 \ 实现难度	低难度	高难度
高价值	立即做（核心功能）	规划做（战略功能）
低价值	可做可不做（锦上添花）	不做（伪需求）

你看，落在“低价值+高难度”这个象限的，基本就是伪需求。直接砍掉，别犹豫。

1.3 需求文档怎么写才不踩坑

需求分析完了，得落到文档里。我见过太多需求文档写得像散文，读完了也不知道到底要做什么。这里说几个关键点：

• 每个需求必须有验收标准：比如“响应时间小于100ms”，而不是“响应要快”。
• 区分“必须做”和“最好做”：用MoSCoW方法（Must have, Should have, Could have, Won't have）分类。
• 注明来源和背景：这个需求是谁提的？基于什么场景？方便后续追溯。

1.4 需求变更管理——别让需求“长胖”

需求分析不是一锤子买卖。产品开发过程中，需求肯定会变。但怎么管理变更，是个大学问。

我个人的做法是：

1. 设立需求冻结节点：比如硬件设计冻结后，原则上不再接受影响硬件方案的需求变更。
2. 变更必须走流程：提交变更申请，评估影响范围（时间、成本、质量），签字确认。
3. 区分“变更”和“新增”：有些需求其实是新功能，不是原需求的变更。别混在一起，否则项目范围会无限膨胀。

嗯，这里要注意一点：需求变更不可怕，可怕的是没有流程的随意变更。你想想看，今天加个功能，明天改个参数，开发团队疲于奔命，最后产品做出来四不像。

1.5 实战案例：一个智能门锁的需求分析

最后分享一个实际案例。我们做过一款智能门锁，初期需求清单有30多项，包括人脸识别、指纹解锁、密码开锁、远程授权、门铃联动、电量检测、防撬报警……看着很全对吧？

但我们用5W1H一分析，发现很多需求有问题：

• 人脸识别：用户场景是晚上回家，楼道光线暗，识别率低。而且成本增加50元，用户愿意买单吗？——砍掉。
• 远程授权：谁会用？租客还是房东？实际调研发现，90%的用户只需要临时密码功能。——简化。
• 门铃联动：需要和第三方门铃对接，开发周期长，而且用户已经有门铃了。——砍掉。

最后我们只保留了6个核心功能：指纹解锁、密码解锁、临时密码、电量检测、防撬报警、低功耗待机。产品上市后，销量远超预期。你看，少即是多。