3. 项目管理基础
做嵌入式项目这么多年，我见过太多“做出来没人用”的产品。原因往往不是技术不行，而是需求没搞清楚。说白了，需求分析就是回答三个问题：为什么要做？用户想要什么？系统该干什么？
这一章，我们聊聊需求分析的三个层次和三种获取方法。这些都是我踩过坑之后总结出来的经验。
需求的三层结构
刚入行时，我总觉得需求就是“客户说啥我做啥”。后来发现，客户说的往往是表象。需求其实分三层：
| 层次 | 定义 | 典型表述 | 产出物 |
|---|---|---|---|
| 业务需求 | 组织或客户的高层目标 | “我们要降低30%的能耗” | 项目愿景、商业论证 |
| 用户需求 | 用户使用系统要完成的任务 | “运维人员能远程查看设备状态” | 用户故事、用例图 |
| 功能需求 | 系统具体实现的行为 | “每5秒采集一次温度，超过阈值报警” | 需求规格说明书 |
关键认知：业务需求是“为什么”，用户需求是“做什么”，功能需求是“怎么做”。三层必须对齐，否则项目必出问题。
业务需求：项目的原点
业务需求来自客户的高层管理者或出资方。它回答的是：投入资源做这个项目，到底图什么？
我记得有个智能家居项目，客户一开始说“要做个智能窗帘”。聊了半小时才发现，他们的真实业务需求是“降低写字楼空调能耗”。智能窗帘只是手段之一。如果只盯着功能做，最后可能方向都偏了。
业务需求通常很抽象，但它是所有决策的判据。功能做不做、优先级怎么排，都要回到业务需求来判断。
用户需求：从用户视角看问题
用户需求描述的是用户与系统的交互。它不关心内部实现，只关心用户能不能完成任务。
举个例子：
- 业务需求：提升生产线质检效率20%
- 用户需求：质检员能用扫码枪快速录入缺陷信息
- 功能需求：扫码枪触发中断，系统在200ms内显示对应工单
写用户需求时，我习惯用“用户故事”格式：作为[角色]，我想要[功能]，以便[价值]。比如：“作为产线组长，我想要实时看到每台设备的运行状态，以便及时安排维修。”
我的经验：用户需求一定要让真实用户参与确认。别只跟项目经理聊，他们往往替用户做决定，但替不了用户干活。
功能需求：落到代码层面的契约
功能需求是开发团队真正要实现的。它必须可量化、可测试、无歧义。
我曾经接手过一个项目，需求里写着“系统响应要快”。结果测试时，我认为500ms算快，客户认为100ms才算。这就是功能需求没写清楚。
好的功能需求长这样：
功能：温湿度数据采集
触发条件：系统上电后自动启动
采集周期：每10秒采集一次
精度要求：温度 ±0.5°C，湿度 ±3%RH
异常处理：连续3次采集失败，触发硬件看门狗复位
输出格式：JSON，包含设备ID、时间戳、温湿度值需求获取方法：三种武器
需求不会自己从天上掉下来。你得主动去挖。我常用的方法有三种，各有各的适用场景。
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 访谈 | 探索性需求、高层目标 | 深度高、能挖掘隐性需求 | 耗时、样本少 |
| 问卷 | 大范围收集、量化统计 | 覆盖面广、效率高 | 无法追问、深度有限 |
| 原型法 | 需求不明确、交互复杂 | 直观、能快速验证 | 迭代成本高、可能误导 |
访谈：面对面挖需求
访谈是我最常用的方法。尤其是项目启动阶段，我会约客户的关键干系人聊1-2小时。
访谈的技巧：
- 先列提纲：准备10-15个开放式问题，别上来就问“你要什么功能”
- 多问“为什么”：客户说“我要一个报警功能”，追问“报警给谁看？什么情况报警？报警后做什么？”
- 记录+录音：我习惯带个录音笔，回头整理时能捕捉到细节
- 区分“想要”和“需要”：客户可能想要镀金功能，但真正需要的是核心价值
避坑指南：我曾经访谈时只顾着记笔记，没注意客户的表情和语气。后来发现客户说“这个功能最好有”时，其实是在犹豫。真正的需求往往藏在那些“嗯…可能吧”的含糊回答里。
问卷：规模化收集
当用户群体很大（比如上百个设备操作员），访谈就不现实了。这时候问卷是高效的选择。
设计问卷要注意：
- 问题要具体：别问“你对系统满意吗”，问“你希望系统在几秒内完成数据导出”
- 选项要互斥：每个选项之间不能有重叠
- 留一个开放题：让用户写点自由意见，往往有惊喜
- 先小范围试填：找3-5个人试填，看看有没有歧义
问卷的缺点是深度不够。所以我通常用它做前期摸底，然后针对关键发现再安排访谈。
原型法：让需求“看得见”
嵌入式系统做原型，不一定非得是硬件。我常用的是：
- 低保真原型：纸面草图或PPT，快速验证交互逻辑
- 高保真原型：用Qt或HTML做界面模拟，甚至用开发板跑个最小系统
原型法的核心价值是降低认知偏差。你说“系统会显示报警”，客户点头说懂。但你把原型摆在他面前，他可能说“不对，我要的是弹窗，不是状态栏闪烁”。
我记得一个医疗设备项目，需求文档写了30页，客户都签了。结果原型一出来，客户说“这个操作流程不对，护士没时间点三级菜单”。最后改了四版原型才定下来。如果直接开发，那30页需求就是废纸。
我的建议：原型法不要追求完美。用最快的方式让用户“摸到”系统，然后观察他们的操作。用户做出来的动作，比他们说出来的话更真实。
需求层次与获取方法的对应关系
这三种方法不是孤立的。我一般这样组合使用：
你看这个图就清楚了：业务需求靠访谈深挖，用户需求用问卷广撒网，功能需求拿原型来验证。三层之间是逐层细化的关系，每一层都要有对应的干系人确认。
需求分析的常见陷阱
最后，分享几个我踩过的坑：
陷阱一：混淆用户需求和功能需求
用户说“我要一个报表”，你直接开始设计数据库表结构。错了。用户需求是“我要能看到每周的故障统计”，功能需求才是“系统按周聚合故障数据，生成PDF报表”。先搞清楚用户要什么，再想怎么实现。
陷阱二：只收集不验证
我曾经花了两周做问卷，回收了200份。结果一分析，发现题目有歧义，一半数据不能用。现在我的习惯是：收集完立刻找3-5个人做回访，确认我理解的对不对。
陷阱三：忽略非功能需求
嵌入式系统尤其要注意：功耗、实时性、可靠性、安全性。这些往往不会写在用户故事里，但漏掉一个就可能导致项目重做。我一般会在需求文档里单独列一节“质量属性”，跟功能需求同等对待。
需求分析没有捷径。但把三层结构理清楚，三种方法用到位，至少能保证你做正确的事。至于怎么把事做正确，那是后面架构设计的事。