FDE能救中国软件吗？别把新角色塞进旧项目里

最近，FDE成了企业软件行业里的热词。

既懂技术，又懂业务；既能写代码，又能进入客户现场；再加上AI，一个人就能完成过去一个小团队的工作。很多人觉得，中国To B交付这个困扰行业十几年的老大难问题，终于看见了新的解法。

但我对这件事既期待，又有些担心。

期待的是，AI确实改变了软件生产效率，FDE也有机会打通产品与客户现场之间长期存在的断层。

担心的是，我们会不会只是换了一个新名字，继续做过去的老生意。

如果合同还是传统SOW，需求还是在项目开始前一次性写死；如果采购还是最低价中标，验收还是逐项核对功能清单；如果FDE仍然按照人月报价，一个人月最多只能报三四万元，那么他到了客户现场，最后很可能只是一个能力更强、事情更多、责任更大的驻场开发。

名字变了，生产关系没有变，结果很难发生根本变化。

中国To B绕不开的六个特征

在中国做企业软件，很多场景大家都不陌生。

生意要靠关系拿下；项目拿下以后，客户会提出大量定制需求；需求越来越多，预算却压得越来越低；系统必须部署在客户自己的机房或者私有云；项目做完了，尾款可能还要拖很久；出了问题要随叫随到，有时候即使没有问题，也得安排人到现场。

总结起来就是六个特征：

关系销售、定制开发、价格低廉、拖欠尾款、私有部署、现场服务。

我见过200w的项目，乙方还没开工，先要交几十万的保证金；也见过最低价中标的项目，中标价低到甲乙双方都知道做不出来，但流程走完了，还是照样开工，最后也果然没做出来。

图片

还有一种情况更常见。

一家成熟软件公司的标准产品，已经可以满足客户八成以上的需求；另一家公司没有成熟产品，却承诺所有需求都可以按照客户要求定制，报价还只有前者的六成。

最后中标的，很可能是后者。

因为站在客户的角度，标准产品只能满足八成，定开公司却承诺满足百分之百。至于最后能不能做到，那是项目启动以后的事。

这就是中国To B最尴尬的地方：

甲方要的是私房菜，付的却是沙县小吃的价格；乙方明知道这个价格做不出来，为了先拿下项目，还是承诺什么都能做。

项目开始以后，甲方不断提需求，乙方不断谈范围；甲方觉得乙方不懂业务，乙方觉得甲方需求天天变。系统迟迟不能验收，尾款也一直收不回来。

双方都很累，却很难说清到底是谁的问题。

甲方要的是结果，乙方交的是系统

如果只站在乙方角度看，很容易把问题归结为甲方不专业、喜欢压价、需求多、付款慢。

但事情没有这么简单。

传统软件项目里，乙方卖的是一套工具，甲方真正想买的却是业务结果。

图片

乙方认为合同里的功能已经全部上线，交付工作已经完成。甲方看到的却是业务部门仍然不用，效率没有提高，原来的问题也没有得到解决。

乙方认为软件已经交付，内部流程调整、人员培训和业务推动属于甲方的事情。甲方则认为，花了这么多钱，买回来的系统没有产生效果，自然不能轻易验收付款。

系统有没有装好，很容易判断；系统有没有创造价值，却很难说清。效果不好时，责任更难划分。

甲方为了保护自己，只能尽量压低价格、多留尾款、提高验收要求、要求私有部署，再把能想到的需求尽可能写进合同。

这些做法未必正确，却是风险与责任错配之后非常现实的反应。

乙方卖的是工具，甲方承担的却是工具无效的风险。这道裂缝不解决，双方就很难真正建立信任。

标准软件撞上了不标准的流程

ERP、CRM这些企业软件，卖的从来不只是功能，还包括一套被固化在系统里的管理流程。

软件假设采购应该这样审批，销售应该那样跟进，财务应该按照某种方式核算。企业购买软件，某种程度上也是在购买一套已经被验证过的管理方式。

但很多中国企业的实际情况并非如此。

我们的企业发展太快了。业务在变，组织在变，老板的管理要求也在变。很多流程不是从一开始就设计出来的，而是在业务发展过程中一点点长出来的。

有些流程写在制度里，有些流程藏在老员工脑子里，还有些流程只来自老板在会议上的一句话。

软件认为企业应该走A流程，企业实际上走的是B流程；好不容易按照B流程完成改造，三个月后组织一调整，又变成了C流程。

于是，标准的软件撞上了不标准、甚至不断变化的企业流程。

软件装得上，却用得别扭。

要么企业改变自己的流程去适应软件，要么乙方不断修改软件去适应企业。现实中，很多项目最后选择的是第二条路。

