FDE 怎么活下来：先拿信任，再扛意外
上一篇我们讲了 FDE 怎么和客户对齐——5 个动作搞定日常沟通。
但 FDE 真正难的部分不是「沟通技巧」。
是活下来。
你干得再好，也可能死在两件事上：
- 老板不信你——你连进场的资格都没有
- 现实给你意外——你规划得再好，也会被打回去
这两件事不是「技巧」能解决的，是必须接受的「现实」。
一、怎么让老板信你
这是最难的一部分，但也是最关键的一部分。
FDE 不是单纯做个系统就走的。FDE 实际上是在改变客户的工作方式。
你会让客户改变原有流程、放弃原有习惯、信任一套新东西。这对客户内部来说，是有阻力的。
我们遇到过最典型的场面：方案讲给业务方听，对方全程点头，最后说——
「我们之前那套跑得好好的，凭什么要为你的『AI 提效』重新学一遍？」
他不是针对你。他是要对自己的 KPI 负责。 原来的流程跑得好好的，改流程对他来说只有风险、没有收益：改好了是「应该的」，改砸了是他的锅。所以他天然的本能就是把事情拖住、把你的成果淡化掉。
这种情况下，FDE 一个人是推不动的。你必须拿到老板的支持——不是部门主管，是真正的「拍板人」。
鸡生蛋的问题：老板凭什么信你？
你还没做出东西，老板凭什么相信你？
我们的经验是，别试图用「说」来解决这个问题，用「做」：
- 先做一个小而完整的成果。 挑客户内部最疼、又最容易出效果的一个小场景，用一两周做一个能跑的东西出来。不用完美，能让老板一眼看到「原来这个事可以这样做」就行。
- 用结果说话，不要用方案说话。 老板听不懂你的技术方案，也不想懂。但他看得懂「这个表原来要人工统计半天，现在点一下就出来」。给他看结果，别给他讲架构。
- 直接和最上方谈。 不要让你的「对接人」过滤信息。对接人可能出于自保，把你的成果淡化掉、把你的方案搁置掉——你精心做的东西，可能根本到不了拍板人的桌面上。
我们现在有些项目推进困难，根子就在这：只和业务方谈，没和老板谈。 业务方不愿意改变，或者觉得花销太大、不敢尝试，这事就卡住了。能直接和最上方谈，很多阻力根本不是阻力。
一个更底层的判断
如果你没能拿到老板的支持，那 FDE 在这个项目里基本就废了。
这不是你能力的问题，是项目结构的问题。
识别出这种结构，比硬推更重要。硬推的结果往往是：你出了十成的力，拿到三成的配合，最后交付不达标，锅还是你的。
二、接受现实的复杂性：永远有意外
第二个现实，也是最反鸡汤的：
FDE 项目里，永远有意外。
需求文档上写的是理想流程，现实里的业务是另一回事：
- 客户的某条业务线下周要做大促，这个月系统不能动。
- 某个第三方平台突然改了 API，你的代码跑不通了。
- 客户的财务系统和库存系统对不上，你得先做数据清洗。
- 每个平台有每个平台的规矩：有的限频、有的半夜维护、有的接口文档和实际行为对不上。
- 客户有些业务环节「经常断」，一直靠某个老师傅手工补，而这个老师傅下周要请假。
- 客户领导突然换人，新领导要重新评估项目。
这些事情没有一件会写进需求文档。只有你天天泡在现场，才会一件一件撞上。
而且注意最后一点：很多意外不是靠技术解决的，是必须人为处理的。 系统跑不通的环节，FDE 得自己顶上去；平台规矩搞不定的流程，得有人去和客户一起想办法绕。指望 AI 或者流程自动消化这些意外，是不现实的。
FDE 不是一个「规划好就能执行」的工作。它是一个「规划 + 持续救火」的工作。
我们的应对机制
你要接受这一点，然后建立自己的「意外应对机制」：
- 每个模块都做降级方案。主链路断了，有没有备用路径？
- 每个关键节点都有 Plan B。这个平台抽风了，数据还能从哪拿？
- 每天下班前确认「如果明天这个出意外，我有什么选项」。想清楚再下班，比半夜被电话叫醒强。
这不是悲观，这是 FDE 的真实节奏。把意外当常态的人，才不会被意外打乱。
写在最后
上一篇讲了怎么和客户对齐，那 5 个动作是「日常」。
但 FDE 的真实工作里，日常只占一半，另一半是「活下来」。
怎么活下来？
- 让老板信你，拿到自上而下的支持
- 接受意外，建立应对机制
这两件事不是一次性做完就完的，是贯穿整个项目的。
FDE 不是一份「按计划交付」的工作。FDE 是在不断变化的现实里，把事做成的工作。