ARTICLE · 1080012
FDE 填完缝之后:水利软件企业怎样把项目经验变成产品?
续集 / 从项目到产品
上一篇谈别迷信OPC与FDE,这一篇谈FDE离场以后
上一篇说,FDE 进入现场不是终点。于是问题来了:缝填完了,人撤走了,客户拿到系统了,公司到底留下了什么?
如果答案是“留下了一段甲方不敢动、乙方也不想再看的代码”,那不叫产品化,那叫电子遗址。
水利软件企业最熟悉的困境是:项目做了二十年,案例遍布全国,下一次投标时仍然要从需求调研开始;同一种报表改了八遍,同一种接口接了十二次,同一批坑由不同项目组轮流踩。公司拥有很多项目,却没有形成与项目数量相匹配的能力。
01 / PROJECT TO PRODUCT
为什么项目越做越多,企业反而越来越重
项目制有一个非常稳定的奖励机制:按时验收的人是英雄,停下来整理共性的人像是在拖进度。于是每个团队都会做出最理性的选择——先把眼前客户哄过去,产品债务留给未来。未来通常由另一个项目组负责。
复制旧项目看起来最快,但复制的往往不仅是功能,还有历史妥协、临时代码和上一任客户的特殊习惯。复制三次以后,没有人说得清什么是标准,什么是例外;复制十次以后,公司宣布要建设“统一中台”。

图|项目制死循环与产品化飞轮的区别
真正的产品化飞轮不是少写几行代码,而是每完成一个项目,下一次交付都应该更快、更稳、更少依赖某几个老员工。否则项目收入增长的同时,人力、沟通和风险会按同样速度增长,公司只是规模更大的手工作坊。
02 / PROJECT TO PRODUCT
别再说“把共性抽出来”:共性到底是什么
很多企业的产品化会议,最后都会出现一句正确但无用的话:“我们要把共性抽出来。”然后会议结束,共性继续留在现场。
判断共性至少要问四个问题:这个需求是否出现在两类以上工程中?是否源自法规、标准或稳定业务机制?客户不提时,业务是否仍然需要?它能否通过配置适应差异,而不是复制代码?
例如,水库名称和审批角色是配置;调度令必须经历拟订、审核、签发、执行确认和归档,则可能是稳定业务结构。某地要求把按钮放在右上角,不是行业能力;不同地区都需要追踪预案依据、责任人和处置状态,才值得进入产品。
03 / PROJECT TO PRODUCT
一个项目至少要带回五类资产
项目复盘如果只归档源代码和需求文档,等于把矿石原样搬回仓库。真正能复用的,是下列五类经过提炼的资产。

图|项目需要回流企业的五类核心资产
1. 业务本体
水库、测站、风险、预案、工单、调度令之间的关系、状态和动作。
2. 规则模板
规范条文、检查清单、判定条件、异常边界和人工升级规则。
3. 数据连接器
接口协议、字段映射、编码转换、质量检查和错误处理方法。
4. 场景评测集
真实问题、正确结果、失败案例和必须人工复核的红线。
5. 实施方法
角色分工、调研清单、里程碑、培训方式和验收证据。
这五类资产里,代码反而不是最稀缺的。AI 可以越来越快地写代码,却无法凭空知道一座水库为什么这样管理、一个告警为什么必须升级、一个验收结论需要哪些证据。真正的行业壁垒,是被组织化的业务判断。
04 / PROJECT TO PRODUCT
建立需求分拣线:不是所有定制都应该进入产品
产品化最怕两种极端。第一种是甲方说什么都进产品,半年后菜单像县城小饭馆:炒饭、火锅、寿司、咖啡和大盘鸡都能点,哪个都不好吃。第二种是产品部门拒绝一切现场反馈,坚称客户“不理解先进理念”,最后只剩理念没有客户。

图|把现场需求分成产品共性、项目配置和应当拒绝的伪需求
每个需求都应进入同一条分拣线:先说明业务问题和使用者,再判断是否跨项目重复,然后验证价值、合规性和维护成本。行业共性进入产品路线图;地方差异进入配置和扩展机制;只有某个人喜欢、又增加长期复杂度的需求,要有勇气拒绝。
这套机制需要产品经理、架构师、现场负责人和业务专家共同决策。不能让销售当场承诺、项目经理回公司求援、研发团队深夜还债。那不是客户导向,那是公司内部的债务转移。
05 / PROJECT TO PRODUCT
FDE 怎样离场,决定它是不是一门好生意
优秀的 FDE 从进入项目第一天起,就在设计自己的离场。因为他的目标不是证明客户永远离不开他,而是让复杂知识进入系统、流程和客户团队。
离场前应完成四件事:让客户内部至少一组人员能够运行核心流程;将关键配置、规则和数据映射纳入版本管理;把常见故障和人工处置边界写进运行手册;让总部产品团队接住现场沉淀,而不是只收到一份汇报 PPT。
客户接管并不意味着供应商失去收入。相反,收入可以从驻场人天转向版本升级、专业模型、数据服务、评测、安全运维和年度订阅。人撤出去了,价值关系反而更稳定。
06 / PROJECT TO PRODUCT
AI 时代,项目型企业的组织也要改
过去项目经验主要存在老员工脑子里,因此公司依赖师傅带徒弟。AI 让知识提取、代码理解、规则整理和文档生成成本大幅下降,但前提是组织愿意把“赶紧验收”之外的工作也纳入考核。
建议给每个项目设置一张“产品回流清单”,并把完成情况纳入项目利润核算:交付收入是一份成绩,带回多少可复用资产是另一份成绩。产品团队则必须承诺吸收时限,不能让现场认真总结的成果躺在共享盘里慢慢变成考古资料。
管理层还要接受一个不太舒服的事实:产品化初期会降低某些项目的表面效率。抽象接口、补评测、整理规则都要花时间。但如果永远只优化本期验收,企业就会用未来十年的重复劳动,为今天节省的两周买单。
07 / PROJECT TO PRODUCT
用三个数字判断产品化是不是自我感动
复用率
新项目中有多少能力直接来自标准产品,而非复制后重写。
交付边际成本
同类项目增加时,需要增加多少人、多少驻场时间。
非人力收入占比
订阅、标准模块、升级和数据服务收入是否持续提高。
如果项目越多,驻场人数同比增长;如果换一个客户,代码要重写一半;如果所谓产品收入仍按人月报价,那么“平台化”“中台化”“AI 原生化”都只是财务报表无法识别的修辞。
08 / PROJECT TO PRODUCT
写在最后:项目是矿,不是产品
水利行业不会突然停止项目制。工程有地域差异、责任差异和建设边界,现场工作永远有价值。问题不是要不要做项目,而是企业把项目当作终点,还是当作发现产品的矿山。
FDE 帮公司进入业务深处,AI 帮团队更快提取知识,业务本体帮助我们描述稳定结构,评测集帮助能力持续进化。它们合在一起,才可能让二十年项目经验不再只体现为“我们什么都做过”,而是体现为“下一次我们不用再从零开始”。
下一次项目复盘时,别只问是否验收、是否回款。再多问一句:除了疲惫,我们究竟带回了什么?
Water-Palantir 企业 AI 转型观察系列
WATER · PALANTIR