# 数据指向流程负责人亲手设计的环节时

> 设计出问题审批环节的人，正是最需要一起修复它的人，开场白决定对方站在哪一边。

原文: https://fdetimes.net/zh/guides/telling-client-their-process-is-broken/

部署进行到第三周，你在日志上跑了一条查询，得到一个谁都不想听的结果：客户要你自动化处理的异常，大部分都源自运营负责人设计的一个审批环节。周一上午的进度会上，这个人就坐在你对面。

这里有两种出错的方式。话说得笨拙，你会失去客户组织内部最重要的盟友；闭口不提，你就会把一个有缺陷的流程自动化，错误发生得比以前更快。

介于两者之间的这项技能，和写代码相比听起来很“软”。但它常常决定一次部署是带来真正的改变，还是只留下一个没人打开的仪表盘。

## 客户让你治症状，你却看到了病因

GSDC Council 在描述前线部署工程师（FDE）常遇到的情况时，提到了一个熟悉的观点：客户要的解决方案，未必针对真正的问题。他们请你自动化某一个环节，但需要修的有时是它前面那一步。

为什么 FDE 往往比客户更早发现这一点？Vinoo Ganesh 在谈到 Kepler 如何做前线部署工程时认为，观察人们怎么工作所得到的证据，与问他们喜不喜欢某个功能所得到的证据，性质截然不同。

一篇对 Palantir 模式的分析显示，那里的 FDE 每周大部分工作时间，即 30–40 小时，都坐在分析师和操作人员身边，而且常常是在保密设施里。坐得这么近，纸面流程和真实流程在哪里分岔，一目了然。

这意味着你的发现来自真实的工作，而不是道听途说，但它仍然需要核实。难点在于，写下纸面流程的那个人至今仍相信它。

## 先讲事实，再讲解读

《关键对话》（*Crucial Conversations*）一书中的 STATE 方法给出了清晰的顺序：每一场敏感对话都应从可观察的事实开始；然后说出你的解读，但要把它当作一个可能出错的推测，而不是不容争辩的真相。

接下来，谦虚地询问对方怎么看，并明确表示你希望听到他们的观点，哪怕与你的完全不同。

这个顺序之所以有效，是因为事实很难反驳，而任何人都可以反驳一个结论。但前提是你的事实确实站得住。Quirk's 在一篇关于如何传达坏消息的指南中强调，任何坏消息都必须有可靠的数据支撑，而数据本身又必须建立在可靠的方法之上。

Quirk's 那篇文章还提到一个容易被忽略的观点：坏消息很少全是坏的，许多客户只需调整策略、发挥自身优势即可。所以在讲坏事实的同时，一定要说出哪些地方是有效的。

**要点:** 先把事实摆上桌，再说你怎么解读。

## 一场会议，逐句拆解

设想一家分销公司请你构建一个智能体，用来核对发票与采购订单（PO）。假设四周后，日志显示共有 1,200 张发票，其中 310 张进入了人工处理队列。

你逐张追查，发现这 310 张中有 248 张的 PO 是在货物已经到仓之后才创建的。因此智能体根本没有可以匹配的对象。

“先收货、后建 PO”这一步，是运营负责人为了加快交付而引入的。下面是一段可以直接使用的五句话脚本。

**陈述事实：**“过去四周，有 310 张发票需要人工处理。其中 248 张的 PO 是在收货之后才创建的。我带来了十张具体的发票，请您看一下。”

**说出有效之处：**“不过其余 890 张发票都自动匹配成功了，说明核对本身是有效的。”

**说出你的假设：**“PO 创建得晚，可能是人工处理的发票数量降不下来的主要原因。但我还不了解这一步当初为什么这样设计。”

**提问并请对方反驳：**“您怎么看这些数字？如果我理解错了，比如有些紧急订单必须这样处理，我非常希望知道。”

**提出小范围试行：**“如果您觉得合理，我们可以选一组供应商试行两周：在到货前先创建一张临时 PO。两周结束后，把这组供应商的人工发票数量和过去四周对比一下。”

