2. 嵌入式系统基础

各位同学，咱们今天聊聊项目管理的基础。说实话，很多工程师一听到「项目管理」四个字就觉得是行政活、是PM的事。其实不然。你写代码、调板子、改需求，这些动作本身就在做项目管理，只是你可能没意识到。

我刚开始带项目那会儿，也踩过不少坑。有一次一个固件项目，开发了三个月，最后发现客户要的是V模型交付，我们却按敏捷迭代在跑，验收时一堆文档补不上。嗯，从那以后我养成了一个习惯——先搞清楚项目本质，再选生命周期模型。

项目 vs 运营：到底差在哪？

先问个问题：你每天修Bug、改驱动、维护老产品，这是项目还是运营？

很多人会答错。我直接给结论：修Bug本身是运营，但「修复某个特定版本的安全漏洞并发布补丁」就是一个项目。

区别其实就三点：

维度	项目	运营
目标	创造独特的产品/服务	维持业务持续运转
时限	有明确的开始和结束	持续进行，无终止日期
产出	一次性交付物	重复性结果
团队	临时组建，项目结束解散	固定编制，长期存在
风险	高不确定性	相对稳定

举个例子。你给一款智能手表开发新的心率算法，这就是项目——有需求、有截止日期、交付后团队就散了。但算法上线后，每天处理用户心率数据、维护服务器稳定，这就是运营。

项目管理五大过程组：不是流程，是思维框架

PMBOK把项目管理分成五大过程组。别被名字吓到，说白了就是五步：

1. 启动——搞清楚「为什么要做」
2. 规划——想清楚「怎么做、谁来做、花多少钱」
3. 执行——动手干
4. 监控——边干边看，有没有跑偏
5. 收尾——干完了，复盘、归档、解散

你想想看，这五步是不是跟你写一个嵌入式模块的流程一模一样？拿到需求（启动），画时序图、分配资源（规划），写代码（执行），单元测试+Code Review（监控），合入主干、写Release Note（收尾）。

我见过最典型的错误是什么？很多团队跳过了「监控」这一步。代码写完了直接扔给测试，结果Bug堆积如山。其实监控不光是测试，还包括每日站会、燃尽图、风险登记册。我曾经在一个RTOS项目中，因为没做风险监控，结果芯片选型变更导致整个调度器重写，延期两个月。

嵌入式项目的生命周期模型：选对模型，少走弯路

嵌入式项目跟纯软件项目不一样。硬件成本高、烧录次数有限、OTA升级困难。所以生命周期模型的选择，直接决定了项目成败。

我整理了三类主流模型，咱们一个一个说。

瀑布模型：老派但可靠

适合需求明确、硬件固定的项目。比如车规级MCU固件、医疗设备嵌入式软件。

• 优点：阶段清晰，文档完整，便于审计
• 缺点：变更成本高，客户看到成品时往往已经晚了
• 我的经验：做BMS（电池管理系统）时用的就是瀑布。因为安全认证要求每个阶段都有签字，改需求？对不起，走变更控制流程，至少两周。

敏捷模型：灵活但需要纪律

适合需求变化快、硬件平台成熟的消费类产品。比如智能家居、可穿戴设备。

• 优点：快速响应变化，客户早期就能看到原型
• 缺点：文档容易缺失，硬件迭代跟不上软件节奏
• 避坑指南：我曾经在一个IoT项目中用Scrum，结果硬件打样周期是两周，Sprint也是一周，硬件永远跟不上软件。后来改成「硬件瀑布+软件敏捷」的混合模式，才跑通。

V模型：嵌入式专属武器

这是嵌入式领域的「亲儿子」。强调验证与验证的对应关系。

V模型的核心逻辑：左侧是设计阶段（需求分析→概要设计→详细设计），右侧是测试阶段（单元测试→集成测试→系统测试），中间用验证线一一对应。

说白了，你写每一行代码的时候，就要想好怎么测它。

下面这张图展示了三种模型的核心差异：

怎么选？我给你一个决策框架

很多新手会问：「到底哪个模型最好？」我的回答是：没有最好的模型，只有最合适的模型。

我一般用三个维度来判断：

• 需求稳定性：需求变不变？变的话频率多高？
• 硬件成熟度：硬件是全新设计还是复用已有平台？
• 安全认证要求：是否需要IEC 61508、ISO 26262等认证？

举个例子。如果你做的是智能门锁固件，硬件平台是现成的，需求每周都在变，那就用敏捷。但如果你做的是汽车ESP控制器，需求冻结、硬件定制、需要ASIL-D认证，那就老老实实走V模型，甚至瀑布。