售前客户需求深度挖掘：从表面诉求到核心痛点的五步法
# 003、客户需求深度挖掘：从表面诉求到核心痛点的五步法
---
上周调一个嵌入式项目，客户说“设备偶尔会死机，重启就好”。我们查了三天的日志，发现是内存泄漏。但真正的问题是什么？是代码质量？不完全是。最后发现是客户为了省成本，把512K的SRAM换成了256K，但没改内存池配置。客户嘴上说的是“死机”，实际痛点是“成本压力下的硬件降配”，而没告诉我们的潜台词是“能不能用软件优化帮我扛过去”。
这种场景太常见了。客户往往不会直接告诉你他想要什么，就像你问用户要什么，他会说“更快的马”，而不是“汽车”。做售前，如果只盯着表面需求写方案，最后交付时必然扯皮。
---
## 第一步：先当工程师，再当侦探
客户说“系统要支持TCP和UDP”。别急着写进方案。先问自己：为什么同时要两种协议？是不是他们之前用UDP丢包严重，想换TCP但又不敢全换？还是上层应用既有实时流又要可靠传输？
我习惯在需求访谈时带个笔记本，左边记客户原话，右边写我的猜测。比如：
```
客户原话：“通信模块要支持断线重连”
我的猜测：现场网络不稳定？设备会移动？重连后数据补传机制有没有？
```
这时候别怕问“蠢问题”：“咱们之前是不是在哪栽过跟头？” 客户往往这时候才开始说真话。
---
## 第二步：挖历史包袱，代码不会骗人
如果是升级项目，一定要看老代码。有一次客户说“新平台性能要提升50%”，结果看了旧代码，发现全是全局变量加轮询，中断里塞了打印日志。这哪是硬件性能问题，分明是架构技术债。
你可以说：“咱们一起review下旧版本的痛点，比如有没有哪段代码你们特想重写但没时间？” 这时候客户工程师往往会打开话匣子：“哎，那个驱动层啊，当年为了赶工期……”
历史代码是需求的矿藏，里面埋着真实的痛点。
---
## 第三步：用场景倒推，别信规格列表
客户给的需求文档往往是一堆参数：响应时间<100ms、支持1000个节点、功耗低于1W。这些数字怎么来的？要还原场景。
“100ms的响应时间，是哪个操作触发的？是按键到屏幕刷新，还是数据上报到云端回包？” 我遇过一个案例，客户咬定要50ms响应，后来发现是他们测试时用人眼感觉“卡顿”，实际测下来80ms用户就无感知了。省下的30ms，让我们把CPU主频降了一档，功耗直接降了40%。
场景还原最好的方法是画时间轴：触发事件 -> 数据流经哪些模块 -> 最终输出。客户一看图，自己就会说“哦，其实这里可以放宽点”。
---
## 第四步：问“如果不实现”，暴露优先级
这是我最喜欢的一招。当客户提了一堆需求，问他：“如果这个功能不做，你们最大的损失是什么？” 或者“如果只能实现三个，你保哪三个？”
有一次客户列了8个通信协议，我们问完这个问题，他自己沉默了十秒，然后说：“其实就MQTT必须要有，其他都是给未来预留的。” 方案工作量直接砍掉一半。
嵌入式里尤其要这么问：“RTOS一定要上吗？如果裸机跑，最担心什么？” 可能客户只是听说“RTOS更高级”，其实他的业务逻辑一个主循环加几个中断就能搞定。
---
## 第五步：用原型验证痛点，别只写PPT
售前最容易犯的错：把方案写成功能罗列。高手会做“痛点原型”。比如客户担心无线信号不稳定，你别光说“我们支持Lora+4G双链路”，而是拿开发板去现场实测，录一段视频：在信号死角，自动切换链路，数据没丢。
甚至代码注释都可以成为沟通工具：
```c
// 这里原来用malloc，但客户现场跑72小时会碎片化崩溃
// 改静态内存池，虽然浪费10%空间，但稳如老狗
static uint8_t mem_pool[1024 * 10]; // 别动态分配，客户怕不稳定
```
让客户看到你懂他的恐惧，比展示一百个参数都有用。
---
## 最后聊点实在的
需求挖掘不是审问，是共情。客户说“要高性能”，可能背后是竞品用低配芯片跑得比他们快；客户说“要兼容旧设备”，可能是老板不想报废那批还没折旧完的硬件。
我习惯在需求会议后，给客户发个简版纪要，里面特意加一栏“我们理解的深层需求”，用工程师的口吻写，比如：
“我们推测咱们最想解决的是：在车间电机干扰下，通信误码率从10^-3降到10^-5，同时不换现有线缆。”
客户如果回复“对，就是这个意思”，这单基本就成了。
别做需求搬运工，要做痛点翻译官。芯片选型、架构设计、代码风格，所有这些技术决策的源头，都在那些没写在招标书里的潜台词里。