第6章 需求调研与业务痛点挖掘
本章导读
五步法里，调研诊断占30%权重，是最高的一步。原因简单：痛点找错，后面全白费。但调研恰恰是新手FDE最薄弱的环节——不会访谈、不会穿透表层需求、不会从一线员工嘴里提取隐性规则。
本章系统讲调研全流程：访谈怎么准备、怎么提问、怎么记录；用5Why穿透表层需求；从一线经验沉淀标准化规则；最后给出需求调研报告的标准结构与写法。读完本章，你应当能独立完成一次客户访谈，输出一份合格的调研报告。
§6.1 调研的本质：把模糊变清晰
客户给FDE的需求，几乎都是模糊的。“我们要做智能化客服"“我们想用AI提效"“我们想搭个知识库”——这些诉求里没有可执行的信息。
调研的本质，是把模糊诉求变成可执行的问题定义。这个过程要回答四个问题：
- 客户到底想要什么？（表层诉求）
- 客户为什么想要这个？（业务目标）
- 真正卡在哪里？（真实痛点）
- 这个痛点值得解决吗？（优先级与ROI）
调研的全部工作，就是回答这四个问题。
§6.2 调研全流程
图6-1：调研全流程 （建议呈现：横向流程图。访谈准备→现场访谈→信息记录→规则提取→报告输出。）
6.2.1 访谈准备
新手常犯的错是"不准备就去访谈”。准备不充分，访谈会变成闲聊，拿不到有效信息。
准备清单：
- 调研目标：这次访谈要搞清楚什么？（写3-5条具体问题）
- 受访对象：决策者、中层、一线员工各访谈什么？
- 背景资料：客户行业、业务模式、现有系统提前了解。
- 访谈提纲：按对象准备问题清单，但留出追问空间。
- 记录工具：录音（需征得同意）、笔记模板。
方法论框6-1：访谈准备的"三问三对象”
- 三问：这次要搞清什么？问谁？怎么问？
- 三对象：决策者（要战略与目标）、中层（要流程与资源）、一线（要真实卡点）。 三类对象信息互补，缺一类调研就不完整。
6.2.2 现场访谈
访谈的核心是提问与倾听，不是演讲。新手FDE常犯的错是急于展示方案，把访谈变成产品介绍会。
提问技巧：
- 开放式开场：“您能描述一下现在这块工作是怎么做的吗？"——让对象自由展开。
- 具体化追问：“您说的’经常出错’，大概一周几次？出错后怎么处理？"——把模糊描述变具体。
- 场景化还原：“上次遇到这个问题时，您具体是怎么操作的？"——还原真实流程。
- 避免诱导：不要问"您是不是觉得XX不好？"，要问"您觉得XX怎么样？"。
倾听技巧：
- 多听少说，FDE说话时间不超过30%。
- 抓关键词，及时追问（“您刚说’看情况’，是什么情况？"）。
- 注意非语言信号（犹豫、叹气、抱怨往往藏着真痛点）。
- 允许沉默，给对象思考空间。
6.2.3 信息记录
访谈不记录等于没访谈。记录要遵循"原文+整理"双层结构。
- 原文层：尽量记录对象原话，特别是带情绪的表达。
- 整理层：访谈后立即整理，把原话归类到流程、痛点、规则、目标等维度。
建议访谈结束后2小时内完成整理，否则细节会模糊。
6.2.4 规则提取
这是调研最考验功底的一步。一线员工说"我们就是这样做的”，背后往往是一堆隐性规则。FDE要把它提取出来，变成AI可执行的逻辑。
详见§6.4。
6.2.5 报告输出
调研最终要落到一份报告。详见§6.5。
§6.3 穿透表层需求：5Why分析法
客户给的诉求往往不是真正的问题。表层诉求→真实痛点之间，可能隔着好几层。
5Why的核心逻辑
5Why不是机械问5个为什么，而是逐层追问，直到找到可行动的根因。层数不固定，有时3层够，有时要7层。
用一个真实案例演示：
表层诉求：“我们要做一个智能客服。”
- Why1：为什么要做智能客服？
- 答：“客服响应太慢，客户投诉多。”
- Why2：为什么响应慢？
- 答：“客服人员不够，忙不过来。”
- Why3：为什么人不够不招人？
- 答：“招了留不住，培训成本高。”
- Why4：为什么留不住？
- 答：“工作重复枯燥，大量时间在回答相同问题。”
- Why5：为什么相同问题反复答？
- 答：“没有统一的知识库，新人靠问老人，老人离职知识就丢了。”
穿透到第5层，真实痛点浮现：不是缺客服，而是缺可复用的知识沉淀机制。 解法不是"智能客服"那么简单，而是先搭一个能持续沉淀与检索的知识库，再在此基础上做问答自动化。
如果不穿透，直接按"智能客服"做，很可能做完发现客户真正的问题没解决。
方法论框6-2：5Why的使用原则
- 不是机械问5次，是问到"可行动的根因"为止。
- 每层Why都基于上一层的回答，不是预设问题。
- 根因必须是FDE能影响的层面（不能停在"公司战略问题"这种FDE够不着的层）。
- 多人验证：把根因拿给不同对象确认，避免单一视角偏差。
§6.4 隐性业务规则提取
一线员工的工作里，藏着大量没写下来的规则。这些规则是AI落地的关键素材——AI要替代人做决策，必须知道人做决策的依据。
规则的三种类型
第一类：显性规则。 写在SOP、手册里的。这类好提取，直接查文档。
第二类：半显性规则。 员工口头能说清楚，但没写下来。这类要靠访谈提取。
第三类：隐性规则。 员工自己也说不清，但凭经验在做。这类最难，要靠观察与场景还原。
提取方法
方法一：场景还原法。 让员工描述一个具体案例的完整处理过程，逐步追问每个判断的依据。
示例（订单异常处理）：
- 员工：“这个订单我直接退回了。”
- 追问：“为什么退回不联系客户？”
- 员工：“金额超过5000的异常单要联系客户，这个才2000。”
- 追问：“那2000以下的都直接退？”
- 员工：“也不一定，如果客户是VIP就要联系。”
- 追问：“怎么判断VIP？”
- 员工：“系统里有标签，或者一年内下过5单以上。”
一轮追问，提取出一条规则树：
订单异常处理：
if 金额 > 5000 → 联系客户
elif 客户为VIP（系统标签 或 年下单≥5次）→ 联系客户
else → 直接退回
方法二：对比法。 给员工两个相似但结果不同的案例，问"这两个你为什么处理不一样”，差异点就是规则。
方法三：异常法。 问"什么情况下你会不按常规处理”，例外里往往藏着重要规则。
规则提取的产出
提取出的规则要整理成规则库，结构化呈现（决策树/规则表/流程图）。这个规则库是后续搭Skill和工作流的核心输入。
方法论框6-3：规则提取的三句追问
- 你为什么这么做？（提取主规则）
- 有没有例外？（提取边界规则）
- 例外怎么判断？（提取判断条件） 三句循环问，规则自然浮出。
§6.5 需求调研报告的标准结构
调研的最终产出是一份报告。报告不是流水账，是结构化的可执行信息。
标准结构
一、调研背景
- 客户概况、调研目标、调研对象、调研时间。
二、业务现状
- 现有业务流程图（谁做什么、卡在哪）。
- 关键系统与数据现状。
- 人员配置与分工。
三、痛点清单
- 按流程节点列出痛点，每条含：现象、影响、根因、频次。
- 痛点优先级排序（按影响×频次）。
四、规则提取
- 已提取的业务规则，结构化呈现。
- 标注规则的来源与可信度。
五、ROI初步测算
- 每个痛点的潜在收益（降本/提效/增收）。
- 实施成本估算。
- 优先级建议。
六、下一步建议
- 建议先解决哪个痛点。
- 建议用什么技术路径。
- 风险提示。
写作原则
- 结论先行：每节开头给结论，再展开论据。
- 数据说话：能用数字不用形容词（“每周约15次"比"经常"好）。
- 可执行：报告读完后，团队应当能直接进入方案设计。
- 可视化：流程图、规则树、优先级矩阵尽量图化。
方法论框6-4：调研报告的自检清单
- 业务流程图画了吗？
- 痛点有根因不是只现象吗？
- 痛点排了优先级吗？
- 规则提取结构化了吗？
- ROI有数字测算吗？
- 有明确的下一步建议吗？
- 六项齐全，报告才算合格。
§6.6 调研常见误区
误区一：只访谈决策者。 决策者给战略与目标，但真实卡点在一线。只访谈决策者，会做出"高层满意但一线用不起来"的方案。
误区二：急于给方案。 调研阶段一开口就讲方案，对象会顺着方案说，真实需求被掩盖。
误区三：把"想要"当"需要”。 客户说"我们要知识库”，这是想要；背后的"知识留不住、新人靠问"才是需要。FDE要区分两者。
误区四：调研一次就完。 复杂项目调研要分多次，初调定位、深调挖规则、验证调确认，不能一次了事。
误区五：报告写给客户看而不是写给团队看。 调研报告首要读者是执行团队，要可执行；给客户看的是另一份精简版。
本章小结
- 调研本质：把模糊诉求变成可执行的问题定义，回答"想要什么、为什么、卡在哪、值不值得"四问。
- 全流程：访谈准备→现场访谈→信息记录→规则提取→报告输出。
- 5Why：逐层追问到可行动根因，不是机械5次。
- 规则提取：场景还原、对比、异常三法，产出结构化规则库。
- 报告结构：背景→现状→痛点→规则→ROI→建议，六项齐全才合格。
- 核心原则：多听少说、结论先行、数据说话、可执行。
思考题
- 选一个你熟悉的工作场景，用5Why穿透一个表层诉求，写出完整追问链与根因。
- 用场景还原法，从一位同事那里提取一条他工作中的隐性规则，整理成规则树。
- 按方法论框6-4，为你做过（或观察过）的一次调研写一份报告自检。
- 找一位同事做一次15分钟访谈（主题任选），记录原话并整理，对比你的预期与实际听到的差异。
延伸阅读
- 本书第11章将讲全流程项目交付SOP，调研是其中的核心环节。
- 第14章讲落地避坑，许多坑根子在调研没做透。
- 经典需求调研方法论（如 Jobs-to-be-Done、用户故事地图）可作进阶阅读。