FDE 的第一道坎：怎么和甲方对齐
入行 FDE 之前，我们以为最难的是写代码。后来发现，最难的是和客户说话。
不是说话本身难，是客户自己也不知道自己想干啥。
他说要做一个「采购计划表」，我们问他要哪些字段，他说「就正常的那些」。什么是「正常的那些」？库存呢？供应商呢？审批流呢？税率呢？他答不上来——不是不愿意答，是真的没想过。
这就是 FDE 的第一个现实：你面对的不是一个想清楚了的甲方，是一个和你一起想清楚的甲方。
那怎么办？我们踩过几次坑之后，总结出 5 个动作。
一、频繁对齐：客户要的不是「听一次」，是「看到东西才能想起来」
很多人会想：我先去调研一下，理清楚再去找客户。这样问得更专业。
错。客户说「正常的那些」，不是因为他懒，是因为他需要看到东西才能想起来。
你问他「要不要审批流」，他可能说「不用吧」；但你把一个带审批流的 Demo 摆到他面前，他马上会说「诶这个我要的」。
所以关键不是一次问得多深，是频率。
我们的经验是：每天或每两天对齐一次。哪怕只是 15 分钟的站立会，哪怕只是「昨天做了什么、今天要做什么」。
你可能会觉得这样很烦客户。其实不会。客户最怕的不是你问得多，是「我给了需求，等了两周看到个完全跑偏的东西」。
高频对齐的本质，是把「大爆炸式的需求评审」换成「小步快走的反馈循环」。
二、早会晚会：用节奏替代口述
光靠「想起来了再说」还不够，要靠结构。
我们一般在项目早期会一天开两个会：
- 早会：对齐进度。今天做哪个模块，做完给到什么版本，负责人是谁。
- 晚会：对齐业务。我白天去客户那边听了一天业务，晚上回来和团队一起把业务过一遍——哪些是必须的、哪些是边缘的、哪些是客户嘴上说不要但其实要的。
为什么 FDE 一定要自己先去熟悉业务？
因为 FDE 不是「纯中介」。FDE 自己也要写代码、自己也要做方案、自己也要扛交付。 客户的业务不是我传话给团队就够了——我自己也要吃透，自己也要动手。
如果 FDE 自己对业务不熟，团队就只能在不知道业务的情况下硬写。写出来的东西客户看不懂，返工成本就极高。
我们经常白天泡在客户现场，听他怎么抱怨、看他怎么操作、读他以前的 Excel。晚上回来和团队一起过业务，让团队也吃透，要达到：大家一起把业务搞明白。
FDE 不是传话筒，是带队的人。 没有 FDE 带着团队一起吃透业务，客户的业务和我们的代码就是两套话。
三、提问前先做功课：问卷比闲聊更高效
一开始我们也喜欢「拉个会聊一聊」。聊完发现，录音整理到崩溃。
客户说的话七零八碎，主线被各种支线带跑。一份两小时的会议录音，我们整理需求要四小时。
后来我们做了一个会议整理 skill，能把录音转成文字、提取需求和业务事实。我们想，这下总能省事了吧？
结果发现：工具救不了会议。
客户说「那个东西啊，反正就是和那个 XX 系统差不多吧，然后可能有时候……」——AI 提取出来就是「系统和那个差不多」。然后呢？需求在哪？
对话本身没有质量、没有主线，AI 进来也是垃圾进、垃圾出。skill 只能放大结构化会议的效率，救不了没结构的会议。
根子不在工具，根子在会议本身。 没有结构化的会议，你让谁来整理都白搭。
后来我们学乖了：先去了解大概，再设计问卷，最后带着问卷去问。
这个顺序很重要：
- 先做初步了解：看看客户现在的系统、流程文档、历史工单，心里有张地图。
- 再设计问卷：把要确认的事情列出来，分模块，每块三到五个问题。主干必须明确，支线可以有。
- 带着问卷去问：客户答「是/否/我不知道」就行，不用他讲故事。
这样录音就好整理了。问答结构清晰，事后想查「他当时到底怎么说的采购流」，三秒钟就能定位到那一句。
没有结构化的会议，事后没人想看录音。
四、客户不懂 Demo：给他们看得见摸得着的 MVP
我们之前总跟客户说「我们做了个 Demo，你看一下」。
客户反应普遍是：「Demo 是什么？」
不是谦虚，是真不知道。在客户的认知里，「Demo」是技术圈的词，对他们来说没意义。他们关心的是：
「这个东西我能不能用？」 「我这个场景能不能跑通？」 「我明天能不能拿这个去试一下？」
我们后来才意识到：客户要的是 MVP，不是 Demo。
- Demo 是「演示给人看」——目的是展示能力、说明思路。
- MVP（Minimum Viable Product）是「最小可用产品」——目的是让用户真的能上手。
这两个东西看起来像，但本质不同。
给客户看 Demo，客户会说「看起来不错」——然后呢？然后就没了。Demo 看完了，客户不会主动去用，因为他没有「用」的入口。
给客户看 MVP，客户能立刻上手点一点、试一试，他会立刻告诉你「这里不对」、「那里要改」。这种反馈是有价值的，因为是从真实使用场景里出来的，能直接驱动下一轮迭代。
所以我们的原则是：尽量给 MVP，少给 Demo。
具体来说：
- 不做「看着漂亮但点不动」的页面 → 每一个按钮、每一个字段都要真的能跑
- 不做「概念演示」的截图 → 要能登录、能操作、能产生真实数据
- 不做「框架 demo」 → 要能在客户的真实业务里跑，哪怕丑一点
客户要的是「看得见摸得着」，不是「看得懂」。 一个丑但能用的 MVP，比一个漂亮但不能点的 Demo 强一百倍。
五、呈现时省略中间细节：给客户看最终形态
有了 MVP 还不够，怎么呈现也有讲究。
我们之前犯过一个错：给客户汇报的时候，喜欢把中间过程也讲一遍——我们试了哪几版方案、数据清洗遇到了什么问题、哪个接口改了两回。我们觉得这是「展示工作量」，客户听完只会更迷糊。
更糟的是，客户会抓住某个中间细节，提出一个根本不需要解决的问题。你随口提了一句「中间有版方案我们放弃了」，他就会追问「为什么放弃？那版是不是更好？」——然后你们要花半小时讨论一条已经死了的路。
后来我们定了个原则：交付阶段成果、或者跟客户沟通的时候，一律以最终形式呈现，中间细节全省略。
这不是隐瞒，是减少歧义。客户关心的是「这个结果能不能用」，不是「你经历了什么」。
具体来说：
- 给他看最终的界面、最终的表、最终的流程，不给他看过程稿
- 需要交代的只有两件事：怎么用、注意什么
- 中间方案、试错过程、内部讨论，客户不问就不讲；问了，一句话带过
每多讲一个中间细节，就多一个被误解的入口。 沟通成本不是聊出来的，是歧义堆出来的。
写在最后
FDE 和客户的关系，不是「服务方和被服务方」的关系。
是一起把一件说不清楚的事搞清楚的关系。
你拿不到客户清晰的需求，因为需求本身就不清晰。 你必须在「客户说不清楚」和「代码要能跑」之间搭一座桥。
这座桥，靠 5 个动作就能搭起来：频率、节奏、质量、形态、呈现。