M0第 2 课 · FDE 与相邻岗位
M0-L2.4FDE 与解决方案架构师、售前工程师
一句话： 售前岗位要证明一个方案行得通，以便赢下订单，通常在成交后退出；FDE 要在合同签下之后，对让它在生产环境真正跑起来负责。
售前工程师（SE）和售前解决方案架构师（SA）是销售一侧的技术人员。他们做 demo、搭 PoC、回答安全问卷、画参考架构，说服客户的技术团队这个产品能胜任。他们的工作按订单是否成交来衡量。
FDE 的工作通常从他们结束的地方开始。合同签下后，必须有人把承诺变成一个系统：用客户的真实数据、在客户的真实权限下、为真实用户运行。这个人就是 FDE。
实践中边界是重叠的。FDE 常被拉进后期的销售中搭技术 PoC，有些 SE 签约后也会继续参与。判据仍然有用：这段代码是为了说服而写，还是为了运行而写？
FDE 为什么需要
Section titled “FDE 为什么需要”企业 AI 交付中最危险的缺口，就在销售过程中展示的东西和实际能交付的东西之间。FDE 要继承所有已经做出的承诺。了解售前岗位如何工作，能让你足够早地介入，把承诺控制在现实范围内。
| 售前工程师 / 售前 SA | FDE | |
|---|---|---|
| 目标 | 赢下订单 | 成交后让它起作用 |
| 代码 | demo 和 PoC 代码，常用样例数据 | 用客户数据的生产代码 |
| 时间跨度 | 几周，直到签约 | 几个月，贯穿上线、采用和移交 |
| 考核 | 赢单率、pipeline、订单规模 | 客户结果、采用率、续约和扩容 |
| 什么时候退出 | 通常在签约时 | 在移交时，即别人能运行它的时候 |
Demo 成功不等于可以上生产
Section titled “Demo 成功不等于可以上生产”用干净样例数据做的 PoC 回答的是”这件事到底能不能做”。它回答不了：在混乱的真实数据上、在客户的安全规定下、在他们的数据量下、面对并没有主动要求它的用户时，它是否还能用。把一次成功的 PoC 当成交付计划，是承诺跑在现实前面最常见的方式。
最好的团队在签约前就让 FDE 参与范围界定，这样验收标准和时间表能反映 FDE 在类似客户那里见过的情况。
- “FDE 就是写代码更多的售前工程师。” 区别在时间跨度和责任，而不是代码量。
- “PoC 成功意味着最难的部分已经完成。” 最难的部分（集成、权限、评测、采用）通常在它之后才开始。
- “FDE 不应该参与销售。” 很多 FDE 会参与，而这种参与是防止过度承诺的最好保障。
销售向客户承诺了一个产品没有的能力，你怎么办？
先弄清到底承诺了什么，以及背后客户真正需要什么。提出你能交付的最接近的版本，附上时间表和限制，在开工前和销售负责人、客户双方达成一致。然后把这个缺口作为证据反馈给产品团队。
PoC 非常完美，为什么上生产还可能失败？
PoC 很可能用的是干净数据、宽松权限、几个友好的用户，而且没有负载。生产环境带来的是脏数据、受限的访问、安全审查、真实的数据量，以及没参与决策的用户。
- 文章：What are Forward Deployed Engineers?（The Pragmatic Engineer，比较 FDE 与解决方案架构师、专业服务的部分）— 这些角色在哪里重叠、在哪里分开