FDE学习笔记⑦:客户说要知识库,我先问他遇到了什么问题

上一篇，我读到 FDE 的能力模型：东西做得出来，客户用得起来，经验复用得起来。这一篇回到交付方法论，读《需求发现与问题拆解》。

这章讨论的是项目起步时的一件事：客户说“我们要做一个 AI 知识库”， FDE 怎样把这句话，变成一个能验证的问题？

它给出的路径很清楚：先看谁在什么场景遇到困难，再明确希望改善的结果，拆出障碍，找到关键难点，最后给出一个具体的验证动作。

读完后，我最大的感触是：这跟产品经理挖掘用户、客户需求的过程很像。熟悉的方法到了 FDE 这里，还要继续走向现场交付。

一、先把客户要的东西，翻译成他想改变的结果

“做一个 AI 知识库”，已经包含了客户对方案的判断。但这句话还没有讲清：谁要用？现在遇到了什么困难？为什么现有办法不够用？

课程要求先写出一份问题陈述，把用户、场景、结果、现状、痛点、指标、约束和非目标说清楚。

其中一个例子是合同初审。课程把目标具体写成：帮助一线法务标出与模板不符的高风险条款，在不增加高风险漏检的前提下缩短初审时间。合同不能离开企业环境，处理过程需要可追溯；自动改写合同、提供商务谈判建议，则不在本次范围内。

这个例子让我更容易理解“结果”。它同时说明了要改善什么、什么不能变差，以及这次做到哪里为止。仅仅写“提高合同审核效率”，后面很难判断是否成功。

课程还有一个追问：有了解决方案之后，会发生什么？

合同风险标出来以后，由谁复核？谁决定修改？怎样交回业务？这些问题决定了系统输出能否进入实际工作。生成一份报告，只完成了其中一段。

目标清楚后，才轮到问题拆解。原文特意区分了两种拆法：“采数据、训练、上线”是项目阶段；“风险定义不清、模板版本混乱、结果如何写回系统”才是在拆阻碍目标的具体问题。

这一区分很有用。项目可以按时走完开发流程，但如果大家始终没有统一高风险的判断标准，最后还是无法证明系统有用。

课程把会让结果落空的关键障碍叫作“硬点”。合同例子给出的下一步，是请律师标注一批合同，形成初版评判规则和测试样本。这个动作既能准备评估材料，也能发现专家是否对判断标准存在分歧。

先找最可能让目标无法成立的条件，再用一个小动作检验它。 这是我对原文方法的归纳。原文提到的“一天能解就一天解”，也要放回这条逻辑里理解：问题与交付边界清楚时，就尽快完成一个小闭环。

二、知识库的讨论，让我看见了现象与假设的距离

学习时，我们用了一个假设场景：客户想建企业知识库，因为新人总问重复问题，老员工经常被打断。

我的第一反应是继续问。我大致会沿着五个方向聊：

我也觉得，沟通过程中应该多倾听，不急着预设观点和方向，让客户充分表达。过早否定，很可能还没了解问题，就把对话变成了方案辩论。

随后，我会继续了解：新人常问哪些问题，哪些反复出现；除了问老员工，还有没有其他途径；老员工被问到的具体是什么，他们有什么建议。

这里，我开始把客户的描述和解释分开。

“新人反复求助、老员工受到打断”，是客户报告的现象。但它是否拖慢了整个业务，是否是流程中最值得优先解决的一环，还需要证据。建立知识库能把老员工解放出来，也仍然是一个假设。

讨论中， AI 进一步提醒：连“新人知识掌握不足”这个原因，都不能过早确认。

新人可能缺少答案，也可能找到了两个版本的规定，不知道信哪个；还可能知道规定，却没有权限决定。这些情况都表现为“新人来问老员工”，背后的障碍却不同。

顺着这些可能性推演，公司即使已有知识库，求助也未必消失。资料是否有效、新人能否找到、是否敢于采用，以及能否据此行动，每一环都可能卡住。

这让我觉得，访谈需要尽快落到一次真实工作上。与其停在“平时怎么做”，更有用的追问是：“能带我看一下最近一次吗？从收到问题，到处理结束。”

具体问了什么，之前查过哪里，等了谁，最终怎样解决，有没有返工。这些细节才有机会帮助我们判断，大家缺的是资料、查找方式、判断依据，还是审批权限。

而“提问减少”也不能单独代表成功。有些求助本来就在帮助新人避免错误。业务完成得是否更快、更可靠，需要一起看。

三、熟悉的产品方法，还要向交付多走一步

聊到这里，我说：“这一篇跟产品经理挖掘用户、客户需求的过程很像。”

用户、场景、现有流程、痛点、指标，这些都是产品工作里熟悉的问题。学习 FDE 时，我可以从已有经验出发，继续理解它对交付提出的要求。

讨论里对岗位差异的补充，也让我觉得更具体了。产品经理通常还要考虑需求覆盖多少用户、是否符合产品方向、如何安排投入； FDE 经常需要继续深入当前客户的现场，查清数据能否拿到、权限能否打通、结果怎样接入系统，以及试点如何验证。

这些职责会重叠，企业产品经理也可能承担完整交付。对我而言，更有帮助的是用它检查责任有没有向前推进。

还是知识库这个场景。需求发现之后，如果决定先试一类新人常见问题，接着就要明确：资料由谁确认？哪些员工有权访问？内容过期由谁更新？回答不了时转给谁？怎样判断试点减少了无效打断，同时没有增加业务错误？

这里的“下一步”，已经从一个功能方向，变成了可以执行和检验的工作。

这一章我想留下两个认识：客户描述了一个现象，不代表原因和解法已经成立；需求发现之后，还要拿出能够验证关键判断的下一步。

我熟悉的是前面的访谈与分析。接下来要继续补的，是怎样把判断落实到数据、权限、流程和验收里。课堂上能把问题问清楚，只是开始。

下一篇，我继续读《客户沟通与阻力处理》：问题定义清楚之后，怎样和客户把边界、风险与下一步说透。

学习材料： FDE 课程《需求发现与问题拆解》，课程仓库^[1]。知识库场景来自本次学习讨论中的假设练习。

参考链接

[1] 课程仓库: https://github.com/VanGong1999/FDE

本文由 AI 辅助创作，作者进行了实测验证和编辑修改。