3、目标回顾：如何定义清晰的项目目标

做嵌入式项目这么多年，我踩过最大的坑，就是项目刚开始时目标没定清楚。

你想想看，一个项目做了三个月，最后发现跟客户要的根本不是一回事。硬件改版、软件重写、测试推倒重来……这种痛苦，经历过一次就够够的了。

所以今天咱们聊聊目标定义这件事。说白了，就是怎么在项目一开始，就把「我们要做成什么样」这件事钉死。

3.1 为什么嵌入式项目特别需要清晰目标

嵌入式项目有个特点：软硬件耦合深，改动成本高。

我做过一个智能家居网关的项目。一开始只说要「支持远程控制」，结果做到一半，客户说还要支持本地语音。好嘛，硬件上没预留麦克风接口，主控芯片算力也不够。最后只能重新画板子，项目延期两个月。

为什么会这样？因为目标定义得太模糊了。「远程控制」这四个字，不同的人理解完全不一样：

• 产品经理理解：手机App能开关灯
• 硬件工程师理解：需要Wi-Fi模块+继电器
• 软件工程师理解：MQTT协议+云端服务器
• 测试工程师理解：响应时间<2秒，成功率>99%

你看，同一个目标，每个人脑子里想的都不一样。所以目标必须量化、必须具体。

3.2 SMART原则在嵌入式项目中的应用

SMART原则大家可能都听过。但怎么用在嵌入式项目里？我结合自己的经验说说。

SMART要素	嵌入式项目中的含义	反面案例	正面案例
Specific（具体）	功能、接口、性能指标明确	「提高系统响应速度」	「按键按下到LED点亮，延迟<50ms」
Measurable（可衡量）	有明确的测试方法和验收标准	「系统要稳定」	「连续运行72小时，无死机、无数据丢失」
Achievable（可实现）	在当前硬件、时间、预算下可行	「用STM32F103做4K视频解码」	「用STM32F103做H.264基线解码，分辨率720p」
Relevant（相关）	目标与项目整体方向一致	「增加蓝牙功能」（但客户只需要Wi-Fi）	「增加OTA升级功能」（客户有远程维护需求）
Time-bound（有时限）	有明确的里程碑和截止日期	「尽快完成」	「8月30日前完成硬件定型，9月15日前完成驱动开发」

我个人习惯，在项目启动会上，拉着硬件、软件、测试、产品一起，把每个目标都过一遍SMART。尤其是「可实现」这条，经常出问题。

3.3 目标分解与对齐

大目标定好了，接下来就是分解。嵌入式项目通常涉及多个子系统：电源、主控、通信、传感器、执行器……每个子系统都要有自己的子目标。

我常用的方法是「目标树」：

项目总目标：开发一款低功耗温湿度采集终端
├── 硬件目标
│   ├── 功耗：休眠电流<5μA，工作电流<50mA
│   ├── 尺寸：60mm×40mm×20mm
│   └── 成本：BOM成本<30元
├── 软件目标
│   ├── 采集周期：1次/分钟
│   ├── 数据上报：每10分钟上报一次
│   ├── 通信成功率：>99%
│   └── 固件升级：支持OTA，升级成功率>95%
└── 测试目标
    ├── 功能测试：覆盖所有功能点
    ├── 可靠性测试：-20℃~60℃环境测试
    └── 寿命测试：电池续航>1年

分解完之后，还要做一件事：对齐。说白了，就是确保子目标之间不打架。

我曾经遇到过一个案例：硬件团队为了降低功耗，选了低主频的MCU。但软件团队需要做实时音频处理，算力不够。这就是目标没对齐。

3.4 避坑指南：我踩过的三个坑

嗯，说到这，分享几个我亲身经历的教训。

坑一：目标定得太「理想」

我曾经在一个项目里，定了「系统响应时间<10ms」的目标。结果硬件选型时发现，传感器本身的采样周期就要20ms。这个目标根本不可能实现。后来我们改成了「从传感器数据就绪到输出，延迟<10ms」，这才合理。

坑二：忽略了「隐性目标」

有一次做工业控制项目，所有显性目标都达成了：功能正常、性能达标、成本可控。但客户验收时提出：你们这个设备，在强电磁干扰环境下会重启。原来我们没把「电磁兼容性」写进目标里。从那以后，我每个项目都会列一个「非功能性需求清单」：EMC、温湿度范围、振动、寿命……

坑三：目标分解后没人认领

大目标分解成子目标，但每个子目标必须有人负责。我见过一个项目，功耗目标没人认领，结果硬件说「我管不了功耗，那是软件的事」，软件说「功耗是硬件决定的」。最后项目延期，就是因为这个没人管的子目标。

3.5 总结一下

目标定义这件事，看起来简单，做起来全是细节。我个人的经验是：

• 用SMART原则把每个目标钉死
• 用目标树把大目标分解到子系统
• 定期做目标对齐检查
• 每个子目标都要有人认领

你想想看，如果项目一开始就把这些做扎实了，后面能少走多少弯路？

下一章咱们聊聊「过程跟踪」——目标定好了，怎么确保它不跑偏。