第四章 企业级落地路径

第四章 企业级落地路径

4.1 第一个试点怎么选

选什么

FDE 的第一个试点，应该选企业内部信息流传递的节点，不要选直接面向客户或供应商的环节。

我推荐两个方向：财务和 HR招聘。

这两个方向有一个共同点：它们都是企业内部信息流传递的节点，不直接面向外部客户，试错成本可控，同时摩擦很大、效率肉眼可见地低。

财务是最强候选。 每个公司都有报销、付款、对账这些流程，它们跨越多个部门，涉及多套系统，里面有大量手工操作和信息搬运。FDE 嵌入进去，第一天就能看到问题在哪里，第一周就能做出一个可用的原型。这种场景特别适合 FDE——需求明确、价值可量化、技术复杂度适中。而且财务流程的优化可以直接量化成节省的时间、减少的错误，ROI 一目了然。

HR 的招聘流程是第二个优先方向。 招聘是一个信息密集的协作流程——简历筛选、面试安排、评价收集、Offer 审批，每一个环节都在不同的人、不同的系统之间传递信息。不同公司的招聘流程差异很大，有的 5 步搞定，有的 15 步起步，标准化的 HR 软件很难覆盖这种差异。但这种差异背后又有共同的模式——都是在收集信息、做判断、走审批。FDE 嵌入招聘流程，可以在保持灵活性的同时把重复性高的部分（面试排期、评价汇总、Offer 生成）自动化。

不要选什么

同样重要的是知道什么不该选。

不要选客服。 客服是高度个性化的岗位，要求即时响应，每个客户的问题都不一样，很难在短期内抽象出可复用的模式。把客服作为第一个试点，你会花大量时间处理 edge case，而不是验证 FDE 的核心价值。

不要选产研。 产研团队自己就是技术团队，不存在"业务和技术之间的信息断层"——填平这个断层恰恰是 FDE 存在的最大理由。放一个工程师到一群工程师里面，解决的问题他自己就能解决，FDE 的价值体现不出来。

不要选采购。 采购的摩擦点要么在外部（供应商），要么在合规（改不动）。有一定规模的企业，采购已经被 ERP 覆盖了，流程虽然慢，但合规要求卡死了，改不动。FDE 最擅长的是"发现痛点、快速试、快速改"——采购这两点都卡不住。

选试点的核心逻辑是：不要选外部面向的（客服）、不要选没有业务-技术断层的（产研）、不要选被合规卡死的（采购）。 第一个试点的目的不是证明 FDE 无所不能，是证明它能在一个具体场景里产生可衡量的价值。做到了，后面的扩展才有说服力。

4.2 团队搭建：从两侧拉人，配对作战

第一个 FDE 从哪来

素材里有一个 90 天培养计划，前提是"配对一个资深 FDE 做带教"。但问题是：如果你连一个 FDE 都没有，谁来带？

所以第一个 FDE 团队的搭建逻辑，不是"招人→培养→上前线"，而是从现有的业务团队和产研团队各拉人出来，配对作战。这和第二章说的 Delta + Echo 双子星单元是一回事——业务侧的人负责理解需求、做 Demo、验证方案；技术侧的人负责把 Demo 变成可运行的系统。只不过在这个阶段，他们还不是"成熟的 FDE"，他们是在做 FDE 的过程中变成 FDE 的。

具体怎么做：从业务部门拉一两个人，从产研部门拉一两个人。两两配对，选一个具体的业务场景，从头做到尾。业务的人先根据对业务的理解做一个 Demo——用现有工具、现有数据，把"理想的工作流"搭出来。技术的人拿到这个 Demo，理解业务到底在做什么，然后基于产品的现有能力，判断哪些可以直接用、哪些需要二次开发、哪些做不到。两个人一起把这个工具在真实业务环境里跑通。

跑通之后，把这个成果反哺给产研团队——哪些能力是产品应该内置的、哪些配置化就能解决、哪些确实需要定制。这就是第二章讲的闭环，只不过现在是由这一对"FDE 种子"来驱动。

