4、需求变更管理：客户临时改需求，嵌入式开发周期如何应对？
做嵌入式开发这么多年，我最怕听到的一句话就是：“客户那边又改需求了。” 说实话，硬件都投板了，代码都调通了，这时候来一句“我们要加个功能”，那感觉就像你刚把饭做好，客人说他想吃火锅。
但怕归怕，活儿还得干。需求变更在嵌入式项目里是常态，不是意外。我这些年踩过的坑，总结下来就一句话：不是所有变更都要立刻做，但所有变更都必须有流程。
4.1 为什么嵌入式项目对需求变更特别敏感？
你想想看，嵌入式开发和纯软件不一样。软件改个功能，重新编译一下就行。嵌入式呢？牵一发动全身。
- 硬件已经定了：MCU选型、外设接口、引脚分配，这些在项目初期就锁死了。客户临时要加个传感器？先看看I2C/SPI口还有没有空余。
- 固件烧录麻烦：量产后的设备，OTA升级还好说，要是需要拆机烧录，那成本就高了。
- 认证测试重做：改一个功能，EMC、安规、可靠性测试可能都要重来一遍。这个时间成本，客户往往看不到。
核心观点：嵌入式项目的需求变更，本质上是在“硬件固化”和“软件灵活”之间找平衡。硬件一旦定了，改动的代价是指数级上升的。
4.2 需求变更的“三段式”应对策略
我个人习惯把需求变更分成三个阶段来处理：接收、评估、执行。每个阶段都有对应的沟通要点。
4.2.1 第一阶段：接收变更——别急着说“行”或“不行”
客户提出变更时，很多工程师的第一反应是“这个简单，加个if判断就行”。我劝你千万别这么干。我在项目中遇到过太多次，看似简单的改动，最后改出了大问题。
正确的做法是：先记录，再承诺。
- 记录清楚：客户到底要改什么？是改功能、加功能，还是改性能指标？用邮件或文档固定下来，别口头说。
- 问清楚背景：为什么要改？是市场需要，还是客户个人喜好？有时候客户自己也没想清楚。
- 给个缓冲期：别说“我马上看看”，而是说“我回去评估一下，明天给你答复”。这个缓冲期很重要，能让你冷静分析。
小技巧：我习惯在项目启动时就建一个“需求变更登记表”，每次客户提变更，就填进去。这样后期扯皮时，有据可查。
4.2.2 第二阶段：评估变更——用数据说话
评估阶段，是技术活，也是沟通活。你需要回答三个问题：
- 技术可行性：现有硬件能不能支持？MCU算力够不够？Flash/RAM还有余量吗？
- 开发工作量：改代码要多久？测试要多久？会不会影响其他功能？
- 时间与成本：这个变更会推迟交付日期吗？会增加多少成本？
我一般会用一张表来评估，给客户看的时候一目了然：
| 评估项 | 具体内容 | 影响程度 |
|---|---|---|
| 硬件资源 | Flash剩余8KB，RAM剩余2KB | 需优化代码，可能够用 |
| 开发周期 | 固件修改3天，测试2天 | 总工期增加5天 |
| 回归测试 | 需重新跑全部测试用例 | 增加3天 |
| 认证影响 | EMC测试需重做部分项目 | 增加2周，费用约2万 |
有了这张表，你跟客户沟通时就有底气了。不是你说“做不了”，而是“做可以，但需要这些代价”。
4.2.3 第三阶段：执行变更——控制范围，分步实施
如果客户接受了评估结果，同意变更，那接下来就是执行。这里有个坑：变更往往会引发连锁反应。
我曾经遇到一个案例：客户要求把UART通信协议从Modbus改成自定义协议。看起来只是改个协议栈，结果呢？上位机要改、测试工具要改、文档要改、生产线的烧录程序也要改。最后花了三周才搞定。
所以，执行变更时，我建议：
- 划定边界：明确这次变更只影响哪些模块，其他模块不动。
- 分步实施：先改核心功能，再改外围。每一步都做单元测试。
- 版本控制：用Git或SVN打好标签，万一改出问题，能快速回退。
避坑指南：我曾经因为一个“小变更”没做回归测试，结果导致量产批次的设备在高温下死机。从那以后，我定了个规矩：任何变更，哪怕只改一行代码，也必须跑完完整的回归测试。
4.3 如何跟客户沟通需求变更？
技术问题解决了，沟通问题才是大头。很多工程师技术很强，但一跟客户沟通就翻车。我总结了几条经验：
4.3.1 用“代价”代替“不行”
客户说“我要加这个功能”，你别直接说“做不了”。而是说：“这个功能可以做，但需要增加5天开发时间和2周测试时间，交付日期会推迟到X月X日。您看能接受吗？”
把选择权交给客户，让他自己权衡。很多时候，客户一听要延期，自己就放弃了。
4.3.2 给客户“ABC方案”
我习惯给客户提供多个方案：
- A方案：完全满足需求，但代价最大（时间最长、成本最高）
- B方案：部分满足需求，代价适中
- C方案：用现有功能变通实现，代价最小
客户通常会选B或C。为什么？因为人都有“折中偏好”。你直接给一个方案，他可能会讨价还价。你给三个，他反而会认真比较。
4.3.3 建立“变更委员会”
对于大项目，我建议成立一个变更控制委员会（CCB）。成员包括：项目经理、技术负责人、测试负责人、客户代表。所有变更必须经过CCB评审才能执行。
这样做的好处是：把个人决策变成集体决策。客户不会只盯着你一个人催，而是面对整个团队。
4.4 预防胜于治疗：如何在项目前期减少需求变更？
说了这么多应对方法，其实最好的策略是预防。我在项目启动阶段，会做三件事：
- 需求冻结期：跟客户约定，在硬件投板前，需求可以改。投板后，只接受“必要”的变更。
- 原型验证：用开发板快速搭一个原型，让客户亲手体验。很多时候，客户看到实物后，自己就会调整需求。
- 合同条款：在合同中明确需求变更的流程和费用。比如：每次变更收取X元评估费，变更导致延期不追究责任。
总结一下：需求变更不可怕，可怕的是没有流程。接收时别急着答应，评估时用数据说话，执行时控制范围。跟客户沟通时，多给选项，少说“不行”。
嗯，这套方法我用了十几年，不能说百试百灵，但至少能让你在客户面前站得住脚。下次客户再临时改需求，你就知道该怎么应对了。