FDE 是一种做事方式：深入现场，把大问题拆成小问题
我越来越觉得，FDE 这个词最容易被误解的地方，是把它当成一种“身份”。
好像只要挂上 Forward Deployed Engineer 的头衔，就自动成了 FDE。但在我看来，FDE 从来不是一群人，而是一种做事方式。
它是为用户负责，是和用户共创，是发现问题、解决问题，真正和用户一起创造价值的过程。它是建立彼此信任的过程，是为用户着想的过程。
FDE 的动作，是一条完整的链条
FDE 的第一个动作，是“深入用户现场”。
不是坐在会议室里听二手信息，不是看着 PPT 上被美化过的流程图，而是真的走到用户干活的地方，看他们每天到底怎么工作，卡在哪里，绕了哪些弯路，为什么明明有系统却还在用 Excel 和微信群。
现场是唯一诚实的地方。人会包装自己的问题，流程文档会掩盖真实的痛点，但现场不会说谎。你只有站在那里，才能看见问题真正长什么样。
但“深入现场”只是第一步。如果只是看见了问题却止步于此，那不过是换了个地方做调研。真正的 FDE，是把一整套动作从头走到尾：
- 深入现场——看见问题：走到用户干活的地方，看见问题真正的样子，而不是被转述、被美化过的样子。
- 定义问题——说清楚：把用户说不清、缠在一起的困扰，翻译成一个能被讨论、能被验证的问题。问题定义错了，后面全错。
- 拆解问题——化大为小：把大的、模糊的问题，拆成一个个小的、清晰的、能立刻动手的问题。
- 解决问题——交付结果：把拆出来的小问题一个一个做掉，交付看得见的结果，而不是停在方案和汇报里。
- 沉淀能力——让它可复用：把这一次的解法，沉淀成可复用的方法和产品能力，让下一次更快，也让别的用户能用上。
- 共创信任——一起走下去：和用户一起持续迭代，在一次次真的把事做成里，攒下彼此的信任。
这六个动作，从“看见问题”到“创造价值”，彼此不重叠，又刚好首尾相接，缺一环都不成立：看不见就无从解决，定义错了就南辕北辙，不拆解就无从下手，不交付就是空谈，不沉淀就每次都从零开始，不共创就换不来长期的信任。
而这条链条的目的，自始至终只有一个：帮用户发现问题，解决问题——而不是制造焦虑，贩卖产品，逃避责任。
后面几节，我想把其中最容易被跳过、也最能拉开差距的几个动作，再讲得细一点。
制造焦虑，是最偷懒的“解决方案”
现在很多所谓的服务，做的其实是反过来的事情。
先制造焦虑：不转型就会被淘汰，不上 AI 就会落后，同行都在做只有你没做。然后顺势贩卖产品：一套系统、一个平台、一份解决方案。最后，一旦出了问题，就开始逃避责任：是你需求没提清楚，是你员工不会用，是你的数据不行。
这套动作看起来很专业，但它和“解决问题”没有关系。它解决的是自己的业绩，不是用户的问题。
真正的 FDE 走的是另一条路：不靠制造焦虑来推动成交，而是靠真实地解决一个又一个问题，来赢得信任。信任不是话术堆出来的，是你一次次真的把事情做成，一点点攒出来的。
如果做不到，那就别自称 FDE
我想说得直白一点：
如果你不是这样的工程师，那就去做好外包，去做好销售——这些都是体面的、有价值的工作——但不要自称 FDE。
外包按需求交付，销售把东西卖出去，这没有问题。问题在于，如果你做的是外包和销售的事，却打着 FDE 的旗号，去承诺“和用户共创、为用户负责”，那本质上是一种错位。你没有深入现场，没有为最终的结果负责，只是借了一个更好听的名字。
FDE 的门槛不在头衔，而在你愿不愿意为用户的真实结果负责。
任何一个小问题都值得被解决
我有一个很坚持的观点：任何一个小问题都值得被解决。
一个每天要手动导三次的表格，一个总是对不上的数字，一个员工每次都要问同事的流程——这些看起来都太小了，小到不值得写进方案里，不值得在汇报时提一句。
但正是这些小问题，构成了用户每天真实的工作体验。把一个小问题干净利落地解决掉，比在 PPT 上画十个宏大的架构，更能建立信任。
而解决小问题的那种细致，恰恰是解决大问题最需要的能力。
大问题，要用解决小问题的细致去拆
大问题当然也值得被解决。但大问题不能靠“买一个大系统”来解决。
我不相信有哪个问题，清晰到、大到，上来买一个几十几百万的系统就能解决。真实的大问题往往是模糊的、缠在一起的、说不清楚的。如果它真的那么清晰，那它其实已经是个小问题了。
面对大问题，正确的做法是：用解决小问题的细致程度，一点点地分析它，拆解它，把一个模糊的大问题，逐步转化成一个个清晰的小问题，然后逐一解决。
- 先把问题说清楚，比急着上方案更重要；
- 把“系统解决不了”的部分，拆成“这一步到底卡在哪”；
- 每解决一个小问题，就离大问题的答案近一点。
大系统解决不了模糊的问题，它只会把模糊固化下来。真正能解决大问题的，是那种愿意蹲下来，把它一寸一寸拆开的耐心。
共创，不是外包
把问题一个个解决掉之后，还剩最后一个动作，也是最容易被忽略的一个：和用户一起走下去。
这里要说清楚“共创”和“外包”的区别，因为它们看起来很像，本质却相反。
外包是“你提需求，我交付”。需求由用户负责想清楚，工程师负责按单交付，中间有一条清晰的责任边界——需求错了是你的事，交付对了是我的功劳。这种模式很高效，也很体面，但它有一个前提：问题已经被想清楚了。
而 FDE 面对的，恰恰是那些还没被想清楚的问题。用户自己都说不清到底卡在哪，这时候你没法“等他把需求提清楚再动手”——你得和他一起，把需求都搞明白。这就是共创：不是各自守住责任边界，而是共同承担同一个结果。
所以外包交付的是“一个符合需求的东西”，共创交付的是“一个真的把问题解决了的结果”。前者做完就结束，后者做完才刚刚开始——因为解决了一个问题，往往会照出下一个更真实的问题，你们就这样一轮轮走下去。
信任就是在这个过程里攒出来的。它不是某一次漂亮交付换来的，而是你一次次和用户站在同一边、共同扛下结果，一点点长出来的。这也是为什么我在前面说：如果你只想守住责任边界，那就去做好外包——那没有问题；但那不叫 FDE。
所以，FDE 到底是什么
回到最开始的问题。
FDE 不是一个头衔，不是一支团队，不是一套方法论的名字。它是一种做事方式：深入现场，为用户负责，和用户共创，把大问题拆成小问题，把每一个小问题认真解决掉。
它相信信任是攒出来的，价值是一起创造出来的，而不是靠制造焦虑、贩卖产品换来的。
如果你也这样做事，那你就是 FDE，无论你的头衔是什么。