# 客户在需求调研里没说的事，FDE 一天就能找出来

> 人们描述的是自以为遵循的流程；坐在旁边看，才能发现连他们自己都没察觉的习惯，而 Agent 恰恰会在这些地方出错。

原文: https://fdetimes.net/zh/guides/contextual-inquiry-sit-with-users/

你刚和一家物流公司的运营负责人开完需求调研会。流程已经画得清清楚楚：投诉邮件进来，员工阅读，在系统里选择事故类型，再转给负责的团队。一共四步，你的任务是做一个 Agent 把它们自动化。

这张图几乎肯定不完整。没有人对你撒谎，人们只是在描述他们*以为*自己遵循的流程。OpenAI 前线部署工程负责人在 Pragmatic Engineer 上撰文指出，客户在需求调研时描述的内容，常常和一线数据与系统的实际情况对不上。

对前线部署工程师（FDE）来说，这个差距不只是 UX 问题。如果 Agent 是照着这张四步图设计的，它会恰好在图里漏掉的地方出错。本文介绍的就是弥合这个差距的技能：在用户身边待一天，并且用对的方式观察。

## 为什么描述总比实际工作更整齐？

原因很简单。Nielsen Norman Group（NN/g）指出，人们回忆和概括自己的工作流程时，背后的推理、动机和心智模型都会从概括中丢掉。

剩下的是步骤，原因没了。所以 UserTesting 提到，用户自述的行为与你观察到的实际操作并不总是一致。

问得再仔细也弥合不了这个差距。NN/g 认为，真实的工作情境还会暴露出用户自己都没意识到的行为，而你没法问一个人他根本不知道自己有的习惯。

这也是 Paraform 在描述 FDE 岗位时说，有些约束只有在看到人实际使用软件时才会出现。

实际结论是：FDE 必须出现在工作发生的地方。一位 Palantir FDE 告诉 Pragmatic Engineer，大多数周里他们有好几天在客户现场工作。

**要点:** 客户告诉你的是他们以为自己遵循的流程。想看到真实的流程，就得坐下来看。

## 以学徒身份到场，而不是访谈者

NN/g 将情境调查定义为一种民族志式的实地研究，把深入观察与访谈结合起来。它用师傅和学徒来形容这种关系：师傅通过做事传授手艺，学徒通过观看来学习。

站到学徒的位置上，你在现场的方式就变了。访谈者提问，然后等答案。学徒盯着师傅的手，留意他们在哪里犹豫、多开了哪些窗口，然后才问：“你刚才为什么这么做？”用户不再需要做任何展示，只要像平常一样工作。

## 示例：投诉团队的一天

回到那家物流公司。设想你从早上 9 点开始坐在投诉专员 Lan 身后。你什么都不问，只在四栏表格里记笔记。下面是这份日志的一段假设摘录：

| 时间 | 你看到了什么 | 留待提问 | 设计影响 |
|---|---|---|---|
| 9:12 | 选择事故类型之前，她在第二块显示器上打开一个 Excel 文件查客户名称 | 这是什么文件，由谁更新？ | 系统之外还有一份重点客户名单，Agent 需要能读取它 |
| 9:40 | 她把运单号复制到承运商网站上查，而不是查内部系统 | 为什么不在系统里查状态？ | 内部数据可能有滞后；在让 Agent 依赖它之前，先确认它更新得够不够快 |
| 10:05 | 遇到一封意思含糊的邮件，她把内容贴到团队群里问同事 | 这类情况通常由谁决定？ | 必须有转交人工的路径；不要强迫 Agent 自己给每封邮件分类 |
| 10:30 | 一封同时描述了两起事故的邮件，她选了“其他” | 涉及多起事故的邮件怎么处理？ | 现有数据模型假设每封邮件只有一个标签 |

这几行没有一行出现在四步图里，但其中任何一行都可能让 Agent 在生产环境的第一周就出问题。值得注意的是，Lan 并没有隐瞒什么。对她来说，这些只是“活儿就是这么干的”，不值一提。

等她休息时，你拿出“留待提问”那一栏。直到这时访谈才开始，而且问题都锚定在刚刚发生的事情上，而不是笼统的回忆。

## 自己动手的步骤

**做好准备。** 要求观察一个普通工作日，而不是一场演示。说明你是来学习他们怎么工作的，不是来评估他们。带上上面那份四栏日志模板。

**既看日常工作，也看例外。** AI Engineer 关于 FDE 的知识库建议，在观察日常工作的同时，也要观察那些会带来实际后果的例外情况，以及非正式的变通做法。日常工作让你看到理想路径，例外和捷径让你看到真实系统缺了什么。

**描述听起来太顺时，要一个例子。** 同一来源建议，当一个流程被描述得过于顺畅时，就请对方举一个最近的例子。实际可以这样问：“上次遇到这种情况是什么时候？能打开给我看看吗？”具体的例子能把人从理想化的流程拉回实际发生的事。

**与需求调研结果对照。** 当天晚上，把日志和需求调研文档放在一起比对。每一处不一致，要么是要带去找决策者的问题，要么是对设计的修改。

## 让观察变得毫无价值的错误

最常见的错误是打断。AI Engineer 指出，在用户工作时提问会改变他们的行为。被问到“你为什么打开那个文件？”之后，Lan 可能会开始为了你而“照章办事”。所以记下时间，把问题留到后面。

第二个错误工程师更难避免：看到用户卡住，就想马上帮忙。同一来源提醒，一旦你成了用户的技术支持，就可能掩盖你本来要找的那些困难。

Lan 在承运商网站上折腾的那三分钟是宝贵的数据。你教她一个快捷方法，这些数据就没了。

第三个错误是只观察团队负责人。主导需求调研的人通常不是每天干活的人。要求坐到最终用户身边，越靠近一线越好。

## 这项技能如何体现在简历上？

阅读 FDE 岗位描述时，留意“在客户现场工作”或“直接与最终用户合作”这类说法。Paraform 将 FDE 与最终用户之间的反馈闭环描述为面对面的。这些招聘启事隐含要求的，就是观察能力。

在简历或面试中，不要写“客户沟通能力强”。讲一个具体的过程：你观察了谁，观察了多久，发现了哪个非正式的变通做法，设计因此做了什么改变。

这样的故事能让招聘方看到，你能挖出真实需求，而不只是执行别人交给你的需求。

需求调研时画的四步图仍然有用：它是你的第一个假设。在 Lan 身边待一天，就是在代码进入生产环境接受检验之前，先检验这个假设。

**本周动手试试:**

- 申请在一位最终用户身边坐 2 小时，记一份 4 栏日志，在对方休息之前什么都不问
- 拿出最近一份需求调研文档里的流程描述，标出听起来“太顺”的步骤，然后请对方给出一个最近的具体例子
- 按“观察到什么、发现了什么、设计如何改变”的格式，重写简历中的一行

## 信源

- [Contextual Inquiry: Leave Your Office to Find Design Ideas (NN/g video)](https://www.nngroup.com/videos/contextual-inquiry/)

- [Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context](https://nngroup.com/articles/contextual-inquiry)

- [Contextual inquiry: A comprehensive guide (UserTesting)](https://www.usertesting.com/blog/contextual-inquiry)

- [Forward Deployed Engineering: Turning Customer Problems Into Working Products (AI Engineer knowledge library)](https://www.ai.engineer/topics/forward-deployed-engineering)

- [What is a forward deployed engineer? A complete guide](https://www.paraform.com/insights/what-is-a-forward-deployed-engineer)

- [What are Forward Deployed Engineers, and why are they so in demand?](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers)