FDE vs 传统IT交付：本质差异在哪

📋 传统IT交付的逻辑

传统IT交付（比如做ERP、CRM、OA系统）有一个基本假设：需求是明确的，技术是确定的，交付是标准化的。

传统IT项目的流程：客户提需求→乙方做需求分析→写需求文档→客户签字确认→开发→测试→上线→验收。整个过程的核心是"需求冻结"——一旦需求文档签字，后面就按文档来，变更要走变更流程，加钱加时间。

这个逻辑在传统IT项目里是成立的，因为：第一，客户知道自己要什么（比如"我要一个进销存系统"，功能是明确的）；第二，技术方案是确定的（用什么数据库、什么框架、什么架构，都是成熟方案）；第三，验收标准是清晰的（功能点是否实现、性能是否达标）。

传统项目经理的核心能力：需求管理、进度管理、风险管理、沟通协调。本质上是"按图施工"的监工。

⚠️ AI项目为什么不能用传统逻辑

AI项目从根上就打破了传统IT交付的三个基本假设。

第一，客户不知道自己要什么。客户说"我想做个AI客服"，但他不知道AI能做到什么程度、不能做到什么、应该做到什么程度。他可能以为AI能100%替代人工，实际上只能处理70%的简单问题。需求不是"明确的"，而是"模糊的"，需要FDE帮客户一起挖出来。

第二，技术方案是不确定的。大模型的能力边界在哪里？同一个问题，用GPT-4和用开源模型效果差多少？Prompt怎么写效果最好？RAG的召回率怎么提升？这些都没有标准答案，需要不断实验和调优。技术方案不是"确定的"，而是"探索出来的"。

第三，验收标准是模糊的。AI项目的效果怎么衡量？"客服AI好用"是什么意思？是准确率90%？还是客户满意度提升？还是人工成本降低？这些指标需要FDE和客户一起定义，而且很多时候要在项目过程中逐步明确。

用传统IT的逻辑做AI项目，结果就是：需求文档写了但客户不认，方案做了但效果不行，上线了但客户不用，最后项目烂尾。这就是为什么AI项目88%死在上线后。

🔍 FDE和传统项目经理的五个本质差异

理解了AI项目的特殊性，就能理解FDE和传统项目经理的本质差异。

• 差异一：需求观不同。传统PM是"需求管理者"——客户说什么就记什么，控制变更。FDE是"需求挖掘者"——客户说的不是真实需求，要通过访谈、观察、数据分析挖出真实痛点，然后帮客户定义清楚"到底要解决什么问题"。
• 差异二：技术观不同。传统PM是"技术协调者"——技术方案由架构师定，PM负责协调开发资源。FDE是"技术决策者"——需要懂模型能力边界、懂技术方案选型、懂效果评估方法，能在"技术上能不能做"和"业务上值不值得做"之间做判断。
• 差异三：交付观不同。传统PM是"交付执行者"——按需求文档交付功能点。FDE是"价值交付者"——交付的不是功能，而是业务价值。客户要的不是"一个AI客服系统"，而是"客服流动率降低30%、夜间值班取消"。FDE要对最终业务结果负责，而不是对功能点负责。
• 差异四：风险观不同。传统PM的风险是"进度延期、预算超支、需求变更"。FDE的风险是"模型效果不达标、客户期望过高、数据质量差、人机协同设计失败、上线后没人用"。FDE需要管理的是"不确定性"，而不是"确定性"。
• 差异五：能力模型不同。传统PM核心能力是PMP那一套（范围/时间/成本/质量/风险/沟通/采购/干系人）。FDE核心能力是"业务理解+技术认知+交付经验+沟通谈判+持续学习"。FDE不需要考PMP，但需要懂业务、懂技术、懂人。

📊 传统PM转型FDE的三个优势和三个短板

如果你是传统项目经理，转型FDE有天然优势，但也有明显短板。

优势一：项目管理基本功。进度管理、风险管理、沟通协调、干系人管理，这些能力在FDE工作中同样重要，而且是很多技术出身的人欠缺的。

优势二：客户沟通经验。传统PM天天跟客户打交道，知道怎么跟客户沟通、怎么管理客户期望、怎么处理客户投诉。这些经验在FDE的客户访谈和需求挖掘中直接可用。

优势三：文档和流程能力。写SOW、写项目计划、写周报、写验收报告，这些文档能力是FDE的基本功。很多技术出身的人写不好文档，这反而是传统PM的优势。

短板一：技术认知不足。传统PM可能不懂大模型、不懂RAG、不懂智能体、不懂模型选型。这是最大的短板，但也是最容易补的——不需要你会写代码，但需要你看得懂方案、问得出关键问题、判断得了技术可行性。

短板二：需求挖掘思维。传统PM习惯了"客户说什么就做什么"，但FDE需要"客户说的不是真实需求，要挖"。这个思维转变需要刻意练习，多做几次客户访谈就能体会到。

短板三：效果量化能力。传统PM验收看功能点，FDE验收看业务效果（准确率、转化率、成本降低）。需要学会怎么定义指标、怎么采集数据、怎么量化效果。