第二章 FDE 的核心模型

第二章 FDE 的核心模型

2.1 Delta + Echo：从"分开干"到"一起扛"

汉得信息的前身

在汉得的时候，现场团队分为业务顾问和技术顾问。这两个人之间的配合，其实就是 Delta 和 Echo 的雏形。

业务顾问（Echo 的前身）负责理解客户的业务需求，把客户的真实痛点翻译成技术可以执行的东西。技术顾问（Delta 的前身）负责把需求变成可运行的系统。

但这套组合有一个关键缺陷：两个人属于不同的专业线，考核标准不同，甚至利益冲突。我在现场见过太多次这种冲突——业务拿回来一个需求，看起来对技术层要求很高，短期内实现不了，或者实现成本高到客户大概率无法接受。又或者需求本身有明显的业务漏洞，上线后容易出问题。这时候冲突就来了：一边说"这东西实现不了"，另一边说"这就是客户的要求"。

这种冲突在业务顾问能力不足的时候尤其频繁。好的业务顾问会在和客户沟通时就把技术可行性和成本边界考虑进去，避免把不可能的需求带回团队。但不是每个业务顾问都有这个能力。

Delta + Echo 的升级

FDE 的 Delta + Echo 双子星单元，本质上就是业务顾问 + 技术顾问的组合，但做了一个关键升级：不是两个人各管各的，是同在一个 pod 里，对同一个业务结果负责。

建设性对抗依然存在——Delta 会质疑 Echo 带回来的需求是否技术可行、成本合理；Echo 会质疑 Delta 做出来的东西是否真正解决了客户的问题。但这种对抗是被设计的，不是意外的。它的目的是防止两种极端：Delta 脱离 Echo 容易陷入技术自嗨，做出架构优雅但对业务没有价值的东西；Echo 脱离 Delta 容易变成只能做 PPT 的传统顾问。

我在汉得见过的那种冲突——"这东西实现不了" vs "客户就是要这个"——在 FDE 模型里不会被回避，但会被更早地解决。因为 Delta 和 Echo 从一开始就一起在现场，一起听客户说话，一起判断什么值得做什么不值得做。冲突发生得更早，解决得也更快。

就应该是一个人

理论上，最理想的情况是一个人同时具备 Delta 和 Echo 的能力——既懂技术又懂业务，既写代码又和客户对话。我在第一章里说的"把两拨人合成一个人"，就是这个意思。

有人可能会说，同时具备顶级工程能力和顶级业务理解力的人太稀缺了，双人组合更现实。但我的判断是：就应该往一个人去培养。原因很简单——哪怕技术顾问在现场，他也一直在忙于开发，根本没有时间去听业务顾问和客户的沟通内容。业务顾问在和客户聊需求的时候，技术顾问在写代码；技术顾问在写代码的时候，业务顾问在和客户确认方案。两个人虽然在同一个项目上，但信息是割裂的。

FDE 要解决的就是这个割裂。一个人既听了客户说什么，又自己动手把东西做出来，中间不需要任何翻译和交接。这才是真正的"前线优先"。

当然，现实中 Delta + Echo 的双人组合可以作为过渡形态存在。但方向必须是合一的——不是"两个人各管一段然后拼起来"，是"两个人都在往同一个全栈方向成长"。

2.2 前线-产品闭环飞轮

闭环是怎么闭环的

第一章讲过，汉得的闭环是"每周汇总需求池，50% 门槛标准化"，周期慢、门槛高、旧项目享受不到。FDE 的闭环机制完全不同。

具体分四步：

第一步：前线构建解决方案。 Delta 在客户现场解决一个具体的业务问题时，不是只做一个一次性的定制开发。他在做的过程中就在想："这个问题其他客户会不会也遇到？这个解法能不能抽象成一个通用的模式？"

第二步：定期 review。 产品和平台团队定期 review 前线的解决方案，识别其中可复用的模式。这个"定期"不是汉得的"每周汇总"，而是一个持续的过程——每个解决方案完成后都会被审视。

