# FDE 成了外包生意，谁付钱谁定义这份工作

> &above、Entrans 等公司开始出租 FDE，同一头衔在不同付款方眼里，衡量标准几乎相反。

原文: https://fdetimes.net/zh/analysis/fde-as-a-service-vendor-vs-outsourced/

英国公司 &above 的服务页面用一句话概括了它的商业模式：由它雇用并管理工程师，这些工程师与你的团队一起构建系统。

这里出售的是前线部署工程师（FDE）。几年前，这个头衔几乎只属于 Palantir 等软件公司的员工。

乍一看，这不过是给外包换了个时髦的名字。但当 FDE 成为一条服务线，出现专门出租工程师的公司，“FDE 做什么”这个问题就取决于另一个问题：谁给 FDE 付钱？

对于有两到八年经验、想走这条职业道路的工程师来说，这个区别很重要。两份招聘启事可以用同一个头衔，但不同雇主会用几乎相反的标准来评判你。在一家雇主那里让你脱颖而出的能力，换一家可能一文不值。

## FDE 头衔不再专属于厂商

a16z 的 Tom Hollands 认为，在 Palantir，解决方案和集成工程一度被视为地位不高的工作，FDE 这个头衔提升了它的地位。一个有声望的职位头衔，迟早会被拿来出售。

如今，Accenture、McKinsey、Deloitte 等众多公司都在与 AI 实验室合作，运营、资助或培训 FDE 团队。

据一份 AI 通讯报道，OpenAI 和 Anthropic 最近几个月各自成立了 FDE 合资公司，AWS 也在投资一个 FDE 部门。

大公司之下，还有一层规模较小的公司，比如 &above 和 Entrans，把 FDE 作为独立服务出售。

SD Times 认为，FDE 是对传统顾问的补充而非替代，因为他们覆盖的正是顾问往往做不好的领域。它还指出，FDE 也可以是 Salesforce 这类技术厂商的直接员工。因此，单凭头衔已经看不出工程师在为谁工作。

## 谁付钱，决定你优化什么

Webfuse 在比较 FDE 和顾问时说，区别在于商业模式。FDE 为产品厂商工作，所以每一次部署都在帮厂商卖软件、留客户。

如果厂商 FDE 把系统做得好到客户不再需要这款产品，那他就是在跟自己的雇主作对。

外包 FDE 的激励恰好相反。&above 把自己的服务描述为：把资深工程师派驻到客户团队，负责一个划定范围的工作流，并承诺把能力转移给客户员工。它还承诺，到合作结束时，客户团队拥有这套系统，不靠 &above 也能继续扩展。

Entrans 把自己的服务与人力外包区分开。在它看来，FDE 即服务必须继续构建并部署解决方案，而不是止步于提供工时。这三种定义带来了三种截然不同的成功标准：

| 模式 | 谁付钱 | 成功的衡量标准 | 客户面临的主要风险 |
|---|---|---|---|
| 厂商 FDE | 软件公司 | 卖出软件，留住客户 | 依赖厂商 |
| FDE 即服务 | 服务公司 | 客户拥有并能扩展的可用系统 | 外部人员掌握深度访问权限 |
| 人力外包 | 人力外包公司 | 提供的工时 | 无人对部署负责 |

**要点:** 先问谁给 FDE 付钱，再问这个 FDE 有多好。

## “你们不会再需要我们”这个承诺站得住吗？

公司承诺交接，不等于交接就会发生。据 The Register 报道，Gartner 在 3 月发布的指南提醒买方警惕设计不当的 FDE 合作，这类合作可能让客户严重依赖厂商。

Forrester 6 月的报告也警告，对快速见效的追求很容易制造盲区，风险不小。

这是同一个问题的两面。FDE 推进得越快，系统知识就越集中在写代码的人脑子里，客户团队只是在旁边看着。

&above 承诺客户不靠它也能扩展系统，直接回应了 Gartner 所说的依赖问题。但只有把这个承诺变成可核查的交接成果，它才有价值。

设想一家保险公司雇了一支 FDE 团队，来自动化理赔分诊。

