📚 课程目录第2章嵌入式项目管理基础

2. 嵌入式项目管理基础

说实话，很多工程师一听到「项目管理」四个字就头疼。觉得那是项目经理的事，跟自己没关系。我以前也这么想。

直到有一次，我负责一个智能家居网关项目。硬件都调通了，固件也跑起来了，结果测试发现——需求文档里写的「低功耗待机电流小于 50μA」，开发团队压根没看到。为什么？因为需求文档躺在共享文件夹里，没人去翻。

那次之后我学乖了。项目管理不是管人的，是管事的。它帮你把「谁在什么时候该干什么」理清楚。今天我们就聊聊嵌入式项目管理的三个基本功：生命周期模型、关键角色、文档体系。

一、项目生命周期：V 模型 vs 敏捷模型

嵌入式项目选生命周期模型，说白了就是选「怎么干活」。我见过两种主流模型：V 模型和敏捷模型。它们各有各的脾气。

1. V 模型：硬件项目的「老黄牛」

V 模型的特点是「左写右验」。左边是需求、设计、编码，右边是单元测试、集成测试、系统测试。左右一一对应，像字母 V 的两条边。

我个人习惯在硬件主导的项目里用 V 模型。比如做一款工业控制器，硬件方案定了就不能改，软件必须跟着硬件走。V 模型的好处是阶段清晰，每个阶段都有明确的交付物和验收标准。

  V 模型核心阶段：
  需求分析 → 输出《需求规格说明书》
系统设计 → 输出《系统架构设计文档》
详细设计 → 输出《模块设计文档》
编码实现 → 输出代码 + 单元测试报告
单元测试 → 验证模块功能
集成测试 → 验证模块间接口
系统测试 → 验证是否满足需求

但 V 模型有个坑：它假设需求一开始就定死了。你想想看，嵌入式产品经常遇到「客户突然说要加个功能」的情况。这时候 V 模型就僵了，改需求等于改整个流程。

我曾经踩过的坑： 一个车载项目，客户在集成测试阶段要求修改通信协议。V 模型下我们不得不回退到设计阶段，重新评审、重新编码、重新测试。项目延期了两个月。后来我学乖了——需求变更频繁的项目，别死磕 V 模型。

2. 敏捷模型：软件迭代的「快枪手」

敏捷模型的核心是「小步快跑」。把项目拆成多个迭代（Sprint），每个迭代 2-4 周，交付一个可工作的增量版本。

我在做物联网网关项目时用过 Scrum。团队 6 个人，每两周一个 Sprint。每天早上站会 15 分钟，每人说三件事：昨天做了什么、今天打算做什么、有什么阻碍。

我的经验： 嵌入式项目用敏捷，关键是要把「硬件交付周期」考虑进去。硬件打样要 2 周，测试要 1 周，这些时间要算进 Sprint 计划里。别让硬件拖了软件的后腿。

敏捷模型的好处是灵活。需求变了？下个 Sprint 调整优先级就行。但敏捷也有短板——它不太适合安全关键系统（比如医疗设备、航空电子）。这类项目需要严格的文档和追溯性，敏捷的「轻文档」风格容易出问题。

3. 怎么选？一张表说清楚

对比维度	V 模型	敏捷模型
需求稳定性	需求固定，变更少	需求频繁变更
项目规模	中大型，团队 10 人以上	中小型，团队 3-9 人
安全要求	高（医疗、汽车、航空）	低（消费电子、IoT）
交付节奏	一次性交付	迭代交付
文档要求	严格，每个阶段有文档	轻文档，重沟通

我个人建议：硬件主导、安全要求高的项目用 V 模型；软件主导、需求变化快的项目用敏捷。如果拿不准，可以试试混合模型——硬件走 V 模型，软件走敏捷，中间用接口文档对齐。

二、关键角色：PM、SE、Dev、Test 各司其职

项目能不能跑起来，关键看人。嵌入式项目里，四个角色缺一不可：PM（项目经理）、SE（系统工程师）、Dev（开发工程师）、Test（测试工程师）。

