FDE与售前、咨询、实施：怎样辨认责任边界

一家企业说要招聘FDE，可能想要一名能促成购买的技术顾问，也可能想要一名要对客户生产系统持续负责的工程师。同一个名称盖住不同任务，招聘、报价和验收就容易各说各话。

上一章追踪名称怎样出现。本章解决另一个问题：面对一份岗位说明或合作提案，怎样看出它实际承担什么，而不被名称带着走。

与售前、咨询和实施重叠在哪里

当名称逐渐流行，一个最直接的问题是：这不就是售前或实施吗？

这个问题有价值，因为它要求新名称说明自己的增量。但回答它时，不能先把已有职业缩成一个容易战胜的样子。美国劳工统计局对销售工程师的现行职业说明，不只列出演示和促成订单，也包括确认技术要求、安排安装、修改产品以适应客户，以及帮助处理问题；部分人员还会参与新产品研发。¹ 所以，“是否接触客户”“是否动手解决技术问题”，都不足以单独把 FDE 与销售工程划开。

咨询也不只有报告。Accenture 在 2018 年关于软件产品工程业务的公告中，已经把平台战略、设计与实施放在同一服务范围里。² 这是一家服务商对自己业务的说明，不代表每份咨询合同都包含工程工作；但它足以提醒我们，不宜用“咨询只提建议，FDE 才会建设”作为全行业定义。

实施同样可能深入真实工作。SAP 关于 Ariba 部署的公开课程，把需求与流程设计、数据准备、系统配置、生产迁移和上线后支持列为不同阶段的活动。³ 本书引用的是当前方法说明，不据此回写某个过去项目的实际过程。它说明的边界是：标准产品的实施，也可能要求技术、业务和组织共同参与，不能把它简单理解为点几下设置按钮。

既然这些工作广泛重叠，名字还有什么用？名字可以传达一个组织的侧重点，但判断具体岗位时，还须往下追一层。两个团队都可能写代码：一个主要为验证购买决定服务，另一个承担客户日常运行的结果；两个团队都可能实施系统：一个被要求尽量按成熟方法交付，另一个被允许把客户处发现的新问题带回产品开发。区分它们的，是责任和后续动作的组合。

这些组合也不必永远固定。售前工程师可能继续参与关键交付，实施团队可能形成可销售的行业产品，FDE 也可能被销售目标牵引。若把每个名称都规定成一套绝不重叠的行为，真实项目反而很难放进去。更实用的做法，是先看工作，再看组织怎样为这项工作命名。

这也是为什么本书使用“前线部署工程师”作为 FDE 的暂译，而不把“驻场”写进必要条件。Palantir 在 2020 年的一份员工访谈里，就记录了一位因疫情而全时远程工作的前线部署软件工程师。⁴ 现场既可以指物理地点，也可以指可接触真实数据、使用者和运行反馈的位置。每天坐在客户楼里，却只经层层转述接收要求，未必比能够直接验证问题的远程工程师更接近工作。

当然，远程也不是免费替代。能否看到实际过程、取得适当权限、及时找到责任人，都需要安排。这里的重点是把空间与责任分开：办公地点是一项条件，理解和改变真实工作的能力是另一项条件。前者有时帮助后者，却不能充当后者的证明。

换一组问题，差别就清楚了

可以用一个教学情境把这些差别放到同一张桌上。沿用序章那家希望缩短客户等待的教学维修企业：客户提交故障，技术人员需要找到对应型号、适用手册、零件库存和服务记录。下面的团队安排只是比较用的情境，不是某家企业的项目实录。

一种安排把任务限定为采购前验证。工程师取一小批经过允许的样本，证明产品能够检索到适用手册，列出接入现有系统的条件。它很好地回答了“这个产品是否值得继续评估”。只要双方知道验证范围，就没有必要把它伪装成已承担全天候维修业务的生产系统。

