首次发布于 2024 年 11 月，更新于 2026 年 3 月

Palantir 现在正当红。所以理所当然地，人们开始盲目模仿其文化中的元素，尤其是“前沿部署工程”。很多公司都在试图效仿这一模式，甚至有其他创始人来找我咨询，问他们是否也应该在自己的创业公司中采用这种模式。

对大多数人来说，答案很简单：“绝对不%#&行！”

只是因为听起来酷就给你的现场团队挂上一个头衔是一回事——真正建立一种“前沿部署”文化则是另一回事。如果不完全接受其收益和成本，这套模式就行不通；除非你愿意接受全部代价，否则你只是在做肤浅的模仿——不过是加了气泡的售前工程——不要指望能取得同样的成果。

我在“前沿部署”岗位上工作了将近 5 年（对外称为“部署策略师”，内部称为“Echo”）。我与一些才华横溢的工程师并肩工作，见证了这种模式最好的一面——以及最糟的一面。现在我在经营自己的软件业务（明确不做“FDE”），对这种模式的独特之处有了更深的体会。

最近有几篇不错的文章解释了 Palantir 的一些运作方式，包括Nabeel 的这篇精彩文章和Ted 这篇专门讲 FDE 的文章。但我想更进一步，专门谈谈为什么这种模式如此艰难，以及对大多数人来说为什么是个坏主意。

诞生于一线

“前沿部署”文化的核心是对现场团队的绝对尊重。他们被授权去做解决问题所需的任何事情，即使这与基础平台只有微弱的——甚至是勉强的——关联。这不仅限于配置或定制；如果这是赢得胜利所必需的，他们可以发明全新的产品和技术。

这就是 Foundry 的故事，也就是 Palantir 今天出售的企业平台。其核心元素最初是在相距遥远的地方开发的：苏黎世和休斯顿、圣保罗和图卢兹、韦斯特波特和巴库。它们因需求而生，因为小团队想要解决一个问题，而成本、兼容性或一致性只是次要的考量。1

客户部署是新技术的试验场——那些行之有效的技术会被迁移到核心并由开发团队接管，而 FDE 们则四散出击，寻找下一个前沿问题。这个开发周期快得惊人：当我被招募时，Foundry 还不存在；而 5 年后我离开时，它已经是一个完整的平台，推动公司走向 IPO。

而这一切完全是自下而上发生的。2014 年，在我们年度的“Hobbitcon”大会上，我们公开宣称的产品策略就是“强烈观点、弱化坚持”——基本上就是往墙上乱扔东西，看看什么能粘住。我们只是……在做东西，然后希望能拼凑出一个像样的业务。在当时，那简直是极度混乱、令人焦虑。我们这些行权价高于 4 美元的持股人都在想，自己到底被套得有多深。

但最终，有些东西开始粘住了。如今 Foundry 创造了数十亿美元的收入，被全球许多最重要的机构用来支撑决策（而且在我写这篇文章时，股价已经超过 146 美元！）

这听起来像是一个可以复制的成功故事——但这种方法不适合胆小的人，也不适合大多数初创公司。

研发 vs. 销货成本

在种种神秘化和溢美之词中，人们很容易忽视其中的权衡。真正做“前沿部署工程”伴随着高昂的代价，而几乎没有人真正愿意付出。

这种模式需要很高的招聘门槛和充裕的预算。在 Palantir，我们招聘的是顶尖的软件工程师——就是那种能去 Google、Facebook 或其他任何地方工作的人——来做 FDE，因为他们是去构建系统的，而不只是做些调整。而且我们需要的不仅仅是技术能力——前沿部署人员还需要创造力、判断力，以及面对客户的魅力。这比组建一支传统的“售前工程师”团队要昂贵和困难得多。

相互重叠和浪费的工作进一步推高了成本。我们经常有好几个团队在研究类似的问题，最终在分析、转换、可视化、编排等方面做出了多个产品，全都是 FDE 们在现有工具不够用的情况下构建的。而且失败很多——那些壮观的火葬堆，烧掉的是时间、金钱和差旅费，最后什么也没留下。我们在客户试点上烧掉了数百万美元；在很多情况下，利润率简直是负无穷，因为我们是在免费做项目。

如果用传统 SaaS 财务视角来看，这一切显得极其低效：你花钱让前 1% 的工程师满世界飞、构建定制软件，没有事前的变现策略，而且失败率很高。