我见过最乱的项目是什么样？PM 不懂技术，SE 只管写文档，Dev 自己测自己，Test 最后才发现 bug 一堆。嗯，那项目最后延期了 3 个月。

1. PM（项目经理）

PM 是项目的「大管家」。管进度、管资源、管风险、管沟通。PM 不需要写代码，但必须懂技术，否则会被 Dev 忽悠。

我个人习惯，PM 每周要开一次项目例会，检查进度偏差。偏差超过 10% 就要启动风险应对措施。

2. SE（系统工程师）

SE 是项目的「技术总工」。负责需求分析、系统架构设计、技术方案评审。SE 要能回答「这个功能到底能不能实现」。

我在一个智能穿戴项目里，SE 在评审时发现蓝牙芯片的功耗指标达不到需求。及时换了方案，避免了后期返工。这就是 SE 的价值。

3. Dev（开发工程师）

Dev 是项目的「搬砖人」。写代码、调驱动、做单元测试。Dev 要对自己的代码负责，不能指望 Test 帮你找 bug。

给 Dev 的建议： 写代码前先看设计文档。我见过太多 Dev 不看设计直接写代码，结果模块接口对不上，集成测试时哭都来不及。

4. Test（测试工程师）

Test 是项目的「守门员」。写测试用例、执行测试、报 bug、回归验证。Test 要站在用户角度思考，不能只测「正常流程」。

我曾经带过一个测试团队，要求他们每个功能至少写 5 个异常测试用例。结果发现了一个「内存泄漏」的 bug，开发查了 3 天才定位到。如果没有测试，这个 bug 就带到生产环境了。

三、文档体系：需求、设计、测试报告

说到文档，很多工程师觉得「写文档浪费时间」。但我想说——文档不是写给领导看的，是写给未来的自己看的。

你想想看，半年后你接手一个旧项目，没有文档，你怎么办？从头读代码？那叫考古。

1. 需求文档

需求文档是项目的「宪法」。所有开发、测试、验收都以它为准。需求文档要写清楚：功能需求、性能指标、接口定义、约束条件。

  需求文档模板（精简版）：
项目背景：为什么要做这个产品？
功能需求：产品能做什么？（列表 + 优先级）
性能指标：响应时间、功耗、精度等量化指标
接口定义：硬件接口（GPIO、I2C、SPI）、软件接口（API、协议）
约束条件：成本、尺寸、认证要求等

2. 设计文档

设计文档是项目的「施工图」。包括系统架构设计、模块设计、接口设计、时序设计。设计文档要详细到「别人看了能直接写代码」的程度。

我习惯用「架构图 + 接口表 + 状态机」的方式来写设计文档。架构图画清楚模块关系，接口表定义清楚每个函数的入参和返回值，状态机描述清楚系统行为。

3. 测试报告

测试报告是项目的「体检单」。包括测试用例、测试结果、bug 列表、回归验证记录。测试报告要能回答「这个版本能不能发布」。

我曾经踩过的坑： 一个项目测试报告只写了「测试通过」四个字。结果上线后客户发现一个严重 bug——设备在高温下会死机。后来查原因，测试环境温度只有 25°C，根本没做高温测试。从那以后，我要求测试报告必须写明测试环境、测试覆盖率和遗留问题。

4. 文档管理建议

文档类型	责任人	交付时间	评审要求
需求规格说明书	SE	项目启动后 2 周	PM + 客户评审
系统架构设计文档	SE	需求确认后 1 周	Dev + Test 评审
模块设计文档	Dev	编码开始前	SE 评审
测试用例	Test	编码完成前	SE + Dev 评审
测试报告	Test	测试完成后	PM 确认

文档不用写得太花哨。关键是「该有的都有，该对的都对」。我见过有人把需求文档写成小说，洋洋洒洒 100 页，结果核心功能只写了 2 页。嗯，那叫凑字数。

好了，这一章的内容就到这里。项目管理不是束缚你的枷锁，而是帮你少走弯路的工具。选对生命周期、用对角色、写好文档，你的项目就成功了一半。