【摘要】

FDE 这个岗位最迷惑人的地方，是它看起来像"高级开发"——能写代码、能改配置、能现场做原型。于是很多新人一上手就进入写代码状态：拿到需求就实现，实现完就演示，演示完就等验收。

半年后回头看，做了一堆功能，客户真正用起来的没几个。

问题不在技术，在目标设定。FDE 的目标从来不是"交付一套软件"，而是"改变客户的某个业务状态"。软件只是手段，而且经常不是最短路径。

这篇讲三件事：新人 FDE 的三种典型错位、时间该怎么分配、以及一条判断标准。

【核心要点】

• 把"交付软件"当目标，是所有错位的起点
• 三种典型错位：技术自嗨、需求照单全收、只对上线负责
• FDE 的时间应该按 4:3:3 分：理解业务、动手实现、推动落地
• 客户说的"功能"背后，往往有一个他没说出口的"业务结果"
• 判断标准：三个月后没人用的功能，不是交付，是库存

---

一、三种典型错位

错位一：技术自嗨

现场看到客户用 Excel 手工整理数据，第一反应是"这个我用脚本十分钟就能自动化"，然后真的去写了。

写完了，客户不用。为什么？因为客户手工整理的那张表，不只是数据汇总，还是他跟车间主任每周对账的沟通载体。你把表自动化了，他还是得打电话确认数字，反而多了一道"去系统里查"的动作。

技术自嗨的本质是：用自己的效率标准，替代了客户的业务标准。

错位二：需求照单全收

客户列了 12 条需求，逐条实现，一条不落。

做完发现，前 3 条是真正卡脖子的，后面 9 条是"顺便想想"。而那 9 条占了你 70% 的工期，还引入了 5 个新 bug。

FDE 和实施的差别在这里：实施按清单交付，FDE 要先判断这份清单是不是真的清单。

错位三：只对上线负责

系统上线了，账号开通了，培训做了，验收单签了。任务完成。

三个月后回访，日活不到 10%。

这三种错位指向同一个根因：把"我交付了什么"当成成功标准，而不是"客户改变了什么"。

二、时间该怎么分：4:3:3

一个健康的 FDE 项目，时间大致这样分：

阶段	占比	具体动作
理解业务	40%	跟班、看真实操作、翻历史数据、问"为什么这么做"
动手实现	30%	写脚本、配系统、做原型、改流程
推动落地	30%	培训、陪跑、处理抵触、修使用中的摩擦

新人最容易把比例做成 1:8:1——理解 10%，实现 80%，落地 10%。

这个比例在"需求明确、客户配合、没有历史包袱"的理想项目里能跑通。现实项目里几乎不存在这种理想情况。

理解业务那 40% 不是浪费。你在现场待两天，看到的"客户实际怎么操作"和"客户描述的怎么操作"，差距经常大到需要推翻方案。

三、跨行业对照：同一个"功能"，四种真实需求

客户说要"报表导出"，四个行业背后要的东西完全不同：

行业	客户原话	真实需求	正确解法
制造业	"要能导出生产报表"	月底对账要花两天，想缩短	不是加导出按钮，是把对账口径固化进系统，做成日结
医药	"要导出批记录"	GMP 审计时要在 4 小时内提供完整追溯	不是导出，是建立审计视图 + 权限留痕
政企	"要导出统计表"	上级要的格式每月都变	不是做死格式，是做可配置的取数模板
AI 落地	"要导出模型效果"	领导要判断这个项目还该不该继续投	不是导指标，是做一页能讲清 ROI 的结论页

同一个"导出"，四个解法。如果 FDE 只按字面实现，四次都会做错。

这就是为什么 FDE 必须先问"为什么"，而不是先问"什么样的表格"。

四、一条判断标准

项目结束三个月后，你可以用这一条自检：

我交付的功能里，有多少是客户每周至少用一次的？

• 超过 60%：交付健康
• 30%–60%：有一半是"看起来有用"
• 低于 30%：你交付的是库存，不是价值

库存这个词不好听，但准确。软件库存不占仓库，占的是客户的信任额度——下次你再提方案，他会先想"上次那个也没用"。

五、那代码还要不要写

要写，而且要比普通开发写得更快、更糙、更准。

• 更快：现场等不起三个月的排期
• 更糙：能跑通业务闭环就行，不要追求架构优雅
• 更准：每一行代码都要能对应到一个具体的业务动作，对应不上的删掉

FDE 的代码是探针，不是产品。探针的作用是快速验证"这个方向对不对"，验证完就该交给产品团队重做，或者直接丢掉。

把探针当产品打磨，是另一种形式的错位。

---

下一篇讲一个更具体的问题：客户说"我要这个功能"的时候，FDE 到底该问哪五类问题。