FDE系列10：需求的真相——为什么客户说的需求经常是错的？
本文是《FDE工程师-从AI技术实现到业务落地》系列文章第10篇
客户说"我要一个AI客服"，你猜他真正需要的是什么？
需求的三层结构
在FDE的工作中，客户说的需求，往往只是"冰山一角"。
┌──────────────┐
│ 客户说出来的 │ ← 水面之上（表面需求）
└──────────────┘
┌──────────────┐
│ 客户真正的需求 │ ← 水面之下（深层需求）
└──────────────┘
┌──────────────┐
│ 客户不知道的 │ ← 深海（潜在需求）
│ 但需要的 │
└──────────────┘
客户说出来的需求：客户认为的"解决方案" 客户真正的需求：客户想解决的核心问题 客户不知道但需要的：客户没想到，但能带来更大价值的方案
FDE的目标，不是实现"客户说出来的需求"，而是挖掘"客户真正的需求"，最好还能提供"客户不知道但需要的"方案。
深度访谈四层次法
如何挖掘客户真正的需求？FDE有一套标准化的"深度访谈四层次法"。
第一层：现状
目的：了解客户当前的业务状态。
问题示例：
"你现在的流程是什么样的？"
"你用了哪些系统？"
"这个流程，每天/每周/每月怎么运作？"
关键：不要问"你缺什么"，要问"你现在有什么"。
第二层：痛点
目的：找到客户在现状中"最难受"的地方。
问题示例：
"在这个流程中，你觉得最麻烦的是什么？"
"什么事情让你觉得最花时间？"
"什么环节最容易出错？"
关键：让客户自己说出"痛点"，而不是你替客户定义。
第三层：影响
目的：量化痛点带来的"损失"。
问题示例：
"这个问题，每个月大概造成多少损失？"
"如果不解决，预计会有什么影响？"
"这个问题，影响了哪些KPI？"
关键：把"痛点"变成"数字"，才能判断优先级。
第四层：期望
目的：了解客户对"解决方案"的预期。
问题示例：
"如果这个问题解决了，你希望看到什么变化？"
"什么才算'解决好了'？"
"你理想的解决方案是什么样子的？"
关键：不要用自己的标准替代客户的标准。
分角色访谈模板
不同的角色，关心的点完全不同。你需要"挨个聊"。
业务VP/总监（十问）
您今年的核心KPI是什么？
这个项目，您希望帮您达成什么KPI？
目前最大的业务瓶颈是什么？
您最担心项目出什么问题？
您对项目的期望是什么？
您觉得什么方案是"不可接受的"？
这个项目失败过吗？为什么？
您怎么看竞争对手的做法？
您愿意在什么条件下追加投入？
这个项目成功，您会怎么奖励团队？
一线员工（十问）
你每天的工作，最花时间的是什么？
什么工作是你觉得"最没价值"的？
现在的系统，最好用的功能是什么？
现在的系统，最让你抓狂的是什么？
如果有一个新功能，你希望它帮你做什么？
你用过哪些AI工具？觉得好用吗？
你担心新系统会"取代"你的工作吗？
你希望新系统怎么"帮"你，而不是"管"你？
你愿意参与新系统的测试吗？
你觉得什么对你们团队最重要？
IT部门（十问）
现在的系统架构是什么？
系统的主要技术栈是什么？
数据存在哪里？怎么接入？
安全和合规有什么要求？
系统的SLA是多长？
运维团队有多大？能力怎么样？
你们最担心什么技术问题？
你们的部署流程是什么？
你们有测试环境吗？
你们最希望新系统做什么？
AI项目中的"需求陷阱"
AI项目在需求阶段，有几个特别容易踩的陷阱：
陷阱一：把"AI"当成"答案"
客户说"我们要用AI"——但这往往不是一个"需求"，而是一个"手段"。
FDE要做的是：先搞清楚"为什么要用AI"，再决定"是不是真的需要用AI"。
很多时候，一个简单的规则引擎就够了。
陷阱二：忽视"数据就绪度"
AI项目最核心的"需求"往往是——数据是否可用。
客户说"我们有数据"——但可能：
数据在Excel里，没有标准化
数据有大量缺失
数据标签不准确
数据量不够
在AI项目中，"数据需求"比"功能需求"更重要。
陷阱三：忽略"Human-in-the-loop"
AI项目最大的风险不是技术，而是"人"。
一线员工不信任AI，不接受AI的建议
管理者不知道AI的输出怎么用
客户方没有人有能力维护AI系统
在需求阶段，就要考虑"人的因素"。
需求确认的"黄金规则"
规则一：写在纸上
所有需求，必须写下来，双方签字确认。
不要相信"口头说好的"。
规则二：区分"必须"和"想要"
类型 定义 示例
Must have 没有这个功能，项目无法上线 数据接入、用户认证
Should have 最好有，但可以延迟 高级报表、数据大屏
Nice to have 有更好，没有也行 深色模式、动画效果
把"Must have"先做出来，再谈其他的。
规则三：设定"需求冻结"节点
项目启动后，需求不能无限追加。
设定一个"需求冻结"节点，之后的任何需求变更，走正式的变更流程。
不变更需求，是对项目负责任的表现。
需求管理自检清单
[ ] 我有没有和"所有"关键角色聊过？
[ ] 我有没有追问到"第四层"（期望）？
[ ] 我有没有验证"数据就绪度"？
[ ] 我有没有考虑"人"的因素？
[ ] 我有没有区分"必须"和"想要"？
[ ] 我有没有把需求写在纸上，双方确认？
🔥 关注「AI拉呱」
本系列持续更新中。
下一篇预告： FDE系列11：差异分析——产品与客户需求之间的鸿沟怎么填？
我们不见不散。
