各公司是如何构建并扩展 FDE 测试平台的

我们交谈过的许多领导者都希望拥有一个前置部署工程团队，但却很少有人知道该如何构建这样的团队。这一职位处于软件工程、产品开发与咨询服务之间的交叉点上，能够胜任此工作的人既稀缺又昂贵，而且很难招聘到。本系列的第一篇文章已经介绍了什么是前置部署工程团队以及为何要建立这样的团队。随后读者最常提出的问题是：什么样的人才能成为优秀的前置部署工程专家？又该如何寻找、聘用并留住他们？在这篇文章中，我们将把这一人才难题提交给四位目前正在招聘和留住这类工程师的领导者们，让他们来谈谈自己的看法。

本文来自“Onsite Hour”系列活动，这是一档专为被投企业打造的每周线上活动，由 Insight 的 100 多位内部专家共同策划。本篇博客是关于如何构建 FDE 动作的三部分系列文章中的第二篇。

此次讨论由总经理普拉文·阿基拉朱主持。

与会嘉宾包括：

• ServiceNow 应用人工智能前沿部署工程组副总裁米库·贾
• Databricks*的前沿部署工程团队负责人马塞洛·佩德森
• Workato 人工智能产品负责人巴斯卡·罗伊*
• Wonderful*公司前沿部署工程部门负责人博阿斯·弗朗西斯

给创始人及 CEO 的六项建议

1. 要寻找那些能带来突破的人。先挑选出那些能够带来成果的人，再教他们所需的技能。弗朗西斯会通过考验候选人的解决方案，来看他们是否能够激发创造力，而非陷入僵局。
2. 应部署多个工作单元，而非依赖某个所谓的“核心人物”。不必苦苦寻找那种难得的完美人才。可以指定一名 FDE 作为负责人和协调者，再根据实际需求，安排数据科学、数据工程、领域专家，甚至是系统集成专家等人围绕其开展工作。“永远都是多个工作单元共同协作，绝不是由某一个 FDE 单独完成工作。”Jha 这样说道。
3. 将团队纳入产品体系之中，从而形成闭环。由该团队来决定自身的激励机制。ServiceNow 和 Workato 都将各自的 FDE 团队部署在产品与研发部门，这样一线的反馈就能为产品发展路线图提供依据。正如 Jha 所说，如果不能将这些反馈信息传回上层，那就“只完成了工作的一半”。无论团队身处何处，都应刻意构建这样的闭环。
4. 以较高的基本工资为基础，并结合相关基准标准来确定薪酬。由于可参照的市场范围有限，因此需要将软件工程、产品管理以及咨询领域的薪酬标准综合起来作为依据来设定薪酬。基本工资部分应设定得较高一些。
5. 防止工程师出现职业倦怠。如果工程师始终充当顾客与产品之间的桥梁，他们就会选择离开。要让工作保持活力，就要让工程师能够直接接触产品本身，同时还要让他们在 FDE 团队、产品团队以及工程团队之间轮换工作。
6. 要构建经久耐用的体系。不要把团队视为临时性的过渡手段，直到顾客完全采用人工智能技术为止。随着技术边界不断向前推进，这些岗位的职责形态也会持续变化，但有一个需求却是永恒不变的——那就是需要有人来填补强大技术能力与实际业务成果之间的差距。

什么造就了一个出色的 FDE？

让四位领导者描述理想的 FDE，你会得到关于同一个人的四种不同表述。

贾是 ServiceNow 的 Applied AI FDE 团队从零开始搭建的人，她将这一职位称为“T 型角色”。作为全栈 AI/ML 工程师所具备的深厚专业技能构成了垂直的一竖，而与业务相关的能力则横跨在顶部——包括将客户的需求转化为可衡量的成果、与企业高层合作，以及在不同阶段陪伴顾客共同推进他们的 AI 应用进程。“AI/ML 技术属于硬技能，”她说，“但这些业务方面的能力同样也是硬技能，正是这一点让这个职位如此与众不同。”

“你怎么知道你遇到了 FDE？就是这股火花。”

弗朗西斯用三个词来形容这种人：“一心只追求结果的工程师”。他在面试时，会故意破坏候选人的解决方案，以此来判断对方是否属于这类人。“你怎么知道面前的人就是那种 FDE 呢？就在于是否有这种闪光点。真正合适的人会展现出活力，而不会变得沉默寡言。”

佩德森在寻找那种“从结果出发、反向推导技术方案，并能快速加以验证的构建者”。但他同时指出：“同样重要的是，我们要与顾客一起构建解决方案，而非仅仅为他们工作。我们的最终目标是帮助他们培养在平台上独立取得成功的能力，而不是让他们过度依赖我们的团队。”

在每一种角色定位的背后，都存在着创业者的思维方式。贾哈指出，顾客们很少能明确地阐述自己的问题。他们拥有强大的新能力，时间也相对有限，但却没有明确的计划。因此，FDE 必须能够在这种不确定性中依然出色地工作，并全程负责把控结果。弗朗西斯在招聘时也会着重考虑这一点。在 Wonderful 公司的新员工中，每六到七人中就有一人是曾经的创业者。“那些能够白手起家创立公司的人”，他说，“担任 FDE 职务也会表现得很出色。”