另一种安排以按约上线为中心。团队确认字段、迁移资料、配置权限、培训使用者，完成约定功能和验收。它的价值在于把已经相对清楚的需求变成稳定交付。如果需求发生重大变化，就要重新讨论范围、费用和时间。这样的范围管理可以保护质量，也能防止临时要求不断吞掉原来任务。

再一种安排仍然要交付，但同时承担探索：维修等待究竟主要来自找不到信息，还是零件缺货，或者批准替换部件的人不在？如果现场证据推翻最初判断，工程师有权和客户重新选择问题，并把反复出现的软件缺口带回产品团队。此时，发现需求本身也是工作的一部分，不能只用最初列出的功能是否逐项完成来评价。

三种安排都可以需要优秀工程师，也都可能在同一项目的不同时期出现。把第三种叫作 FDE，并不能证明前两种低级；企业最需要的，可能恰好是一次范围清楚的技术验证或成熟实施。这里的区别不在谁更努力，而在客户和供应商共同允许什么被重新判断。

第一件要问的是，团队对什么结果负责。是客户听懂方案，是一项约定功能交付，是持续运行，还是还包括共同产品的进步？“对客户成功负责”听起来宽广，却不足以安排工作。维修时间仍然很长时，团队必须知道自己需要继续查原因，还是已经到达需要另行协商的范围。

第二件要问的是，团队能改变什么。只能修改演示数据，能够配置系统，能够写入客户业务软件，还是也可以提交核心产品修改？责任超出权限时，工程师会不断把问题往别处转交；权限超出审查能力时，局部修复又可能影响更多用户。一个有用的岗位设计，需要使两者大致对得上。

第三件要问的是，新增知识去哪里。它留在个人笔记里，变成客户的操作办法，进入服务商的交付工具，还是改变软件平台？这些去向没有天然的高低，却对应不同的商业承诺。如果企业希望以后交付越来越容易，就要能够说明经验怎样离开原项目、被别人理解和使用；仅仅增加几个成功案例名称，还看不见这个过程。

第四件要问的是，意外由谁承担。探索产生的新发现会改变工期，客户流程变化会带来返工，进入生产后会出现维护任务。按工时收费、按项目收费、用产品收入支持前期投入，各自会使团队关注不同的风险。本书不把某一种计费方式规定为 FDE 的身份证。合同怎样划分责任、团队怎样实际工作，比账单上有没有“咨询”二字更有解释力。

用这四个问题观察，就不必急着给所有岗位排队。一个叫实施顾问的人，可能持续建设可复用软件；一个叫 FDE 的人，也可能大部分时间只做售前演示。前者不需要为了得到承认而改名，后者也不能仅凭名字自动获得产品工程的全部含义。

身份明确，与机制充分，是两条不同的轴

现在可以给材料做一张简短画像。它不评定谁更“正宗”，而是防止一种证据替另一种证据作答。

最后一行是材料类型说明，不是新案例。它提醒我们：名称是身份线索，实际改变是机制线索，采用与结果又是后续证据。三者需要分别找到。

比如，一份岗位说明承诺员工能够提出产品改动，可以确认公司期望的职责；只有看到提议、选择、实现和维护的记录，才能进一步分析一次真实回流。遇到缺口，先保留缺口，不能用一个流行职称自动补齐。

把称谓换成一份可核对的承诺

沿用维修企业的教学情境，负责人可以要求候选团队把四个问题写成同一张交付说明：要改善哪一步等待，允许改变哪些资料和软件，哪些问题能带回共同产品，出现新需求时谁决定增加投入。能写清这些，才有条件讨论该招谁、买什么。

如果提案只保证完成一次演示，就按技术验证的范围购买；如果标准产品的配置已经足够，就选择成熟实施；如果问题仍需共同发现，而且双方愿意承担真实工程与持续反馈，再考察FDE安排。这里没有一种永久优胜的岗位，只有更符合当下任务的责任组合。

具体组织方案在甲方选择与乙方经营中展开。接下来先看Palantir：当客户结果与共同产品由不同团队承担时，两者如何相互推动，也如何发生冲突。