注意，整段脚本里没有一句话在说“您的流程错了”。听的人要么自己得出这个结论，要么指出一个日志没有记录到的合理例外。无论哪种结果，对你都有利。

## 开会之前：假定一定会被质疑，再检查一遍

准备工作从方法开始，而不是从措辞开始。重新核对你的统计方式：时间窗口、时间戳来源、排除了哪些记录。流程负责人会攻击最薄弱的一环。

接着，挑几个案例亲自去现场看，正如 Ganesh 所说：观察工作能得到查询给不了的证据。十张真实的发票比一张图表更有说服力。

然后准备好一个行动方案。Natalie Meurer 在谈到前线部署工程的“肮脏秘密”时认为，一个有用的运营应用必须帮助人们依据数据采取行动，而不只是看数据。

在上面的例子里，这就是脚本的最后一句：为期两周、范围很窄的试行，结束时有一个可以对比的数字。

## 对话是怎么搞砸的

最常见的错误是一开口就抛结论。如果你的第一句话就是定论，对方会把整场会议都用来反驳，而不是和你一起看数字。

另一个陷阱是在赢得信任之前就开口。Ganesh 描述了 FDE 如何通过一个个成功的小修复来赢得信任，进而接触到更深层的问题。如果你在第一周就指出别人流程中的缺陷，就是在花一笔你还没挣到的资本。

也不要在对方上级面前突然抛出这个发现。先私下和流程负责人谈，让他们有机会反驳，并和你一起向上汇报。

最后，不要只带着一个仪表盘、却没有任何提议去开会。那样会议往往以点头告终，什么都不会改变。

## 求职时，把这项技能变成证据

准备 FDE 面试时，要准备好回答这样的问题：“讲一次你不得不告诉客户他们不想听的事情的经历。”好的回答有四个部分：你发现了什么数据、如何核实、说服了谁，以及随后带来了哪些可衡量的变化。

阅读岗位描述时，留意那些关于与客户利益相关方合作、理解其运营流程的内容。这个故事就该写在简历的这个位置，用数字说话，而不是用形容词。

本周练习：从你手上的项目中挑出最让人担心的那个数字，按上面的模板写一段五句话脚本。读给一位同事听，问他：哪一句听起来像指责？

流程负责人并不需要你证明他错了。他需要看到的是：和你一起修复流程，比继续为它辩护风险更小。

**本周动手试试:**

- 在当前部署中挑一个让人担心的数字，拉出背后的 10 条具体记录，亲自检查你的统计方法是否站得住。
- 提前写好对话的三句开场白：一句只讲事实，一句以“也许”开头的假设，一句询问流程负责人怎么看。
- 按这个模板在简历中加一行：你在数据中发现了什么、和谁达成了一致、流程如何改变，以及实测结果。

## 信源

- [Researchers, it's OK to give bad news (and here's how to do it)](https://www.quirks.com/articles/researchers-it-s-ok-to-give-bad-news-and-here-s-how-to-do-it)

- [Crucial Conversations' STATE Method: 5 Essential Skills](https://www.shortform.com/blog/crucial-conversations-state/)

- [Think Like a Forward Deployed Engineer: 5 Real-World Scenarios](https://www.gsdcouncil.org/blogs/think-like-a-forward-deployed-engineer-real-world-scenarios)

- [How Forward Deployed Engineering is done at Kepler (Vinoo Ganesh, AI Engineer World's Fair 2026)](https://ai.engineer/talks/1OMHGsUZiqA-forward-deployed-engineering-is-done-kepler)

- [Palantir's Forward-Deployed Engineering Playbook: The Original Model Anthropic and OpenAI Are Copying](https://getperspective.ai/blog/palantir-forward-deployed-engineering-playbook-anthropic-openai-copying)

- [The Dirty Secret of Forward Deployed Engineering (Natalie Meurer, AI Engineer World's Fair 2026)](https://www.ai.engineer/talks/Byv311hdoHE-dirty-secret-forward-deployed-engineering)