FDE 模式：把工程师放到客户现场

FDE（Forward Deployed Engineer，前向部署工程师）这个词最近被用得很滥。很多人把它当成「驻场开发」的新说法，这两者的差别其实是本质性的。

三个区别

驻场外包按工时结算，FDE 按结果结算。 前者的交付物是代码量和在场天数，后者的交付物是一个跑起来的业务结果。这个差别决定了工程师在现场的行为方式完全不同。

驻场外包执行需求，FDE 定义需求。 客户说要什么就做什么，这是外包。FDE 的职责是先弄清楚客户真正的问题是什么——很多时候客户描述的解决方案，和他真正的问题之间隔了好几层。

驻场外包的经验留在个人身上，FDE 的经验要回流到产品。 这是最关键的一条。如果现场学到的东西没有变成可复用的交付包，那每个新客户都是从零开始，规模越大越累。

什么情况下 FDE 是必要的

不是所有项目都需要 FDE。我的判断标准有三条，满足两条以上才值得：

1. 需求无法在签约时确定 —— 客户说不清要什么，或者场景还在变化
2. 需要进入客户内部系统 —— 涉及数据、流程、权限，远程做不了
3. 第一个客户具有标杆意义 —— 这个项目做出来要能被复制给后面十个客户

如果需求清晰、可远程、且不是标杆客户，用常规项目制更划算，没必要付 FDE 的溢价。

一个常见误区

很多团队把 FDE 当成「销售支持」：工程师跟着销售去现场，演示产品、解答技术问题、把需求记回来。

这是把 FDE 用成了售前，非常浪费。

FDE 的核心产出应该是工作流的改造，不是需求文档。他在现场应该做的是：坐到业务人员的工位旁边，看他一天怎么工作，找出真正可以被自动化的环节，然后在现场把它做出来。

一个合格的 FDE，离开客户现场时留下的不应该是一份需求清单，而是一个正在被使用的东西。

对组织的要求

FDE 模式对组织的要求比看起来高：

• 招聘门槛高 —— 需要同时具备工程能力、业务理解能力和客户沟通能力，这种人本来就稀缺
• 考核方式不同 —— 考核工时和代码量会直接毁掉这个模式，必须考核业务结果
• 知识回流机制是硬成本 —— 需要有专人把现场经验沉淀成交付包，这部分投入容易被砍掉

砍掉知识回流，FDE 就退化成了高级外包。这是这个模式最常见的死法。