定制越来越多，产品越来越重，项目越来越难维护。

过去面对这种局面，最直接的办法就是加人。

流程不清楚，派人梳理；系统不适应，派人修改；需求变化了，再增加开发人天。靠驻场、加班和堆人，一个项目总能勉强扛过去。

问题是，这些经验很难回到产品里。

第二个客户来了，还是要重新调研、重新开发、重新踩坑。项目做了很多，产品却没有真正成长起来。

整个行业也因此被锁在了人天外包加定制开发的模式里。

如果规则不变，FDE只会变成超级驻场

FDE本来应该站在产品与客户之间，把技术变成真实的业务结果。

但到了中国的项目现场，这个角色很容易变形。

客户可能会把FDE理解成更懂业务的定制开发。

产品不好用，找FDE；接口对不上，找FDE；业务部门不愿意配合，还是找FDE。需求是他梳理的，原型是他设计的，代码是他写的，系统也是他推动上线的。

最后系统没有产生效果，责任还是他的。

过去由产品经理、实施顾问、开发工程师和项目经理共同承担的压力，现在集中到了一个人身上。

这不是FDE模式，而是把原来几个人的压力，交给一个更能干的人承担。

AI虽然提高了他的工作效率，却不会自动改变项目规则。

过去需要十个人做三个月的事情，现在一个FDE带着多个AI Agent，可能几周就能完成。可如果甲方的第一反应是"既然用的人少了，价格就应该再低一点"，AI带来的效率最终只会变成新一轮压价。

原来一个团队三个月堆出一座代码废墟，未来可能一个FDE带着AI，三周就堆出来了。

速度更快，不代表模式更先进。

FDE真正要解决的是项目永远从头再来

中国To B长期没有解决的，不只是交付效率问题，而是每一次交付都像第一次。

这个客户要求修改审批流程，下一个客户也有类似要求；这个项目需要连接一套老系统，下一个项目又要重新开发；驻场团队解决了大量现场问题，但项目结束、人一撤走，很多经验也跟着消失了。

公司做了很多项目，产品却没有真正长出来。

这才是FDE最值得期待的地方。

图片

FDE不能只负责快速响应客户需求，还要判断客户提出的到底是一个孤立需求，还是一类企业共同存在的问题。

哪些需求应该现场解决，哪些可以通过配置完成，哪些需要抽象成平台能力，哪些根本不应该进入产品，这些判断比快速写出代码更重要。

过去，项目团队忙着赶进度、做验收，没有精力做产品抽象；产品团队远离客户现场，又看不见业务里的真实细节。

FDE恰好可以站在两者之间。

他既能进入现场理解问题，也能把问题翻译成产品能力。现场解决一个问题只是开始，能不能让下一个客户不再从头开发，才是FDE真正创造的价值。

AI也应该用在这里。

它不只是帮助FDE更快地写代码，还可以帮助梳理流程、分析共性、生成原型、验证方案、补齐测试，把散落在项目现场的经验变成可以继续复用的资产。

真正有价值的闭环应该是：

进入现场发现问题，快速做出方案，用业务结果验证，再把有效经验沉淀回产品。

每交付一个客户，产品都应该变得更成熟；每解决一个特异性问题，都应该降低下一次交付的成本。

如果做不到这一点，FDE仍然只是交付资源。做到这一点，FDE才有可能成为连接客户现场与产品进化的关键角色。

FDE救不了旧模式，但可能带来一次重做的机会

所以，FDE加上AI，到底能不能救中国软件？

我的判断是，它救不了所有软件公司，更救不了一套不愿意改变的旧模式。

如果项目仍然按照人月计费，需求仍然靠SOW一次性锁死，验收仍然只看功能清单，那么FDE只会成为驻场开发的新名字，AI也只会成为压缩交付成本的新工具。

真正需要改变的，是我们怎么定义一个软件项目的价值。

不是完成了多少功能，而是解决了什么问题；不是投入了多少人天，而是创造了什么结果；不是这个客户的需求有没有做完，而是做完以后，有多少能力可以进入产品，继续服务下一个客户。

判断FDE有没有价值，也可以看一个最简单的结果：

做完一个项目以后，留下的是一堆只能由原班人马维护的定制代码，还是一套可以继续复制、继续进化的产品能力？

如果只是让定制开发变得更快，中国软件仍然逃不出人天外包的旧模式。

如果能够把现场需求变成产品进化的养分，把一次性交付变成持续沉淀，那么中国To B过去十几年没有走通的那条路，才可能真正出现一个新的入口。

最怕的不是FDE在中国做不成。

最怕的是整个行业都学会了FDE这个新词，用上了最先进的AI，却只是以更高的效率，继续重复过去十年的老路。