但在真正的“FDE”文化中，你不会去计较花在特定客户身上的时间——那样就抓不住重点。单个部署的利润率可能很糟糕，因为这本质上是研发，而不是销货成本。客户实施主要是一个构建和学习的机会，而不是收割短期现金的途径。2 这是一种非常独特的资本配置视角，99% 的创始人和投资者都无法接受。

FDE，掌舵吧

除了财务成本之外，很少有公司愿意让自己的产品路线图完全服从于一线团队。

“FDE”模式依赖于"Auftragstaktik" 3（任务式指挥）的原则：高层领导只设定高层次目标，其余所有决策都交由前沿部署团队自行做出。这与大多数组织文化格格不入——在那些文化中，领导层制定自上而下的路线图和计划，偏离轨道则被视为异端。

这种自下而上、渐进演化的方式带来了惊人的创新速度。我们让百花齐放，最终收获了一束无法通过集中规划或执行造就的绚丽花束。

这往往带有达尔文主义的色彩：多个由 FDE 构建的解决方案相互竞争，看谁能被部署机队的其他部分采用。这感觉就像丛林战斗式的开发：代码为了解决某个特定客户的问题而写得又快又糙，而将其通用化所花的时间比构建 v0 还要长。过程很混乱。

当然，大多数组织的自然倾向是抵制这种变化，通过雇佣一层层的产品经理来实施流程，加以控制和约束，确保一切都符合季度路线图幻灯片第 71 页上的甘特图。

但要收获前沿部署工程的收益，你不仅要接受这种混乱，还要拥抱它。 你必须怀着对经验教训的感激之情看待那些重叠的工作、失败的项目（以及 FDE 们燃尽的躯壳）。这是“前沿部署”模式的核心，除非你愿意全身心投入，否则你并没有真正在做这件事。

我当时没有意识到的一点是，Palantir 的业务拓展与初创公司的风险投资模式有多少共同之处；大多数押注落空也没关系，只要命中的那些能带来丰厚回报。我们的客户试点就像一个个小型种子期初创公司：配备几名 FDE 和紧凑的时间表，然后被告知去撞穿高墙、把事情做成。大多数都没能成功——但成功的那几个创造了难以置信的价值。4

什么时候才真正适合全面采用“前沿部署工程”？

我认为需要具备几个条件：

  • 一个能够支撑极高定价的市场；如果你想把这作为长期模式，基本上必须瞄准财富 500 强规模的公司或大型政府机构。
  • 一种心态：承认你其实并不知道该构建什么，而是要通过与用户自下而上地探索来发现它。这在初创公司创始人中并不常见，他们通常对想构建什么有着强烈的愿景（或者说服自己有）。
  • 一个为可扩展性而设计的平台，以及在边缘开发与向核心迁移之间保持的纪律。

这些条件极其罕见，而且很难做到。5

我们在 Hex 做的事情

Hex 没有 FDE，这家公司的创始人和核心工程团队有很多前 Palantir 员工（更广为人知的称呼是“霍比特人”）。我们的开发团队有软件工程师和产品经理，客户团队则有解决方案工程师和产品专家。我们是一家 SaaS 公司，只销售一款产品——现场没有定制开发工作。

但我们开发这款产品的方式借鉴了在 Palantir 时期的许多经验。我们与客户和用户紧密合作开发新功能——进入承诺工程循环，让我们能够快速发现并构建正确的东西。这避免了“象牙塔”式开发——这种开发方式不幸非常普遍，也是大多数软件很糟糕的原因。

我鼓励任何正在构建新事物的人采用这种模式！去和客户坐在一起。感受他们的痛点。与他们一起构建。让用户引导你，并拥抱团队在过程中即时做出创造性决策。

只是不要把这等同于需要“前沿部署工程”，或者假装自己是某种你并不是的角色。

脚注

  • 这就是为什么 Palantir 一直是创始人的强大摇篮。直接与客户迭代、在有限资源下工作、在紧迫的时间线上构建，这些正是初创公司早期所需的技能。我们许多人接受了人们所能期望的最好的创始人教育，却完全没有意识到这一点。↩
  • 我怀疑这是判断谁在真正做前沿部署的主要“标志”之一——如果你的团队里有一群精打细算的人在为客户利润率操心，那你实际上做的是解决方案工程或专业服务，不如坦率承认这一点 ↩
  • Karp 博士总是能随口来一个冷门的德国哲学引用 ↩
  • Palantir BD 成为创始人工厂的又一个原因 ↩
  • 据我所知，真正在做这件事的只有 Distyl 的 Arjun。他曾是 FDE，也是一个特立独行者，有意识地消化真正前沿部署文化带来的所有痛苦和权衡。↩