第六章 中国企业语境下的适配与风险

第六章 中国企业语境下的适配与风险

6.1 "包工包料"的甲方预期

一个非常常见的场景

在中国企业里，甲方和乙方的关系有一个根深蒂固的模式：甲方动动嘴皮子，乙方把东西全做出来。

我在汉得的时候，见过无数次这种场景。客户提一个需求，团队花两周做出来。客户看了说这里不行那里不行，改。改完再看，又说之前那个版本其实更好。改了很多版之后，客户选择使用第一版。

这不是个案，这是中国企业甲乙方关系里的常态。甲方的心态是"我付了钱，你就应该把我想要的东西做出来"。他们不认为需要自己参与设计、验证、迭代。他们的角色是"提需求"和"验收"，中间的过程是乙方的事。

这种预期和 FDE 的工作方式有一个根本冲突。FDE 要求甲方的人一起参与——一起发现问题、一起设计方案、一起验证效果。但甲方的预期是"你做给我看"。如何弥合这个预期差距，是 FDE 在中国企业落地的第一个挑战。

怎么处理

在合同里就把角色定义清楚。 不要在口头上说"我们是一起做"，要在商务条款和项目章程里写明白：甲方需要指定业务对接人，每周投入多少时间参与方案设计和验证；FDE 的角色是"联合创新"而不是"代工交付"。如果甲方不同意这个条件，这个项目就不适合用 FDE 模式。

用"联合实验室"或"创新中心"的形式降低阻力。 这是素材里一个有用的建议。与其在传统的甲乙方合同框架里硬塞 FDE 的概念，不如换一个形式——双方成立联合团队，共同投入资源，共同对结果负责。这种形式在中国企业里更容易被接受，因为它打破了"我出钱你出力"的二元对立。

让甲方的人从第一天就动手。 不解释为什么甲方需要参与，直接让甲方的人参与。FDE 做出一个原型后，把工具交给甲方的业务人员操作，让他们自己跑、自己发现问题。一旦他们开始自己用，就回不去了——他们会意识到参与比旁观更高效。

6.2 现有团队怎么转型

为什么不可能共存

第三章讨论过 FDE 和现有角色的关系，我的判断是：方向不是划清边界，是消灭边界。第六章要把这个判断在中国企业的语境下再讲透。

在中国的 IT 服务市场里，最常见的团队配置是：售前团队负责拿单，实施团队负责交付，售后团队负责维护。三个团队各管一段，交接是常态。如果在这种结构里"嵌入"FDE，结果是可以预见的——FDE 变成实施团队的一个高端版本，做的东西和传统实施没有本质区别，只是人更贵。

共存是不可能的。因为 FDE 和传统角色的底层逻辑是冲突的——FDE 要求同一个人从头到尾负责、边做边沉淀；传统模式要求流水线分工、各管一段。把这两种人放在同一个组织里，只会产生内耗：传统实施团队觉得 FDE 抢了他们的活，FDE 觉得传统实施团队拖了后腿。

转型路径

正确的做法不是共存，是转型。把现有的人变成 FDE，而不是在现有团队旁边加一群 FDE。

从 IT 咨询团队转型。 IT 咨询团队最大的问题是"接需求、做需求"——用户说什么就做什么，从来不思考这个东西能不能标准化、该不该标准化。转型的方向是让他们从"需求执行者"变成"问题解决者"。不是客户说"我要一个审批流"就去做审批流，而是先问：这个审批流解决的是什么业务问题？有没有更好的解决方式？这个模式在别的客户那里出现过吗？问完这些问题之后再动手。

转型的第一步是让咨询团队里的人学会用工具自己做东西。就像第四章说的，从业务侧拉出来的人要学会用 AI 编程工具。咨询顾问如果只能写 PPT 和需求文档，他永远不可能变成 FDE。他需要能自己搭原型、自己验证想法、自己判断技术上可不可行。

从 SaaS 产研团队转型。 SaaS 产研团队最大的问题是"客户要什么都不给"——因为每个需求都要经过"所有人用还是不用"的筛选，大量合理但不够通用的需求被直接拒绝。

表面上看这是人的态度问题——产品经理不愿意接定制需求。但根本原因是产品架构层面的问题：产品没有能力承载不同企业的个性化需求。一个需求如果能被"所有人用"，它才能进产品；如果不能，就被拒绝。这个二元筛选逻辑注定了大量合理的个性化需求会被丢掉。

转型的方向不是让产研的人去前线"找平衡"。是通过第五章讲的双循环模型，让产品本身具备吸收个性化需求的能力。内循环在前线发现不同企业的个性化场景，外循环把其中可复用的部分抽象为平台能力。随着外循环持续运转，产品能覆盖的场景越来越多，能配置化的部分越来越多，下一个企业的个性化需求就不需要从零开始做了。