你需要雇用独角兽吗？

小组一致认为，服务的交付单位应该是团队，而非个人。ServiceNow 会针对每一项问题组建一个团队——包括产品、工作流程及业务领域的专家，必要时还会加入系统集成专家——由一名 FDE 担任该团队的负责人并负责协调各项工作。由于所处理的领域会不断变化，因此这个团队也会相应调整组成，但那位负责人能够“确保整个过程的连贯性”。

有趣的是，各方在谁应该拥有账户所有权这个问题上存在分歧。在 Workato，Roy 对企业客户也采用同样的团队模式，但他让客户成功经理担任账户所有者，因为不同项目所需的 FDE 技能组合各不相同。而 Wonderful 和 Databricks 则将这项职责分派给两个人，由一名 FDE 与一名“部署策略师”共同负责。在他们的模式中，FDE 扮演 CTO 的角色，而策略师则担任 CEO，负责制定战略以及管理客户关系。

四支团队是如何运行 FDE 模型的

以下是各位专家团队在决定 FDE 测试台标准的相关事项上的对比情况。

ServiceNow 将这一角色定义为“T 型结构”：即拥有扎实的 AI/ML 工程能力作为核心，同时在之上具备出色的业务技能。该团队负责产品开发与研发工作，不负责市场推广任务；他们采用小组制进行工作，由 FDE 来负责问题的统筹与管理。这类人才均来自 AI/ML 工程领域的顶尖人才梯队。成功的标准是能够实现从“启动阶段”到“扩展阶段”的过渡，并产出可商业化的产品。其薪酬水平则与工程领域的最高层级相匹配。

Databricks 希望候选人具备三项核心技能：产品管理经验、实际的软件工程能力，以及面向客户的经验。该团队与产品紧密相关，工程师们会在 FDE 团队与产品团队之间来回调动。佩德森采用“两人一组”的工作模式，让一名 FDE 工程师与一名部署策略专家搭档，同时根据需求再配备全栈开发、数据工程和数据科学方面的专家。成功的标准是所带来的业务价值以及平台的使用率。该公司的薪酬结构中，软件工程技能占约 40%，产品管理能力和咨询能力则占其余比例。

Workato 从那些已有顾问负责服务顾客的系统集成商处获取资源，同时通过与各大学的合作招募毕业生，以便从一开始就对他们进行培养。FDE 们隶属于产品团队，而一线工作成果则会被用于制定平台的开发规划。对于企业客户，由 CSM 负责该客户的全部事务，而 FDE 的职责则会根据不同项目有所变化。这项工作融合了工程、产品设计以及咨询等多个方面，其成功与否则以产品的采用率和使用量增长作为衡量标准。

在这四家机构中，Wonderful 处于发展最早阶段。它竭力招募各类人才：包括前创始人（约占招聘人数的六分之一到七分之一）、那些不符合传统标准的科技行业工程师，以及来自顶尖咨询公司的优秀人才。该组织的结构十分灵活——“每次项目启动都相当于一家新创企业”——FDE 角色会与项目策略师搭档共事，这一安排类似于 CTO 与 CEO 的分工模式。其薪酬水平极具竞争力，会参照前创始人、科技行业巨头以及顶尖咨询公司的薪酬标准来设定。成功的标准则是为客户创造的价值，以及 FDE 个人的成长情况。

FDE 团队应该向谁汇报？

“FDE 属于你们的市场推广策略的一部分，还是属于产品与研发工作的一部分？”贾哈问道。他认为 ServiceNow 的团队显然更属于产品与研发领域。出于同样的原因，罗伊也将 Workato 的 FDE 视为产品团队的一部分——因为它们与产品发展路线图紧密相关。这样的架构能够形成良性循环：当某个 FDE 解决了该领域的某个新问题后，这些成果又会反馈到平台上，从而使后续的客户能够获得更大的优势。

“FDE 是您市场推广策略的组成部分，还是属于产品与研发领域的内容？”

对于 FDE 团队应该向哪个部门汇报，并没有统一的答案。佩德森领导的数据砖团队选择以人才与产品作为交换方式，而非隶属于某个特定部门。在市场上，FDE 团队也常常驻扎在市场推广部门和服务部门中。“这是一个重要的决定，”贾哈说，每位领导者都必须慎重做出这一抉择。

FDE 如何与销售团队协作？

FDE 团队负责处理那些由销售团队重点管理的客户关系，因此该团队会持续关注这些关系的发展状况。佩德森认为这是一种合理的分工方式：当销售人员建立起良好的客户关系并处理好相关事务后，FDE 团队便介入，共同为客户创造价值。他的团队与销售团队共享 Slack 频道，并且每周五都会为客户进行产品演示。“我们只专注于交付成果以及为客户提供支持，”他说，“我们的任务就是尽快向客户证明我们平台的价值，确保他们知道如何在我们平台上取得成功。”

