第二章：角色定位与职责
做嵌入式外包项目，最怕什么？
我个人的经验是——最怕角色不清。甲方觉得乙方该干这个，乙方觉得甲方该干那个。最后项目烂尾，双方都觉得自己委屈。
说白了，嵌入式项目是个系统工程。硬件、软件、测试、管理，每个角色都得有清晰的边界。今天我就把这几类角色的核心职责掰开揉碎了讲清楚。
2.1 甲方（需求方）的核心职责
甲方是谁？是出钱的人，也是最终用产品的人。但很多甲方有个误区——觉得出钱了就万事大吉。
我遇到过最典型的案例：甲方丢过来一份三页纸的需求文档，说「照着做就行」。结果做到一半，甲方说「这里我要改」「那里我没想到」。项目延期三个月，预算超了40%。
所以，甲方真正的职责是什么？
- 需求明确化：把「我想要个智能家居网关」变成「支持Zigbee 3.0协议，至少连接50个节点，响应时间小于200ms」。
- 提供测试环境：真实的使用场景、配套设备、网络条件。别等交付了才说「我们工厂的电磁环境不一样」。
- 及时决策：技术选型、方案变更、预算调整，甲方得有人拍板。我见过甲方内部踢皮球，一个接口定义拖了两周。
- 验收标准前置：什么算「做完」？什么算「合格」？这些在合同里就得写清楚。
核心原则：甲方不是甩手掌柜，而是项目的「导航员」。方向错了，乙方跑得再快也没用。
2.2 乙方（承接方）的核心职责
乙方是干活的人。但「干活」两个字，包含的东西可不少。
我刚开始带项目时，总觉得乙方就是「按需求实现」。后来吃了亏才明白——乙方要对整个交付负责，包括那些甲方没写出来的东西。
- 技术可行性评估：甲方说「我要用蓝牙传4K视频」，你得告诉他这不现实。别硬接，最后交不了货。
- 方案设计：芯片选型、架构设计、接口定义。这些是乙方的专业领域，甲方通常不懂。
- 进度管理：什么时候出原理图？什么时候打板？什么时候联调？乙方得自己心里有数。
- 风险预警：发现某个芯片交期要12周，得提前告诉甲方。别等到项目deadline了才说「芯片买不到」。
- 文档交付：原理图、BOM表、固件源码、测试报告。这些是乙方的「毕业证」。
避坑指南：我曾经接过一个项目，甲方说「文档后面补就行」。结果验收时甲方换了技术负责人，新来的看不懂代码，要求我们重新写文档。嗯，那笔费用最后算在了我们头上。
2.3 项目经理的角色分工
项目经理是项目的「粘合剂」。但很多人把项目经理当成了「传话筒」——甲方说一句，传给工程师；工程师说一句，传给甲方。
这不对。项目经理的核心价值是「翻译」和「决策」。
| 职责领域 | 具体工作 | 我踩过的坑 |
|---|---|---|
| 需求管理 | 把甲方的业务需求转化为技术任务 | 甲方说「要快」，我理解成「优化代码」，结果是甲方想要「换更快的芯片」 |
| 进度控制 | 制定里程碑，跟踪每日进展 | 有一次硬件工程师说「原理图画完了」，结果没画电源部分，白高兴一场 |
| 资源协调 | 人手不够？设备没到位？找项目经理 | 测试工程师同时跟三个项目，谁优先级高？项目经理得拍板 |
| 风险管控 | 提前识别风险，制定预案 | 芯片涨价这种事，项目经理应该比采购更早知道 |
项目经理不需要懂每一行代码，但得知道「谁在做什么」「做到哪了」「卡在哪里」。
2.4 硬件工程师的角色分工
硬件工程师是项目的「地基」。地基没打好，软件再牛也白搭。
- 原理图设计：芯片选型、外围电路、接口定义。我见过有人把电源正负极画反的——嗯，板子一上电就冒烟。
- PCB Layout：走线、阻抗匹配、EMC设计。别小看Layout，同样的原理图，不同人画出来性能差很多。
- 硬件调试：用示波器看波形，用万用表量电压。硬件工程师得有「手艺人」的耐心。
- BOM管理：物料清单、替代料、交期。我建议硬件工程师自己跟采购确认一遍，别完全依赖采购部门。
个人习惯：我每次画完原理图，都会打印出来，拿红笔逐条检查。电脑上看容易漏，纸上反而能发现问题。这招救过我至少三次。
2.5 软件工程师的角色分工
软件工程师是项目的「灵魂」。硬件是骨架，软件让产品活起来。
- 驱动开发：让芯片「开口说话」。I2C、SPI、UART，这些底层协议得玩得转。
- 应用层开发：业务逻辑、用户交互。这部分最容易被甲方改需求——「这里加个按钮」「那里改个颜色」。
- 协议栈集成：蓝牙、Wi-Fi、LoRa。别自己造轮子，能用现成的就用现成的。
- 固件调试：用J-Link、用串口打印。软件工程师得学会「二分法定位bug」——先确定问题在哪一层，再缩小范围。
软件工程师最容易犯的错是什么？我告诉你——「我觉得这样写没问题」。然后一跑就死机。所以，代码评审和单元测试不能省。
2.6 测试工程师的角色分工
测试工程师是项目的「守门员」。很多人觉得测试就是「点点点」，其实不是。
- 测试用例设计：正常场景、异常场景、边界条件。比如一个按键，按一次正常，按十次呢？按一万次呢？
- 功能测试：需求文档里写的功能，一个一个过。别漏项。
- 压力测试：长时间运行、高负载、高温高湿。嵌入式产品经常7x24小时运行，测试也得跑这么久。
- 回归测试：改了一个bug，会不会引入新bug？每次版本更新都得跑一遍。
我的经验：测试工程师最好从项目初期就介入。别等开发完了才叫测试来。那时候发现架构问题，改起来成本太高。我建议测试工程师参与需求评审和方案设计，提前「找茬」。
2.7 角色之间的协作关系
这几个角色不是孤立的。我画个简单的协作图给你看：
甲方（需求） → 项目经理（拆解） → 硬件工程师（设计）
→ 软件工程师（开发）
→ 测试工程师（验证）
↑_____________________________↓
反馈与迭代项目经理是枢纽。硬件和软件之间需要频繁沟通——比如某个引脚功能定义，硬件觉得该这么接，软件觉得该那么配。这时候项目经理得拉个会，当场定下来。
测试工程师发现问题，不能只丢一句「这里有问题」。得说清楚：什么条件下复现？期望结果是什么？实际结果是什么？这样开发才能快速定位。
避坑指南：我曾经见过一个项目，硬件工程师和软件工程师各干各的，直到联调那天才发现——硬件用的SPI模式0，软件配的模式3。嗯，整整调了两天。从那以后，我要求硬件和软件在方案阶段就对一遍接口定义。
2.8 小结
角色定位清晰了，项目就成功了一半。甲方别当甩手掌柜，乙方别闷头干活。项目经理别只做传话筒，工程师别只管自己那一亩三分地。
说白了，嵌入式外包项目是个团队活。每个人守好自己的边界，同时帮别人看一眼——这才是项目顺利推进的秘诀。
下一章，我会讲项目启动阶段的具体流程。包括需求评审、方案设计、合同签订这些实操内容。到时候见。