Palantir早期高管解释如何正确的践行FDE
AI智能体在企业侧落地的种种挑战，推动了近期Palantir的爆火，其“三板斧”之一的FDE（前端部署工程师）模式近期也被国内普遍关注。关于FDE模式究竟跟定制开发有何区别，市场也有不少的讨论。近期，在播客The LightCone上，Palantir早期高管Bob McGrew作为亲历者，分享了FDE模式的由来以及一些细节和关键点，可供参考。
Bob McGrew，曾任Paypal早期工程师，Plantir早期高管，OpenAI的首席研究官，现在在美国陆军任职。以下内容来源于播客上Bob McGrew发言的记录和总结整理。50分钟播客完整视频可以在B站找到：《FDE模式保姆级教程：前Palantir研发负责人谈FDE三大纪律八项注意》（具备中英文字幕）
要点：
1.FDE本质上是面对未知产品形态和个性化需求的不得已之法，如果能做成标准化产品规模化复 制，就没必要搞FDE。
2.FDE基于平台化产品+现场实施，由FDE工程师基于平台化产品，驻场进行定制化原型开发，FDE工程师追求快和定制，产品经理追求更高度的通用化。
3.Palantir非常强调真正解决了用户的核心问题，创造了核心用户价值，这些问题甚至可能用户自己不能清晰描述。
4.FDE驻场团队分为Echo团队和Delta团队，前者具备深厚行业经验，现场挖掘需求和协调，后者是软件工程师，负责快速做出原型
5.FDE模式虽然也是项目制，但在持续提升收益，一方面持续提高业务价值，合同金额持续提升，一方面通过提升产品标准化，提高项目利润。
具体内容：
FDE的由来
Shyam Sankar，Palantir的总裁兼CTO，首创了FDE模式。公司的客户需要的产品都有一些轻微的个性化差异，为一家客户打造产品，去找下一家客户时，发现他们的需求略有不同，但公司没有去为第二个客户开发一个全新的东西或者为第二个客户完全定制，而是构建了一个平台化的产品，在每个客户部署时有极强的可定制性。
当然这样也就需要派人去现场进行定制化的开发。这部分过去大家都认为属于服务，软件公司都希望尽可能减少，但Shyam认为可以反其道行之，从中挖掘出价值。他意识到需要FDE工程师来承担产品探索的职能，FDE工程师会去现场，弥合产品现有功能与用户实际需求之间的差距。之后产品团队根据各个项目情况，从中提取标准化产品的方向。
传统实施方法是从接近产品现有功能的地方起步，一旦攻克了首个难题，FDE就能在企业内部挖掘出其他关键痛点，这些问题有的时候价值比最初锁定的目标要更高。后面大家发现可能之前没有意识到，Palantir竟然也能解决这些问题。
FDE的运作模式
核心在于设立了2个关键角色，Echo团队和Delta团队。
Echo团队由驻场分析师组成，前往客户现场与客户交流，搞清楚什么样的Demo或者应用场景才是贴合用户需求的，才是能解决客户核心痛点的。同时，他们也担任客户经理的角色，在现场维护各方的关系。
Delta团队，本质上就是软件工程师，写代码速度快，能吃苦，把设想落地为现实可以运行的原型或解决方案，给客户演示。
所有这些需要在极短时间内完成。首先带着初步构思进入项目，制定计划在几个月后进行向领导层的演示，如果演示通过，正式着手部署，在全公司内推广。
Echo团队的画像通常是客户所在行业的专业人士，在行业内有深厚的领域专长，同时必须是“异端者”，即他们非常了解用户的现行运作模式，同时又能意识到其中的问题。如果他们意识不到当前的问题，也就没办法通过新软件实现效率的显著提升。
Delta团队，非常擅长开发快速原型，可以快速的写出一些粗糙的代码，而不是那种致力于开发出可以长期稳定十来年的软件的工匠型开发者。大概率他们写的代码后续会被推倒重来，或由其他人接手重写。
定制化的质疑
2.产品经理和FDE团队合作提炼通用产品
公司有产品经理的产品团队和FDE工程师团队，双方协作定义更高维度的产品。
产品经理的工作是定义产品的愿景，必须思考在客户现场发现新问题时，它的通用版本是什么，错误的做法则是直接把客户定制功能引入产品中。这里需要的是具备产品思维，从定制化功能中抽象出通用功能的人。
例如最开始跟军方合作时，如果考虑的是为人员、财务等创建对应的数据表，那这个数据结构最后变成了专用于这个行业的。Palantir的转变在于，将其提到更高的层级，不再去预设具体的对象类型，而是构建了本体论，由FDE工程师根据客户的需求进行定义。
早期开发的常见做法：首先FDE团队在客户处现场开发原型，观察效果，然后回来跟产品团队讨论，通用的产品功能是什么，然后再找其他几家客户，把这些客户的FDE工程师也找来协助设计这个通用功能，这样确保设计的功能即满足最初客户的需求，也适合其他客户。
FDE模式与传统定制模式的区别
FDE的实际运作机制、客户经营方式以及成果挖掘过程，与标准的软件公司截然不同，一个关键区别是，如何选择问题及为问题定价。FDE模式是在卖结果，你为客户解决了一个问题，需要为解决这个问题的价值定价。
传统PMF模式下，公司需要尽可能减少每个客户的人工投入，维持合同金额不变。FDE模式下，则是需要让合同金额变大，为客户做越来越有价值的事情，同时针对客户的定制化工作量可以保持不变。
FDE模式下，对产品的衡量标准也不同。一方面是交付的价值，持续交付有价值的成果，另一方面是越来越高的产品杠杆。具体是指，FDE工程师基于公司的产品定制具体功能交付用户，即产品本身通过FDE工程师进行了一次价值放大，产品的持续提升需要让这个价值放大的杠杆越来越大，例如面向类似的功能，FDE工程师所需的定制开发时间越来越短。
其他一些关键点
如果公司的业务可以不用密切与客户沟通个性化需求，只需要专注开发标准化产品并可以持续规模化，就可以继续，不需要FDE。只有其他模式不可行，才需要采用FDE模式。
跟客户做原型目标必须是解决领导层认定的TOP5的重要问题，否则项目大概率成不了，因为他们没有足够的动力坚持到困难的部分，也就是为他们量身开发的新产品模块。产品如果要本地化部署，涉及到本地的IT团队和IT系统，满足领导层的TOP5也是保证能够获得足够权限的基础。
完全按照客户需求做定制，并不一定能解决用户核心问题。你实际交流的是某个CEO以下层级的具体的人，他们更愿意让你解决一些从他们角度好解决的问题，而不是真正具备影响力，切实推动业务发展的核心难题。
做产品功能演示时，从我能做出什么，转到从用户的视角出发，好的演示是用户看完后很希望把它用起来， 这样才表明真正解决了客户的问题。
大客户们并不相信自己以及你们能解决问题，所以创业公司早期合理的策略是承担风险，见效或者等规模化应用时付费。
