被吹爆的FDE角色，正在掩盖AI产品的核心问题
本文来自WeChat公众号： ToB产品创新研习社 ，作者：大D
这两年，FDE（Forward Deployed Engineer，前沿部署工程师）越来越受到关注。
很多人把它看成AI产品GF入机构的关键角色：既懂代码，又懂业务; 既能和用户沟通，又能把操作系统真正部署到生产环境。
这个判断没有错。
但如果换一个角度看：
如果一个产品必须依赖大量FDE才能交付，它究竟是足够贴近客户，还是根本还没有成熟？
一、FDE解决了难题，也可能掩盖状况
FDE的价值，是GF入用户真实环境，把新品能力接入具体业务流程。
但它也可能掩盖新品本身的缺陷。
新品Endpoint不够标准，FDE来补;
统计结果模型不够清晰，FDE来解释;
Scopes体系不够完善，FDE来协调;
流程无法复用，FDE再写一套定制代码。
客户看到了结果，管理层看到了收入，团队看到了项目成功。
可是，原本应该被产品解决的问题，被一个人的能力暂时遮住了。
这就像给一栋没有完成设计的房子配了一位经验丰富的管家。管家确实可以让客人住得下去，但并不意味着房子的结构已经合理。
所以，FDE越能解决复杂问题，企业越要警惕：这些问题有没有被沉淀为产品能力，还是只被某几个工程师记在脑子里？
二、FDE越多，不一定代表交付能力越强
FDE模式最容易出现的误区是：第一个客户需要两个月，第二个用户也需要两个月，第三个顾客仍然需要两个月，于是企业开始招聘MoreFDE。
表面上，这是在扩大交付能力。
实际上，这是在扩大定制成本。
如果FDE班底随着客户数量线性增长，公司就没有获得真正的规模效应。收入增加了，人员花费也同步增加; 顾客增加了，系统复杂度也一起增加。
这时，机构已经从软件企业滑向了软件服务支持公司。
真正健康的曲线应该是：第一个客户依赖大量现场工程，后续用户逐渐转向配置、模板和标准连接器。
FDE的工作量应该回落，而不是不断增加。
判断FDE模式是否健康，不是看团队有多忙，而是看同类问题是否越来越不需要人工解决。
三、客户为什么会依赖FDE？
还有一个容易被忽略的状况：客户依赖FDE，究竟是因为业务复杂，还是因为产品不透明？
如果用户只有依赖某个工程师才能理解操作系统、配置规则和完成更新，那么FDE就可能变成新的锁定机制。
客户获得了短期结果，却GA去了长期自主权。
这对机构软件尤其危险。因为客户真正担心的，不只是产品能不能用，还包括人员变动后Draw台能不能继续运行，供应商更换后统计结果能不能迁移，定制逻辑能不能被审计。
优秀的FDE应该降低顾客对个人的依赖，而不是制造新的个人依赖。
每一次交付都应该留下文档、配置、测试用例、Scopes规则和可复用模块。否则，所谓“深度服务”很可能只是把操作系统知识藏在某个人身上。
四、FDE并不天然比新品更接近顾客
很多厂商认为，FDE到了客户现场，就能获得真实需求。
但现场距离近，不等于判断一定准确。
顾客提出的需求，可能只是某个部门的临时习惯; 客户要求的Features，可能是旧流程的补丁; 客户愿意为一次性定制付费，也不代表其他顾客会需要同样的能力。
如果FDE只是把客户说的话翻译成代码，他就不是产品发现者，而是高级需求外包人员。
FDE真正核心的能力，不是“顾客要什么就做什么”，而是能够区分三件事：
这是客户的特殊要求，还是行业共性状况？
这是流程本身的难题，还是新品能力不足？
这个需求应该做成代码、配置项，还是干脆不做？
没有产品判断力的FDE，越贴近客户，越容易把产品带向碎片化。
五、FDE的终点，可能是FDE越来越少
FDE最有意义的阶段，往往是产品还没有完全标准化，但又已经GF入复杂厂商场景的时候。
它可以帮助企业快速理解现场，跑通关键流程，发现新品缺口。
但它不应该永远停留在现场。
成熟的路径应该是：
第一步，FDE用工程方式解决客户问题;
第二步，把重复状况抽象成产品模块;
第三步，让实施和客户自己完成大部分部署;
第四步，FDE只处理真正复杂、高作用和高风险的场景。
换句话说，FDE的成功，不是让顾客离不开FDE，而是让顾客逐渐不需要FDE。
如果一家公司不断增加FDE，却没有降低定制化交付比例，那它并不是找到了AI产品化路径，而是在用人力延缓产品问题的爆发。
结语
FDE当然重要。
但它不是所有AI厂商都应该复制的组织答案，更不是“只要招到出色FDE，就能解决落地问题”的万能钥匙。
它更像一面镜子：照出用户环境的复杂，也照出商品本身的不成熟; 照出厂商真实的流程，也照出软件公司的抽象能力不足。
真正值得关注的，不是厂商有多少FDE，而是这些FDE每完成一个项目，商品是否因此变得更标准、更易用、更可复制。
FDE不是软件规模化的终点，而是软件从定制走向商品化时必须经过的一段路。
Generate poster / share QR code