第二章讲过报销系统的案例：移动端模块从"每个项目单独开发"变成"配置化"——字段可配、流程可配、展示可配。做完这个转变之后，业务顾问自己就能把客户的移动端需求交付掉，不需要技术人员二次开发。这就是产品架构层面的转型——不是产品功能变多了，是产品变得更灵活了，能承载更多不同的企业场景。

转型的第一步：产研团队需要建立的是平台可扩展性——配置化能力、模板化能力、API 化能力。每一条个性化需求被满足后，不是留在一个客户那里，是通过外循环变成平台能力，让下一个企业直接受益。

6.3 遗留系统与数据孤岛

现实

中国企业 IT 环境有一个普遍特征：系统多、老、杂。

一个中大型企业可能同时跑着 ERP（SAP 或用友）、OA（泛微或致远）、CRM、HR 系统、财务系统、自研业务系统，以及若干部门级工具。这些系统之间的数据通常是不通的——同一个客户的信息在三个系统里有三个版本，同一个审批流程在 OA 里走一遍、在 ERP 里又走一遍。

FDE 进入这种环境，面对的不是"给你一个干净的沙盒你可以随便搭东西"，而是"你的解决方案必须跑在一堆乱七八糟的旧系统上面"。

怎么处理

不要试图替换旧系统。 替换一个运行中的遗留系统的成本和风险远大于在它上面加一层适配。正确的做法是用"适配层"的方式——FDE 做的新东西通过 API 和旧系统对接，旧系统继续运行，新能力逐步叠加。等新能力覆盖了旧系统的核心功能，旧系统自然会被淘汰。这比"一次性推倒重来"安全得多。

数据问题先治标，再治本。 数据不通不是一天造成的，也不可能一天解决。FDE 在做项目的时候，先把眼前需要的数据打通——用脚本搬运、用接口对接、用中间表做映射。这些临时方案不优雅，但能让业务先跑起来。跑起来之后，再把数据治理作为平台团队的长期工作来做。

安全合规提前设计，不要临上线才想起来。 中国企业（尤其是国企和金融机构）对数据安全和合规的要求很严格。FDE 在做 discovery 的时候，就要把数据分级、权限模型、审计要求纳入考量。等到东西做完了才去过安全评审，大概率会被一票否决，前面的工作全部白费。

6.4 最典型的失败与红线

两种失败，一个根源

我在两种模式里都工作过，见过两种截然不同但同样致命的失败：

IT 咨询的失败：FDE 变成了现场外包。 这是汉得模式下最常见的退化。工程师到了现场，客户说什么就做什么。不问为什么，不想能不能标准化，不考虑做出来的东西和产品的关系。完全变成了接需求、做需求的执行者。做了一堆定制功能，没有一个能沉淀到产品里。项目结束了，代码留在客户仓库里，再也没有人碰过。

SaaS 的失败：动不动就拒绝合理需求。 这是我后来在 SaaS 公司见到的。产品经理坐在办公室里，收到客户需求后先做判断："这个需求够不够通用？能不能放进产品路线图？"答案经常是不能，于是需求被拒绝。客户提了十次合理的需求，被拒绝了十次。客户学乖了，不再提需求了。产品和客户之间的信息通道就这么断了。

两种失败看起来完全相反——一个是什么都做，一个是什么都不做。但根源是同一个：把产品当核心，没有把业务需求当核心。

IT 咨询的失败表面上是"什么都做"，实际上是因为不关心业务问题本身——只关心把需求文档上的功能做完、把项目按时交付。做着做着就变成了外包。

SaaS 的失败表面上是"什么都不做"，实际上也是因为不关心业务问题本身——只关心产品路线图上的功能排期。客户真正需要的东西，如果不在路线图上，就不是"我们的问题"。

红线

一条红线：前线优先。

这是第一章讲的四条原则里最重要的那一条，也是整本蓝皮书的底线。如果只保留一条规矩，就留这条。

前线优先的意思是：在任何决策中——需求要不要做、功能怎么设计、资源怎么分配——业务前线的真实需求优先于产品规划的完美、优先于技术架构的优雅、优先于标准化流程的规范。

踩了这条红线的表现：

• FDE 在现场变成接需求的工具人，不思考、不判断、不沉淀
• 产研团队以"产品路线图排不上"为由拒绝前线的合理需求
• 考核体系把 FDE 推向"计费工时最大化"而不是"业务价值最大化"
• 产品团队从来不看前线做出来的东西

一旦出现这些信号，不需要等到项目失败再反应。这些信号本身就是失败的早期症状。

---