罗伊从结构上消除了各种摩擦因素。在消费平台上，每使用一次 FDE 功能，都会增加账户的价值，同时也会提升客户经理的收益，因此两者是相互促进的。贾哈表示，如果处理得当，这种关系将会是互惠互利的。FDE 还能帮助客户开拓他们之前未曾考虑过的业务领域，从而为下一次续订奠定基础。

如何保持 FDE？

贾哈警告说，让 FDE 人员沦为“客户与产品之间的固定纽带”，或者更糟糕的是，变成一个在各个项目之间来回切换、最终精疲力尽的“面向客户的程序员”，才是导致其失去价值的最快方式。她的解决办法是让工作具有“累积效应”——每一次任务都应让工程师在产品中留下自己的痕迹。正因如此，在她所领导的团队中，产品本身的质量与客户满意度同样重要。

其他领导者则通过引导员工履行各项职责来重新定义这些角色。在 Databricks，佩德森表示，每项任务的意义就在于“让自己不再需要那份工作”。他们通过提升客户团队的技能，将当下新兴的技术整合到核心平台中，从而实现这一目标。通过让工程师在 FDE 团队与产品研发团队之间轮换，他们能够将现场积累的经验转化为平台的固有功能，进而帮助客户更成功地使用该平台。

罗伊通过组建高效的团队，逐步晋升为“架构师”级别的 FDE。而弗朗西斯则让员工按照自己的节奏成长：那些一起开始工作的初创团队，六个月后就已经各不相同了，“因为我们希望每个人都能做自己最擅长的事。”

对于没有薪资参考标准的职位，该如何支付报酬？

目前还没有可作比较的标准化市场标准，因此这些负责人自行制定了相应的标准。佩德森从软件工程、产品管理以及技术咨询这几个方面来进行评估，其中软件工程所占的权重为 40%，这一比例低于其团队最初假设的 70%，因为这个职位并非纯粹的工程类岗位。罗伊也对这个职位有类似的看法。贾的团队负责产品和研发工作，他们将标准设定在工程领域的最高水平，以此吸引“最优秀的、具备人工智能相关背景的人才”。弗朗西斯指出，真正针对 FDE 职位的评估标准直到现在才刚刚出现。

最重要的教训与结构有关。企业的业绩需要时间才能体现，而且常常会因为 FDE 无法控制的因素而进展受阻。将薪酬与短期绩效挂钩，会让工程师们为并非自己造成的延误而承担惩罚。

关于 FDE 测试台的常见误解

专家组希望澄清的几件事。

• “你得雇佣‘独角兽’来处理这件事。”交付单位是一个个小组，由 FDE 负责整体协调工作，而各领域的专家则根据需要轮流参与处理任务。
• “FDE 其实不过是收费较高的咨询师或销售工程师罢了。咨询师会按照既定的时间与工作量来完成任务；而销售工程师则通过制作演示来促成交易。FDE 则负责实现没有明确限制的目标，并将自己所创造的内容反馈到产品中。”
• “应该按照高级软件工程师的标准来支付他们的薪酬。”其实并没有什么合适的参照标准。领导者需要同时具备软件工程、产品管理以及咨询方面的能力。由于企业的发展往往会受到那些超出 FDE 控制范围的因素影响，因此必须以精益理念作为基础。
• “这是一种用于市场推广的附加工具。”这些企业中的大多数都将相关团队设在产品与研发部门，因此来自一线的实际反馈会被纳入产品发展规划中。而该团队向何处汇报，则是一个至关重要的决定，它会影响后续的所有工作。
• “随着客户逐渐转向使用基于 AI 的技术，这类角色将会消失。”FDE 这一概念出现于当前 AI 浪潮之前，24 个月内其规模就增长了约 40 倍。虽然其形态不断变化，但缩小强大技术能力与实际业务成果之间的差距这一需求却始终存在。

整体格局

阿基拉朱最后提出了一个重要问题：随着客户和集成商越来越习惯使用基于人工智能的技术，FDE 这一概念还会存在吗？

弗朗西斯则持相反观点。这种职业早在当前的人工智能浪潮出现之前就已存在，而且很可能会比传统的软件工程师这一职业存在更久。“那些能够主动应对各种挑战的工程师，才是未来的核心力量，”他说。贾哈也认同这种职业会持续存在，但其形态会不断变化；她指出，在 24 个月内，这类工程师的数量增长了约 40 倍。即便是在完全依赖人工智能的企业中，依然需要有人来处理杂乱的数据、协调分布式系统，并应对各种监管要求，因为技术正在朝着她所说的“智能代理经济”方向发展。

佩德森提出了长远的观点。他在 2009 年时在 Google 的职位是“部署工程师”，而他的目标一直都是设法让自己不再需要从事这份工作。不过“只要还有大型计算机存在，我们就还得继续做这项工作”。罗伊则从客户的角度来阐述这个问题：虽然职位会不断变化，但“客户始终希望看到实际的工作成果”。

那些需要被派往前方工作的工程师很难找到，他们的薪酬也难以确定，而且留住他们也很困难。但正因这项工作依赖于那项无法被自动化替代的要素——即能够将业务问题转化为实际解决方案，并且还能与客户保持良好沟通的人，所以它或许才是人工智能时代最稳定的职业类型。