第三步：沉淀。 约 70% 的前线解决方案会被重构为平台功能或标准模块。这个重构不是前线工程师自己做的——有专门的 Platform Engineer 负责把前线"粗糙但管用"的方案变成"通用且可靠"的平台能力。

第四步：反哺。 新的平台能力反向赋能未来客户的落地，进一步减轻单个 FDE 项目的负担。下一个客户遇到类似问题时，不需要从零开始，直接调用平台能力就行。

一个真实的闭环案例

我在汉得做的是报销系统。每个客户项目都需要做移动端，但每个客户的报销政策和用户填写内容都不一样，所以每个项目的移动端都是单独开发、单独设计的。

做了两三个项目之后，我发现了一个关键点：虽然每个客户的报销政策不同，但移动端的信息采集方式是可以被标准化的——字段可以配置，流程可以配置，展示方式可以配置。

跑了三四个项目之后，我把移动端的模块做成了一个标准功能。这个标准功能可以让业务顾问直接在前端和后端完成所有配置，不需要技术人员做二次开发。

这个变化的直接效果是：业务顾问获得了类似 FDE 的能力。 他们不再需要找技术顾问写代码，自己就能把客户的移动端需求交付掉。

这个案例也解释了一条演进路径：从每个项目单独开发 → 发现可标准化的部分 → 做成配置化模块 → 业务人员直接交付。2020 年之后，这条路变成了低代码构建平台；AI 时代来了之后，又进一步变成了 Agentic Coding 平台——业务顾问直接通过 AI 把要做的东西做完。逻辑是一致的：让最接近客户的人，直接产生可交付的成果。

哪些东西可以拿回产品？

不是所有前线的东西都值得沉淀。大致有三类：

判断标准是一个问题：这个东西会不会让下一个客户的部署更快？ 如果会，就值得沉淀。

怎么加快闭环的速度？

闭环的最大敌人是时间差。前线发现一个模式，如果等半年才沉淀到平台，黄花菜都凉了。这里有几个我认为可行的加速手段：

把沉淀当成从第一天就启动的事。 不是"做完项目再想沉淀"，是在项目过程中就持续识别可复用的模式。Platform Engineer 和 FDE 的配合不是事后交接，是并行工作。

用分层架构分离关注点。 客户定制层（FDE 直接操作）→ 平台适配层（可复用组件）→ 核心平台层（通用能力）。FDE 在定制层工作，沉淀下来的东西自然往上推。这比"做完一整个项目再把一部分抽出来"快得多。

强制 handoff。 每个 FDE 项目结束时，必须有一个结构化的知识转移：这个项目解决了什么问题、用了什么模式、哪些可以复用、哪些不能、为什么。不是把代码扔给平台团队就完了。

70% 是经验值，不是起点。 刚开始做 FDE 的时候，沉淀率可能只有 20-30%。随着平台能力越来越完善，前线的可复用素材越来越多，沉淀率会自然上升到 70% 左右。重要的是闭环机制从第一天就存在，而不是等到沉淀率达标了再建。

2.3 FDE 与传统角色的本质区别

素材里有大量的对比表，比较 FDE 和 SE、SA、CSM、专业服务的区别。这些表格在维度上很全面，但我觉得它们没有抓住最核心的东西。

最本质的区别是一句话：FDE 是手艺人，传统角色是流水线工人。

手艺人从头到尾负责一件作品。他理解需求、设计方案、动手制作、交付成品、处理售后。他对结果负责，不是对某个工序负责。

流水线工人只负责流水线上的一个环节。他接收上一个环节传过来的东西，做完自己这部分，传给下一个环节。他不关心上游为什么这么做，也不关心下游拿去干什么。

映射到具体的角色上：

不是说流水线不重要——流水线的效率比手艺人高，标准化程度也好。问题是：当交付的东西足够复杂、足够定制化、足够不确定的时候，流水线的协调成本会超过它带来的效率。你需要一个人（或一个极小的团队）从头到尾看着这个东西，随时判断方向对不对、做得对不对。

这就是FDE 存在的理由——在复杂场景下，手艺人比流水线更高效。

---