3、需求冻结与范围控制：砍掉非核心功能、设定优先级矩阵、与客户重新谈判
项目进度失控，十有八九是需求没管住。
我见过太多团队，一开始拍胸脯说「都能做」，结果做到一半发现资源根本不够。这时候怎么办？硬扛？不现实。延期？客户不答应。唯一的出路，就是——砍需求。
但砍需求不是乱砍。你得有策略、有依据、有谈判筹码。这一节，我就聊聊怎么把「失控的需求」拉回正轨。
3.1 先搞清楚：哪些功能是「非核心」？
说白了，嵌入式项目里，功能分三类：
- 核心功能：没有它，产品就是废铁。比如电机的驱动、传感器的数据采集。
- 增强功能：有了更好，没有也能用。比如远程升级、日志导出。
- 锦上添花：纯属「想要」而非「需要」。比如炫酷的LED灯效、语音播报。
我个人习惯，在项目启动时就列一张功能清单，让客户和团队一起打标签。怎么打？用优先级矩阵。
优先级矩阵（示例）
| 功能名称 | 业务价值（1-5） | 实现成本（1-5） | 优先级 |
|---|---|---|---|
| 电机PID控制 | 5 | 3 | P0（必须做） |
| Wi-Fi远程配置 | 4 | 4 | P1（尽量做） |
| OLED动画显示 | 2 | 2 | P2（可延期） |
| 语音播报 | 1 | 3 | P3（砍掉） |
我的经验：优先级矩阵最好在项目启动会上就做。别等到进度失控了再补，那时候客户已经对每个功能都「充满感情」了。
3.2 砍功能，不是「你说了算」
很多工程师觉得，砍功能就是跟客户说「这个做不了」。错。那是吵架，不是谈判。
我建议你换个思路：用数据说话。
比如，你发现某个功能需要额外增加2周开发时间，而项目只剩3周了。你可以这样跟客户说：
「王总，这个远程升级功能，我们评估下来需要2周。如果坚持做，那核心的电机控制测试时间就会被压缩。您看，是优先保证电机控制的稳定性，还是先上远程升级？」
你看，这不是「做不了」，而是「二选一」。客户自然会选核心功能。
谈判的「三不原则」
- 不直接拒绝：说「做不了」等于关上门。说「我们可以做，但会影响进度」才是谈判。
- 不模糊承诺：别说什么「尽量做」。要么明确排期，要么明确砍掉。
- 不单方面决定：砍功能一定要客户签字确认。我吃过这个亏——口头答应砍了，验收时又翻旧账。
避坑指南：我曾经因为客户口头说「这个功能不急」，就把它从Sprint里移除了。结果验收时客户说「我什么时候说过不急？」——从那以后，所有需求变更必须走邮件或签字流程。
3.3 需求冻结：给「变」画个句号
嵌入式项目最怕什么？怕的是「边做边改」。今天加个传感器，明天换个通信协议。你想想看，硬件都打样了，软件还在改接口，这项目能按时交付才怪。
所以，我强烈建议在项目中期设置一个需求冻结点。
需求冻结的实操方法
- 明确冻结时间：比如「硬件投板前一周」或「软件Alpha版本发布时」。
- 发布冻结公告：邮件通知所有干系人，包括客户、项目经理、开发团队。
- 建立变更委员会：冻结后，任何需求变更必须经过委员会评审。委员会由项目经理、技术负责人、客户代表组成。
- 变更代价可视化：每次变更，都要评估对进度、成本、质量的影响，并让客户签字确认。
关键点：需求冻结不是「不让改」，而是「改之前先算账」。算清楚代价，客户自然就谨慎了。
3.4 与客户重新谈判：从「对立」到「同盟」
进度失控时，客户往往比你还急。这时候谈判，其实是有筹码的。
我常用的策略是：先承认问题，再给出方案。
比如：
「李总，目前项目确实比计划晚了2周。我们分析了一下，主要原因是XX功能比预期复杂。现在有两个方案：
方案A：砍掉XX功能，按原定时间交付，核心功能全部保留。
方案B：保留所有功能，但交付时间推迟3周。
您看哪个更符合您的业务需求？」
你看，这样就把「你 vs 客户」变成了「你 & 客户 vs 问题」。客户会站在你这边，一起想办法。
谈判时的「三个不要」
- 不要抱怨：别说「都是你们需求变来变去」。客户听了只会觉得你能力不行。
- 不要隐瞒：进度问题越早说越好。拖到最后一刻，神仙也救不了。
- 不要承诺做不到的事：为了安抚客户，承诺「加班搞定」。结果没搞定，信任就彻底没了。
我的习惯：每次跟客户谈判前，我都会准备两份方案。一份是「保守方案」（砍功能保时间），一份是「激进方案」（加资源保功能）。让客户选，而不是让客户想。
3.5 总结：砍需求，是为了活下来
嵌入式项目，资源有限，时间有限。什么都想做，往往什么都做不好。
砍掉非核心功能，不是失败，而是战略聚焦。设定优先级矩阵，不是推卸责任，而是科学决策。与客户重新谈判，不是认怂，而是专业表现。
记住一句话：交付一个功能完整、质量可靠的产品，比交付一个功能残缺、bug一堆的产品，强一百倍。
嗯，这一节就聊到这里。下一节，我们聊聊「如何用敏捷方法快速止血」——说白了，就是怎么在混乱中找回节奏。