FDE 团队怎么组建

汇报线、编制单位、考核口径与负载上限，四件事定下来，FDE 团队才不是「高级外包」的另一个名字。

多数公司组 FDE 团队的第一件事做错了：先招人。人招来塞进现有组织，半年后发现它变成了交付部——因为汇报线、编制单位、考核口径、负载上限这四条约束一条都没定。这篇讲这四条怎么定。

读完你能回答：

FDE 团队该挂在销售、交付还是产品下面，各自会把它变成什么
为什么「两个人一组」比「一个全能的人」更靠谱
一个人同时最多带几家客户，超了会发生什么

汇报线：挂错地方，角色就变了

挂销售下面，它会被赢单节奏吃掉，变成售前——因为季度末唯一被追问的问题是「这单能不能签」。挂交付下面，它会被工单和 SLA 吃掉，变成外包——因为唯一被追问的是「这个人这周在哪个现场」。要它反哺产品，就得让产品路线图的人对它负责，或者让它向产品/技术负责人汇报。

Palantir 早期之所以能成立，是因为 FDE 就是它的增长引擎本身，直接向创始团队汇报，不需要向任何销售配额让路。a16z 复盘时给的建议是同一条：把 FDE 当成产品的一部分来做，而不只是交付环节 a16z-palantirization。这条汇报线，就是把这句建议落到组织结构上。

编制单位：两个人一组，不要一个英雄

单人编制的失败模式很固定：这个人的技术能力被现场榨干，没有时间思考哪个东西该沉进平台，最后团队里只剩下一个个各自为战的独当一面者——能力留在人身上，不在系统里。

Palantir 的编制是配对的：Delta（前线部署工程师，负责把它做出来）加 Echo（部署战略师，负责定义使命、客户高层关系与采纳路径），背后接 Dev（平台工程）a16z-forward-deployed。分工的关键不在两个人各自做什么，在于其中一个人的 KPI 就是「这次学到的东西有没有回到平台」——如果两个人都在写代码救火，回流永远不会发生。

小团队没有两个人力可以配，也要保留这个「角色分工」：让工程师自己每周留出一段不可侵占的时间，把现场缺口写成产品需求或连接器。分工可以合并，职能不能消失。

考核口径：不背配额，那背什么

外部市场的口径很清楚：1000 条 FDE 岗位描述里，带销售配额的是 0% bloomberry-fde-jobs。但「不背配额」不等于「不背数字」。三条够用了：

复用资产数：每个项目至少留下一条能被下一家客户直接用的东西（连接器、模板、评估集、迁移脚本）。国内大厂公开的 FDE 招聘要求里就写着类似的一条。
激活与续约：接手的账户，30/90 天真实使用率有没有涨。这是上线不等于激活那条判断落到人头上的版本。
回流条数被采纳率：提给产品的问题里，有多少真的进了路线图。只数条数会催生垃圾需求，要看采纳。

不要考核「出差天数」「在场小时」——那正是把 FDE 变成外包的那把尺子。

负载上限：一个人都带活几家

FDE 的价值来自「吃透一个客户的多重问题」，而吃透需要连续的注意力。行业里常见的 pod 规模是十几个人量级，一个人同时服务两家是常态，第三家开始出现质量断崖：现场变成巡检，交付退回报工单。

定这个上限要按阶段：验证期的灯塔客户需要密集在场，一家都不能多；复制期可以把两到三家同构客户配给同一组人——前提是他们用的是同一份打法手册。判断依据不是人手，是「这个人的现场洞察有没有时间被写下来」。没有时间写下来，就是在烧掉你最贵的那份资产。

招人：三个可观察信号

三层能力（技术通才、翻译、主人翁）在三种能力，而非一种里拆过，这里只说怎么验：

给一段脏数据，看他问什么。 优秀的人会先问「这张表和哪个系统对账」「这个字段谁在维护」，而不是先讲模型选型。
要一个「他说服客户改流程」的例子。 只会接单执行的人，在客户现场会变成高级外包；讲得出他把客户从「他们以为要的」引导到「真正有用的」的人，才是这个岗位。
问他在没有产品底座时怎么做。 答「自己写脚本硬接」的，要确认他会不会把脚本沉淀下来；答「先界定范围、拒绝一部分」的，更可能守住边界。

学历、大厂年限、会不会调模型，都是弱信号。

三个问题自检

你的 FDE 向谁汇报？这个人的季度目标里，有没有一条是「产品因为现场变强了」。
最近一个项目结束，客户手上除了系统还留下了什么？团队手上有没有多一条能搬走的资产？
现有的人均客户数下，谁有时间把现场缺口写下来？如果答案是「没有人」，那你缺的不是编制，是回流机制。

代价照例说清楚：这套组织设计比「招两个能人」贵。配对编制意味着第一个项目你会觉得自己多养了一个人；复用资产考核意味着短期交付速度变慢；限制负载意味着你要拒掉一些本来能签的单。这三笔钱是买「可复制」的门票——不付，你就永远停留在靠英雄救火的规模，而英雄会离职。