假如到了最后一天，内部团队从未独立部署过一次变更，从未独立处理过一次故障，也看不懂日志、找不出模型哪里出了错，那么无论代码运行得多好，这次合作制造的都是依赖。

一个实用的检验方法是：趁 FDE 还在现场，让客户团队新增一种理赔类型，但不许 FDE 碰键盘。

每一步都应由客户方的人签字确认，而不是由 FDE 自己标记完成。客户的技术负责人确认部署，运维值班工程师验收故障处理，工作流负责人签收最终测试。

## 访问权限：卖点还是风险？

一些服务商把工程师在客户 VPC 内工作作为安全卖点来宣传，因为数据从不离开公司的基础设施。Gartner 从相反的角度看待同一个细节：FDE 往往拥有全栈访问权限，既能进入客户环境，也能接触厂商的代码库。

两种看法都对，而化解这种矛盾的人通常就是 FDE。在 VPC 内工作能让数据留在一处，但也意味着一个不在客户工资单上的工程师，握着客户最关键系统的钥匙。

负责任的外包 FDE 会把访问权限当作交接计划的一部分。

从第一周起，他们就记录自己获得了哪些权限、为什么需要、哪天归还，并请客户的安全团队审批这份清单。

对客户来说，这份清单比服务页面上的任何文案都更有说服力。

## 如果你想走这条路入行

如果你的目标是出租 FDE 的公司，要清楚自己被雇来做什么。在这种模式下，产品是你离开后留给客户的能力，而不是你亲手构建的东西。

看双方如何描述自己，就足以区分。&above 写的是“资深工程师派驻到你的团队，负责一个划定范围的工作流”，目标是让客户团队拥有系统。Webfuse 描述的厂商 FDE 目标完全不同：通过部署帮助卖出和留住软件。

读招聘启事时，看它偏向哪一边。“scoped workflow”“capability transfer”“embedded with client team”这类说法，意味着你会按交接情况接受考核。如果启事只谈工时、到岗时间和技术栈，那多半是换了头衔的人力外包。

简历上写“构建了一条文档分类数据管道”，只讲了一半。把另一半补上：客户团队有多少人接手了这项工作，你走后他们自己又做成了什么。

运行手册、与客户工程师的结对编程，以及一次你主动撤销自己权限的经历，都是申请这类岗位时可以拿出的证据。

在厂商那里，好的 FDE 让客户舍不得离开产品；在出租 FDE 的公司，好的 FDE 让客户不再需要自己。市场两种工程师都需要。

**本周动手试试:**

- 挑一个你部署过的项目，按这个公式改写一行简历：具体的工作流、交接给了谁、客户团队之后自己做成了什么。
- 读三份在招的 FDE 招聘启事，记下雇主是厂商、服务公司还是咨询公司，并写出每份启事隐含的成功标准。
- 针对你目前负责的系统，列出你持有的每一项访问权限，并写一份在交接当天撤销它们的计划。

## 信源

- [Forward Deployed Engineers as a Service | &above](https://www.andabove.com/services/forward-deployed-engineers.md)

- [FDE as a Service Providers (Entrans)](https://www.entrans.ai/blog/fde-as-a-service-providers)

- [Forward Deployed Engineer vs Technical Consultant (Webfuse)](https://www.webfuse.com/blog/forward-deployed-engineer-vs-technical-consultant)

- [Forward-Deployed Engineers vs. Implementation Consultants: The Crucial Distinctions](https://sdtimes.com/software-engineering/forward-deployed-engineers-vs-implementation-consultants-the-crucial-distinctions/)

- [Palantir's fondness for French food cooked up tech's latest fad – forward-deployed engineers](https://www.theregister.com/a/5300360)

- [AWS Bets $1 Billion to Embed Engineers Inside Customers as Amazon Joins OpenAI and Anthropic in Forward Deployed AI Race](https://www.inbenta.com/ai-this-week/aws-bets-1-billion-to-embed-engineers-inside-customers-as-amazon-joins-openai-and-anthropic-in-forward-deployed-ai-race)