为什么是现在：AI 编程的前提

在继续往下说之前，有一点必须先讲清楚：业务人员能自己做工具，这件事在五年前是不可能的。是 AI 编程工具把写代码的门槛降到了业务人员够得着的地方。

第二章讲过一条IT 咨询的演进路径：每个项目单独开发 → 标准化配置 → 低代码 → Agentic Coding。现在到了 Agentic Coding 这一步，业务侧的人才能真正"自己做"。没有这个前提，"业务侧学会自己迭代小工具"就是空谈。

这也是 FDE 模型在现阶段才成立的核心原因——不是组织理论忽然变了，是技术条件终于到了。

业务侧和技术侧各自的成长

FDE 对两侧的人有一个双向要求：业务人员要学会编程，程序员要搞明白业务。

这个过程结束后，会发生一件事：

业务侧的人学会了用 AI 工具做东西。 他发现自己不需要等产研排期，通过 AI 编程工具和现有产品的组合，就能解决业务问题。他开始理解产品的能力边界，在和业务部门沟通时知道什么可以做什么做不到。他从一个"提需求的人"变成了一个"能自己动手解决问题的人"。

技术侧的人不再埋头只写代码。 他亲自看到了业务是怎么运转的、痛点在哪里、为什么有些需求看起来简单但做起来复杂。他从一个"接收需求文档写代码的人"变成了一个"能判断什么值得做什么不值得做的人"。

这对参与 FDE 的产研人员来说，成长速度会明显快于留在后方的同事。他们直接面对业务，做完一个项目效果立刻看得见——这个流程从 5 天变成 1 天，那个环节从手动变成自动。而没参与 FDE 的产研人员还在排期做功能，效果要等半年才知道。这种"结果可见性"和"成长速度"的差异，会让更多产研人员主动想参与 FDE。不需要设计正式的竞争机制，让成果透明就够了。

这就是 FDE 的种子。一对配对完成一个项目后，业务侧出一个 FDE，技术侧出一个 FDE。他们各自回到自己的团队，可以进一步推广和实施——业务 FDE 在业务团队里培养更多的业务 FDE，技术 FDE 在产研团队里培养更多的技术 FDE。

然后裂变

第一批种子跑通之后，裂变就可以开始了。

第二批：从业务和产研团队再各拉两三个人，分别和第一批的 FDE 配对。这次有了带教的人，培养速度会更快。

第三批：不再需要从外部拉人了。业务 FDE 在业务团队内部识别合适的人，技术 FDE 在产研团队内部识别合适的人，自然扩展。

这个裂变模型的好处是：它不需要你一开始就有完整的 FDE 编制和预算。两三个人就能起步，用实际成果证明价值，然后逐步扩展。比"一次性招一整个 FDE 团队"风险低得多。

配套的硬性规则

团队搭建过程中，有几条硬性规则：

首次集成时间不超过 14 天。 技术侧的人进入项目后，14 天内必须完成第一次和业务系统的集成。做不到，要么是项目选错了，要么是技术能力不够。

生产上线时间不超过 90 天。 如果一个项目 90 天还上不了线，直接终止。拖得越久，沉没成本越高。

业务侧必须有对接人。 如果业务部门没有人愿意配合，项目不启动。FDE 不是单打独斗，需要业务侧有人提供业务上下文、配合测试、推动使用。

每个项目至少产出一个核心产品改进。 做不到的项目，需要复盘原因——是项目本身太定制化，还是没有去识别可复用的模式。

上线 120 天后，技术侧 FDE 撤出。 注意，这里撤出的是技术侧——也就是产研团队的人。他回到产品团队，把前线的经验、发现的可复用的模式带回去用于孵化新的 FDE。而业务侧的人不会撤出，因为他就站在原地。经过了这一个完整的项目，业务侧已经多了一个能自己迭代小工具的人。这个人不需要再等产研排期，他能用现有的产品和工具自己解决问题，同时还能把做出来的东西继续反馈给产研团队，作为可用的工具开发方案。闭环没有断——只不过从"两个人一起做"变成了"业务侧自己做、持续反哺产研"。

