FDE Times 数据在招 FDE 职位 863▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 71在招公司 181支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

分析

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

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

分享微博

要点速览

  • &above、Entrans 等公司把 FDE 当作服务出售:由它们雇用并管理工程师,再派驻到客户团队。
  • 厂商 FDE 的考核是帮助卖出软件、留住客户;外包 FDE 承诺的是,客户离开他们也能运行系统。
  • Gartner 和 Forrester 警告厂商锁定、权限过宽以及追求速度带来的盲区,这让交接能力成了求职市场上的优势。
三种 FDE 模式的对比表。厂商 FDE 由软件公司付钱,以留住客户衡量成功,风险是依赖厂商。FDE 即服务(高亮)由服务公司付钱,以客户拥有系统衡量成功,风险是外部人员掌握深度访问权限。人力外包由人力外包公司付钱,以计费工时衡量成功,风险是无人对部署全程负责。
同样的 FDE 头衔,付钱的人不同,成功标准几乎相反:外包 FDE 的成功,是客户不再需要他们。来源:文中引用的 &above、Entrans 和 Webfuse 的自我介绍。

英国公司 &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 即服务 服务公司 客户拥有并能扩展的可用系统 外部人员掌握深度访问权限
人力外包 人力外包公司 提供的工时 无人对部署负责

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

公司承诺交接,不等于交接就会发生。据 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 让客户不再需要自己。市场两种工程师都需要。

这篇文章对你有帮助吗?

6 个信源
路线图上的下一篇 · 阶段 1: 基础认知FDE 什么时候在筑护城河,什么时候只是在做咨询ServiceNow 和 Workday 上市时毛利偏低,后来都追了回来,关键看一线经验能否回流到产品。