# 一本从未提到FDE、却讲清FDE工作的书

> 《Team Topologies》里的赋能型团队几乎就是FDE的翻版，但Docker坦言首次照书改组并未降低认知负荷。

原文: https://fdetimes.net/zh/books-courses/team-topologies-fde-teams/

Docker 写过一篇文章，介绍他们如何按照 Team Topologies 重组工程团队。文中有一句企业博客里很少见的话：第一次尝试没能降低认知负荷，他们只好重来。

这个细节比任何赞誉都更有分量。Matthew Skelton 和 Manuel Pais 的这本书不是一用就灵的配方，而是一套词汇，用来描述每个团队处在什么位置、团队之间如何接触。

对前线部署工程师（FDE）来说，需要的正是这套词汇。FDE 夹在客户、销售和产品团队之间，一线需求一旦卡在三方之间，就得讲清楚：谁做什么，做多久，什么时候结束。

## 读哪个版本，按什么顺序读？

第一版 *Team Topologies: Organizing Business and Technology Teams for Fast Flow* 由 IT Revolution Press 于 2019 年 9 月 7 日出版，共 240 页。整套方法围绕四种基本团队类型和三种团队交互模式展开。

第二版于 2025 年 9 月 23 日出版，共 304 页，副标题改为 *Organizing Business and Technology for Fast Flow of Value*。出版方把团队视为交付价值的基本单元，仍称这本书是 IT 与知识工作组织设计领域的一大进步。

建议的阅读顺序：先读 teamtopologies.com 上的 Key Concepts 页面，篇幅短，所有定义都在里面；再读第二版；最后把书和 PostHog 公开的 FDE 手册放在一起对照，看一家真实公司把 FDE 团队放在哪里。

## 观点一：过载的团队会做出糟糕的决策

书中认为，拆分团队的首要原因是认知负荷。Key Concepts 页面说得很到位：CPU 过载，电脑就会变慢；团队过载，就会决策失误、行动迟缓。

设想一个四人的 FDE 团队服务六个客户，每个客户的技术栈各不相同。一线的每个临时修补，从此都成了团队必须记在脑子里的东西。到第七个客户时，团队缺的不是技能，而是脑子里已经没有空间了。

到客户现场后要做的第一件事：列出团队独自扛着的所有东西，比如连接器、脚本和定制配置。这份清单会告诉你，哪些工作需要推给别的团队。

## 观点二：叫对团队类型

书中的四种团队类型里，有三种与 FDE 的日常工作直接相关；第四种读 Key Concepts 页面时自然会看到。

流对齐团队跟随一条工作流，通常在一个业务领域内，产品团队一般就属于这一类。平台团队构建服务，吸收一部分复杂性，帮助流对齐团队跑得更快。

对 FDE 最重要的是赋能型团队：帮助流对齐团队克服障碍，同时发现缺失的能力。这个角色与 PostHog 对其 FDE 团队的描述非常接近。

PostHog 的 FDE 团队处在客户、销售、客户成功（CS）和产品工程之间，不负责产品方向，而是通过产品工程团队，把从客户那里得到的真实经验带回产品。

Rocketlane 描述的是另一种模式：把 FDE 职能放在产品和研发部门，而不是市场销售体系（go-to-market）。没有哪种安排适合所有公司。你要做的是弄清自己的团队采用哪种模式，只有这样，才知道客户需求会流向哪里、由谁拍板。

## 观点三：选对交互模式，并定好结束日期

书中提出三种交互模式：协作、X 即服务（X-as-a-Service）和促进。协作的定义是两个团队*在限定时间内*共同工作，去发现新东西，比如一个 API、一种实践或一项技术。X 即服务是指一个团队提供某样东西，另一个团队以服务的方式使用它。

对 FDE 来说，促进是指帮助产品团队理解一线的问题，让他们自己去构建，而不是替他们写功能。

设想一家银行客户需要通过一个陌生的身份提供方实现单点登录（SSO）。头三周，FDE 和平台团队协作，找出合适的 API。此后由平台团队以服务形式提供，FDE 直接使用即可。

如果这次协作没有结束日期，平台团队就会被卷进每一个客户，认知负荷也会蔓延到两个团队。

**要点:** 两个团队之间的每一次协作，都应该从一开始就写明结束日期。

判断一项工作何时应该变成服务，可以用 Rocketlane 提出的标准：只帮到一个客户的方案是定制；能帮到所有未来客户的方案是产品开发。

套用到上面的例子：专门为这家银行的身份提供方写的连接器仍属于定制；只有把它做成所有未来客户都能用的东西，才算产品开发。

## 重画团队地图，Docker 给了什么教训？

纸面上正确的团队地图，实际未必能减轻负荷，Docker 就是最清楚的例子。他们用逆康威策略（Reverse Conway Maneuver）让团队与架构对齐，目标是降低认知负荷、减少依赖，并与产品方向保持一致。

第一次，他们做错了。这提醒我们：在现有团队旁边放一个新团队（比如 FDE 团队），要检查认知负荷是否真的下降了，光把地图画出来还不够。

## 谁该读，怎样用在职业发展上？

如果你是有 2-8 年经验的工程师，正在做 FDE 或想成为 FDE，这是少有的、读完下周就能用上的组织类书籍。新组建 FDE 团队的负责人更应该读。

面试时可以直接问：FDE 团队向产品汇报还是向销售汇报？客户需求通过什么路径到达平台团队？回答含糊，往往意味着后面摩擦不少。写简历时，与其写“客户集成”，不如写清你如何把一项定制变成了多个客户共用的功能。

每张组织架构图上都有一个 FDE 方框。这本书帮你画出连接这个方框与其他团队的箭头，并在每支箭头上写下到期日。

**本周动手试试:**

- 阅读 teamtopologies.com 上的 Key Concepts 页面，然后给经常合作的每个团队归一个团队类型
- 拿最近三个客户需求，套用 Rocketlane 的标准：只帮到一个客户，还是能帮到所有未来客户？
- 对目前与平台团队进行中的每一项协作，写下结束日期和预期产出

## 信源

- [Team Topologies book (teamtopologies.com)](https://teamtopologies.com/book)

- [Team Topologies, 2nd Edition (IT Revolution)](https://itrevolution.com/product/team-topologies/)

- [Key Concepts (Team Topologies)](https://teamtopologies.com/key-concepts)

- [Building Stronger, Happier Engineering Teams with Team Topologies (Docker)](https://www.docker.com/blog/building-stronger-happier-engineering-teams-with-team-topologies/)

- [Forward deployed engineering overview - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/overview)

- [Forward Deployed Engineering: Finding the Model That Fits (Rocketlane)](https://rocketlane.com/blogs/forward-deployed-engineering-models)