启动之前的一道门槛

团队搭建的倒计时不是从拉人那天开始的。在那之前，有一件事必须搞定：业务发起人。

没有业务发起人的试点，大概率会变成一场技术自嗨。业务发起人是那个愿意把团队的时间腾出来配合 FDE 的人，是那个在 FDE 做出来的东西和现有流程冲突时拍板"用新的"的人，是那个在项目遇到困难时不会撤退的人。

如果找不到这样的人，不要开始。等。等到有一个业务部门的主管主动说"我这里有问题，你们能不能来帮我看一下"，再启动。

4.3 项目执行：三步走

试点选定、团队搭好之后，FDE 进入项目执行。整个过程分三步。

第一步：跟着走一遍。 FDE 到了现场，先到业务人员的工位旁边坐下来，看他怎么工作。不是画流程图，不是写需求文档，是亲自动手跟着走一遍完整的业务流程。

第二步：第一天就交付一个能跑的原型。 挑一个最痛的点，直接动手做一个粗糙但能跑的改进。做出来就给业务人员用，用完反馈，立刻改。第一天的原型不需要完美，但必须能跑、必须能解决一个真实的痛点。

第三步：逐步深入和扩展。 原型验证方向之后，把粗糙的方案打磨到可以日常使用，把覆盖范围从一个环节扩展到整个流程。每解决一个问题就立刻让业务人员用起来，增量交付。

4.4 与需求方的协作

FDE 和业务人员的配合方式，不是"我给你做东西，你验收"。两个人（或一个极小的团队）一起发现问题、一起设计方案、一起验证效果。业务人员提供业务上下文和组织感知，FDE 提供技术落地和判断可行性。项目做完之后，业务人员应该学会用 AI 工具自己解决日常问题，技术侧 FDE 在 120 天后撤出但保持持续的通道——业务侧随时能找到技术侧，闪光点持续回流给产研团队。

4.5 沉淀机制

发现的那个瞬间就报上来

沉淀机制最关键的一步，不是做完项目之后的复盘，是在发现可复用模式的那个瞬间就报上来。

我在汉得做报销系统的时候，不是做了四五个项目之后才突然意识到"哦，移动端可以标准化"。是在做第二个项目的时候，就发现移动端的信息采集方式和第一个项目几乎一模一样——字段不同，但采集的逻辑是相同的。那个发现是在项目过程中冒出来的，不是事后复盘想出来的。

发现之后，我做了产品设计和方案输出，然后把开发工作交给标准化部门（当时的产品中心）完成。这个分工很重要：前线的人负责发现和设计，后方的人负责重构和标准化。不是前线工程师自己把标准化也做了——他还在跑项目，没那个时间。

必须跑够足够多的项目

沉淀机制有一个前提条件：FDE 必须在外部跑了足够多的交付项目，才能看到可以标准化的东西。

一个项目看不到模式。两个项目开始有感觉。三到四个项目之后，哪些是通用的、哪些是定制的，就比较清楚了。所以沉淀不是靠聪明，是靠经验积累。你必须在不同的客户、不同的场景里看到同一个问题反复出现，才能确认这是一个值得标准化的模式，而不是某一个客户的特殊需求。

这个前提也解释了为什么 FDE 不能频繁换项目。一个 FDE 在一个领域里待的时间越长，他看到的重复模式就越多，沉淀出来的东西就越有价值。频繁轮换的 FDE，每个项目都是从零开始，和传统的驻场开发没有区别。

沉淀的路径：从发现到平台化

沉淀的路径大致是：在项目中发现模式 → 立刻记录和上报 → 由平台团队负责重构 → 新能力反哺后续项目。这条路径里有几个关键点：发现是即时的不是事后的；记录不需要完美但必须抓住瞬间；重构不由前线负责而是后方 Platform Engineer 的工作；反哺速度取决于同步频率。

沉淀的具体机制、即时捕捉的方法、以及什么值得沉淀什么不值得，第五章会详细展开。

---