FDE 驻场第一周,先写一页纸,别急着做原型
访谈时问客户上次怎么做,不问想要什么功能,拿到的才是数据,而不是愿望清单。
要点速览
- 客户调研是 FDE 自己的工作,不能甩给产品经理。第一周把问题理解错了,整个团队都会做错东西。
- 最好的开场问题是请客户讲讲上一次做这件事的经过。客户的夸奖都是愚人金。
- 成功定义要有用户、指标、当前水平和目标值,而且要具体到有可能被证明是错的。
周一早上,你坐在客户的会议室里。你拿到了数据仓库的访问权限、一个 Slack 频道,还有部门负责人的一句话需求:“我们需要一个 Agent 来处理订单调度。”
开发者的本能是打开笔记本,马上动手做原型。先等几天,从一张白纸开始。
Perspective AI 在 2026 年发布了一份关于 FDE 如何开展调研的指南。指南认为,理解客户是前线部署工程师(FDE)工作的核心,而不是交给产品经理的事。弄清系统到底要做什么,是 FDE 的责任。
所以,如果你把问题理解错了,团队很可能会做错东西,而且这个错误可能要等投入大量精力之后才会暴露。
为什么不直接问客户需要什么?
FDE 模式起源于 Palantir,它很早就明白了这一点。Palantir 不去问客户想要什么,而是把工程师派进客户自己的环境。面对复杂而新颖的问题,客户往往要等看到系统跑起来,才知道自己需要什么。
访谈依然重要,但问题要问对。“你需要哪些功能?”换来的是一份愿望清单。“上次做这件事时情况怎么样?”换来的是数据。一页纸计划的作用,就是逼自己问第二类问题。
第 0 周:这一页纸上写什么?
同一份 Perspective AI 指南给出了一个为期四周的 FDE 调研周期:第 0 周打基础,第 1–2 周做大范围的异步客户访谈,第 3–4 周和客户的领域专家一起设计评测。第 0 周发生在写第一行代码之前,必须产出两样东西。
第一样是利益相关方地图:高管发起人、负责评估结果的人(评测负责人)、最终用户、系统管理对接人,以及怀疑者。第二样是明确区分谁来评判系统输出、谁从输出中获益。这两者往往不是同一批人。
下面这页纸的其余部分是建议的结构,并非出自该指南。把自己限制在一页之内:如果一页写不下,说明你还不清楚什么最重要。可以直接套用的模板:
调研计划 — [客户] — 第 0 周
1. 用客户自己的话描述问题:
2. 利益相关方地图(谁能阻止、拖慢、扩大项目):
发起人 | 评测负责人 | 最终用户 | 系统管理员 | 怀疑者
谁评判输出?谁从输出中获益?
3. 最多 3 条待验证的假设:
4. 第 1–2 周访谈安排(访谈谁、何时、同步还是异步):
5. 成功定义:
[谁] 把 [X] 从 [Y] 降低/提高到 [N],衡量方式为 [如何衡量]
6. 待解决的问题:
第五行最难写,所以先空着。等和真实用户聊过之后再填。
先见怀疑者
利益相关方地图上有一栏常被遗忘:怀疑者。Perspective AI 指南把这个人描述为客户组织中不看好项目成功的人,他能帮你发现真正关键的失败模式。
不要回避这个人。问他指南建议的两个问题:“要让这件事真正成功,需要满足哪些条件?”以及“这个组织里类似的项目以前在哪里失败过?”
他们的回答会告诉你,他们认为项目会在哪里出问题。在第一周,这通常是你能拿到的最诚实的风险清单。
访谈提纲:问上周的事
对于最终用户,指南建议用“讲讲你上一次做 X 的经过”开场。这契合 Rob Fitzpatrick 所著《The Mom Test》中的两条原则。
第一条:谈客户的生活,而不是你的想法。第二条:问已经发生过的具体事情,而不是泛泛的看法或对未来的预测。
一份 20 分钟的提纲可以是这样:
开场: “讲讲你上一次给早班规划路线的经过。”
深挖: “哪一步最花时间?那天花了多久?”
“当时你开着哪些界面或文件?”
“上一次出问题时,你是怎么处理的?”
收尾: “有没有什么我该问却没问的?”
“接下来我应该找谁聊?”
两个收尾问题都来自《The Mom Test》。书中还认为,每次会面的目标是拿到一个承诺和一个下一步,比如再约一次会面或帮忙引荐。
忽略“听起来很棒”这类话。Fitzpatrick 把夸奖称为客户学习中的愚人金:闪亮、分散注意力,而且毫无价值。
关于访谈数量,Perspective AI 指南提到,FDE 在头两周通常会做 15–40 次异步客户访谈,而实时访谈因为难以约时间,往往停留在 8–10 次左右。
把这个数字当作提醒。你不坐在回答者旁边时,提纲必须清楚到对方可以独立作答,所以批量发出之前,要认真写好并测试。
从一句回答到一个可能出错的数字
假设有一家物流公司。你问一位调度员上一次规划路线的经过。她说:“上周一早上,我花了大约 90 分钟。早上 6 点有两辆卡车报故障,我得挨个给司机打电话,再把所有信息手动抄进 Excel,结果有三单送晚了。”
这句话已经给了你需要的一切。用户是早班调度员。X 是路线规划时间。Y 是 90 分钟,也就是她亲口说的当前水平。你提出 N 为 30 分钟,再和她以及怀疑者核实这个目标是否现实。
这页纸的第五行现在写成:“早班调度员把路线规划时间从 90 分钟缩短到 30 分钟,以连续 10 个班次的时间记录衡量。”这个陈述有可能是错的,正因如此它才有用。“Agent 让调度更高效”永远不会错,所以什么也证明不了。
有了第一版原型后,拿给领域专家看。Perspective AI 指南说得很明确:不要让他们给假设的输出打分,要给他们真实的输出。一份针对周一早班的真实路线方案,会暴露出任何访谈都挖不出来的潜规则。
让这页纸失效的三个错误
最常见的错误是还没提问就先展示方案。一上来就演示你的 Agent,客户就会讨论你的 Agent,而不是描述他们的工作。你一个问题都还没问,这次访谈就已经违反了《The Mom Test》的第一条原则。
第二个错误是把夸奖和承诺当成数据记下来。“我们肯定会用”是对未来的预测。“上周我花了 90 分钟”是已经发生的事。只有后者才能写进成功定义。
最后一个错误是只访谈项目的支持者。没有怀疑者的利益相关方地图,只会让你看到自己想看的东西。设想一下:真正的风险在法务团队、IT 部门,或者一位已经看着三个项目先后失败的班组长身上,而它恰好在你准备上线时冒出来。
把这页纸带去求职面试
如果某个 FDE 岗位的职位描述提到“客户调研”或“需求范围界定”,准备好一个具体的调研故事。
用成功定义的同一套结构写进简历:你访谈了谁,发现了什么,哪个指标从 Y 变到了 N。如果还没做过真实项目,为一家你熟悉的企业写一页调研计划,也值得带去。
你在第三周写的代码,最多只能和第 0 周写的那页纸一样好。所以,先把那页纸写出来。
这篇文章对你有帮助吗?
感谢你的反馈!