FDE 学习笔记(一)

2005 年就有 FDE 这个概念，为什么直到近几年才火起来？本质在于 AI 的出现大幅降低四个板块的成本，既知识蒸馏的成本，定制开发的成本（这个我们在 vibe coding 上见了很多了），以及跨职能协作的成本，和最重要的，快速试错的成本。

AI 作为新工具，既降本，也在这几个板块有更多的延展增长机会。业务上存在的问题始终存在，但存在一个成本更低效率更高的解法，大家的关注度自然就比较高。

如果把一次项目交付定义为一场战役的话，FDE 的工作代表了两个角色。第一个是侦察兵，核心任务是前置到一线用工程手段解决问题。这也是大部分传统软件行业使用的交付方式。

第二个是教官，核心是将一线实践反哺为可复用能力。短期要结果侦察兵更重要，长期要利润要标准化复制，教官更重要。在FDE 的工作中，这两个工作的比例是各占 50%。

而在我们日常的工作里，前者要占 90%，后者，也就是类似沉淀和凝聚共识的工作，只占 10%。这就导致了项目跟着人走的问题。

这个人指的就是项目经理这个角色。项目经理在项目就做得好，团队表现好，客户认可度高，换一个项目经理就不行。人走带着沉淀和解决方案走，公司本身没留下足够多的积累。从这个层面讲，FDE的路径和机制具备一定的优越性。

FDE 的交付侧，和我们日常的项目管理在逻辑上非常相似。三步走，读现场，组方案，和验证交付。交付上很相似，比如我们项目跑 abtest，FDE 是跑冻结样本集，名不一样，但底层验证逻辑一致。

但，这三步除了有交付的要求，同时也有沉淀的要求。这和传统项目管理区别就比较大了。比如第一步的读懂现场，除了在交付上要了解真实业务场景和约束，更重要的是沉淀知识图谱和术语库。

可以以此倒推出来FDE 发展的核心命题：既 FDE 沉淀的能力必须是通用的，完成的能力不能仅仅是一个客户的“私有配置”。一定要完成“从特殊中抽象一般”这件事情，才算是合格的 FDE工作。

如何在量化层面的识别这件事情呢？那就是去看在 FDE 交付过程里，“单位价值对应的现场投入是否在持续下降”。也很好理解，随着同类目不同客户在业务需求上交集标准化板块的覆盖提升，成本一定会呈现一个坡度下滑的趋势。

所以在给 FDE 团队定指标的时候，除了常规的开发的指标，比如交付周期，交付人天，Bug 率，客户满意度之外，也会有一些沉淀型指标。比如能力沉淀情况，复用率，以及知识可交接性。

只是按照行业惯例，这种较难量化且规律明确的指标很容易在执行过程中被弱化或者变形，这就需要负责人在刚开始进项目的时候想的清楚，把这块当做和交付完全重要性的板块来拎，否则一定会走歪。

而FDE 到底放在哪个团队，实际考量也不同，如果放在交付团队，交付上一定有保障，但是交付团队每天炮火连天的在赶进度打仗，那么必然在沉淀上会弱些。如果放在产品团队，因为产品天然在场属性会弱一些，很容易输出“在办公桌想出来的产品”。

那么能不能双线汇报呢，也许更加复杂。腾讯那边给的一个解法是，就把 FDE 团队独立为一个团队，直线领导，给明确的交付+沉淀双指标即可，由最大的负责人直接带。看，这是不是和当时私域刚发展的时候一样？新鲜事物或者工具出来之后，只有最大的负责人比如 ceo才能站到全局战略去思考，去定位，且有耐心。外挂到其他部门，很容易变成部门完成指标的助力器，但团队本身的新鲜能力和该走的正确路径却被影响了。

当然 FDE 里也有不同的角色，Echo 和 Delta（Dev 这里不展开）。Echo 是脑，判断干什么，干哪个。比如识别需求，判断路径，最重要的是做决策。这要求比较强的判断力和领域理解力。Delata 是手，更多是写代码，配系统，调接口，跑测试，把 Echo 提出来的方案变成可落地运行的东西。这块要求的更多的就是执行力+工程能力。

大部分一人公司，负责人同时兼具了这两种身份，要不就是策略占长，通过自然语言让 ai 做系统，要不就是落地厉害，更多让 AI 作为外脑支持策略。只是大部分成熟的FDE 团队这两个角色还是有独立分割的，毕竟在两个不同方向上的长板选手还是没有那么多的。