从项目回来之后，对 Palantir FDE 交付模式有了更多了解（见 Palantir FDE 模式的实践和思考)，我突然意识到：我在企业内部干的事情其实也类似于 FDE 交付，都是基于真实的业务进行系统开发，不过在项目上是和客户聊业务，在企业内部是和公司里的业务专家对齐业务

这篇博客记录一些 FDE 在企业内部的实践，并且对比和外部项目的区别

主要角色和工作流程

在项目上的交流，更类似于 Palantir FDE 的模式，主要的角色是：

• FDE Echo 团队 - 负责建立客户关系，公司目前没有明确的组织框定，但在职能上主要是销售团队的客户经理和公司内部相关领域的业务专家（比如我们团队有在公司采购体系干了十几年的专家）来承担。销售团队和客户有良好的关系，也更清楚客户组织内部的各种情况和关系；业务专家会保持和客户的专家同属类似的领域，能够顺畅交流
• FDE Delta 团队 - 负责根据客户交流的情况进行技术上的实现，也就是我所在的团队。实际上和 Echo 团队会配合比较紧密，因为一些客户领域的业务术语并不好理解，需要 Echo 团队的业务专家进行翻译和教学
• 客户的业务专家 - 一般是不懂技术的业务专家，熟悉客户内部的业务流程
• 客户 IT 系统的供应商 - 有些数据集成相关的需求要找这些供应商对齐

一般的交流，是 Echo、Delta 团队、客户的业务专家一起聊客户的业务，根据客户的业务聊出一个痛点场景进行攻关

在公司内部，角色则相对简化，不需要花太多精力维护客户关系：

• 公司的业务人员 - 实际在公司业务一线的人员，他们有很多工作习惯和工作流程，并且数字化程度并不算高（很多是 Excel 进行管理）。原来公司也有一些组织去开发相应的系统提升他们的办公效率，但系统不好用并且迭代很慢，往往满足不了业务需求
• FDE Delta 团队 - 负责技术实现，也就是我所在的团队
• 业务专家 - 真正在相应业务一线摸爬滚打十几年的专家，比公司的大多数业务人员还更懂业务，他们能顺畅和公司的业务人员进行沟通，也有丰富的实战经验。业务专家和我们 FDE Delta 团队是在同一个组织的，拥有共同的目标和管理者，因此相比客户的业务专家沟通会顺畅很多

在公司内部，我们 FDE Delta 团队一般只和业务专家进行交流，因为他们经验足，能够代表业务一线的需求，知道什么样的系统是真正通用的、高价值的、一线能用上的。业务专家会定期收集一线人员的反馈，也会时常去一线项目上直接和一线人员沟通，收集到的这些反馈会由业务专家反馈到我们这边进行下一轮迭代

主要工作

看完上述主要角色和工作流程，想必对我们的主要工作应该有了大致的概念。用我的话来说，我觉得就是把以往业务一线人员的工作习惯固化到系统里，相当于优化一些人拉肩扛的流程和一些原本用 Excel 管理的流程

和外部项目的区别

在内部给一线业务人员做项目和给客户做项目还是有很大的差别：

• 企业内部沟通更加流畅：企业内部的一些组织关系对我们来讲是明确的，沟通往往非常顺畅；但客户的组织关系是不明确的，如果客户关系不够好，很可能客户的企业对我们来讲就是黑盒，这种情况下，可能会出现各种非技术的因素影响项目的进展，也影响和客户的沟通效率，最终就可能导致项目战线拉得很长或者做出来客户并不满意的东西
• 企业内部迭代更加稳定：在对外的项目上，由于每个客户情况不同，可能有各种非技术的因素影响项目进展；企业内部的项目并不存在这个问题，迭代可以做到相对稳定，这对于技术人员显然是更加舒适，正反馈也更强的，毕竟一些非技术因素导致项目进行不下去对技术人员来讲还是很无力的

可以明显发现企业内部采用这种模式带来的价值是确定性更强的

我的体会和思考

以下是我在实践中的一些体会和思考：

• 用户体验重要，但不需要像 toC 产品一样追求极致的用户体验：总体和做对外 toB 的产品、项目是类似的，很多使用细节能用比好用重要，不需要打磨太细，花很多精力在提升易用度上，不如把这部分的精力放在跑通业务流程、加快迭代上
• Vibe Coding 加快迭代，使得这种模式行之有效：公司原本也有一些人（称之为装备部）做类似的系统，但由于迭代速度较慢，很难跟上业务需求，一线业务人员很容易就用不起来最终弃用，甚至会因为规定原因出现一些系统不好用还不得不用的情况，反而降低效率。Vibe Coding 带来的迭代速度加快可以有效解决这个问题
• 业务专家很重要：公司装备部的人除了迭代速度跟不上之外，缺少业务专家也是一大劣势，这意味着他们得到的反馈往往是失真的。在我们团队，技术实现和业务专家紧密沟通，这种沟通效率上的差距也会使得最终的产品效果上的巨大差异
• 产品逻辑和做个人自用小工具类似：个人自用的小工具是自己觉得怎么样好就做成怎么样，Vibe Coding 出的企业系统则是业务专家觉得怎么样好就做成怎么样。不过企业系统还需要花费大量时间处理数据集成中的各种技术非技术问题
• 长期来讲，业务专家或许可以自己尝试自动化：实际上可以发现，对于业务的理解、流程的理解是完成这些产品的关键所在，只有真正长期干过的人才真正掌握这些知识，而依赖我们技术实现只是因为专家不懂技术。所以长期来看，或许业务专家可以自己尝试自动化业务流程。短期在实践中暂时不太可行，我们的项目就有个业务专家兴致勃勃用 Cursor 写了个 Skill，最后发现连基本的概念都没有搞清楚，只能开发再进行优化（说是优化实则和重写一版差不多了）

• #FDE