第 12 章　避免掉进定制化黑洞

12.1 深入客户不等于满足所有需求

FDE 必须进入客户现场，但现场越深入，越容易收到大量个性化要求。一个特殊字段、一条例外流程、一份定制报表，看起来都不大；累积之后，产品可能被拖成只服务一个客户的项目。

如果每签一个客户都要重新开发、部署和维护，收入增长就必然依赖人数增长。团队表面上拥有软件产品，实际运行方式更像人力外包。

FDE 的挑战是同时完成两件相反的事：足够深入，解决真实问题；又能保持抽象，把重复问题沉淀为可复用能力。

12.2 判断需求属于哪一层

现场需求可以分成几类。

客户配置是同一能力的不同参数，例如品牌名称、审批额度和知识范围，应尽量通过配置解决。

通用组件是多个客户都会遇到的技术能力，例如权限过滤、文档版本管理和工单连接器。

产品能力影响核心使用方式，具有较广价值，需要进入正式路线图和质量体系。

项目定制只服务特殊流程，应明确成本、维护责任和期限。

还有一类需求应被拒绝：与产品方向无关、风险不可接受，或长期成本明显超过价值。客户提出并不自动意味着团队必须实现。

分类时可以问：其他客户是否也会遇到？能否通过配置而不是分叉代码解决？谁长期维护？如果客户停止合作，这项能力是否仍有价值？

12.3 把现场经验变成资产

可复用资产不只包括代码。

连接器可以缩短系统接入时间；行业模板可以保存常见流程和角色；评测集可以记录真实任务与失败模式；行业词表可以改善检索和分类；实施手册可以保存决策顺序、检查项和风险；培训材料可以降低用户采用成本。

这些资产的共同特点，是让下一次交付更快、更稳、更少依赖某个个人。

沉淀不能等到项目结束。项目进行中就应标记重复出现的问题，并在关键阶段复盘。等团队离场后再整理，许多背景和取舍已经丢失。

12.4 什么应该进入产品路线图

现场反馈很多，产品团队不可能全部接收。一个需求是否产品化，可以考察重复频率、客户价值、战略一致性、实现成本、维护成本和对架构的影响。

重复出现不一定必须产品化。同一表面需求背后可能是不同问题；反过来，一个只在少数客户出现的需求，如果代表重要行业的准入条件，也可能具有战略价值。

进入路线图的需求需要脱离单个客户语言，描述共性用户、问题、约束和预期结果。不能简单把客户的功能清单转交研发。

产品团队也需要向前线说明决定：接受、延后、通过配置处理，还是明确拒绝。没有反馈的“需求收集箱”，最终会让 FDE 失去回流意愿。

12.5 一次例外不抽象，重复摩擦要复盘

过早抽象和完全不抽象同样危险。

第一次遇到特殊需求时，团队可能还不知道它是普遍规律还是偶然例外。此时可以采用受控定制，并记录背景、成本和维护方式。

当相同摩擦在第二个、第三个客户出现时，就应触发产品化复盘：共同部分是什么，差异能否配置，接口能否标准化，评测能否复用。

复盘也要计算真实成本。一个组件不是写完代码就可复用，还需要文档、测试、版本兼容、支持和持续维护。没有维护能力的“通用组件”，只是把项目代码搬到了另一个仓库。

12.6 让第二个项目更快、更稳

交付复利可以从几个变化中看见：第二次业务访谈有更好的问题清单，数据接入使用已有连接器，测试直接复用失败分类，安全评审有成熟材料，部署和培训不再依赖原作者。

复用不意味着复制完全相同的方案。不同客户的流程、权限和数据仍然需要判断。真正被复用的是经过验证的构建模块和决策方法，而不是把上一家客户的系统改个名称。

团队可以持续观察几个信号：首次可用时间是否缩短，单个项目需要多少人工投入，复用组件覆盖了多少工作，现场问题进入产品后是否减少重复故障。

如果客户数量增长，而交付时间和人力以相同比例增长，说明复利还没有出现。

12.7 不同规模客户需要不同杠杆

小客户决策快、预算有限，无法承担大量定制。服务必须依靠标准产品、模板和自动化，让一名 FDE 能支持多个客户。

中型客户已有一定流程和系统，但权责常不清晰。项目需要在标准化与有限定制之间平衡，并尽早对齐业务、IT、财务和管理层。

大型客户系统复杂、合规要求高，通常需要更深的现场投入和更完整的项目治理。团队可以为灯塔项目投入更多人，但每个项目仍要产生能够回到平台的能力，否则规模越大，定制债越重。

客户规模不同，投入方式会变化；不变的是每一次交付都要思考下一次怎样更容易。

12.8 FDE 与产品团队怎样形成闭环

前线掌握真实问题，产品团队掌握长期架构和整体优先级。两者只有形成稳定机制，现场经验才会变成产品进步。

FDE 提交的不应只是“客户强烈要求”，而要包含问题发生的场景、影响、频率、现有绕行办法、真实样本和可能的共性。产品团队则要评估长期价值、架构影响和维护成本。

发布新能力后，FDE 还要把它带回现场验证：是否真正解决问题，是否产生新的失败模式，其他客户能否复用。反馈不是从客户到产品的一次传递，而是一轮持续循环。

模型团队同样需要前线信息。抽象的准确率无法替代真实任务中的失败轨迹。经过脱敏和授权处理的评测样本、工具调用错误和用户修改行为，能帮助团队看见模型在生产中的边界。

12.9 警惕几种定制化信号

当项目出现以下情况时，团队应及时检查：每个客户都有独立代码分支；相似接口被反复实现；只有驻场人员知道怎样运行；新版本不敢统一升级；报价依赖人天；产品路线长期由最大客户临时需求控制。

这些现象不代表业务一定错误。有些高价值行业本来就需要深度服务。关键是团队是否清楚自己经营的是产品、产品化服务还是定制项目，并使用与之匹配的价格、组织和利润预期。

最危险的状态，是用产品公司的价格承诺定制服务，再用工程师个人投入填补差额。

本章小结

FDE 的价值不只在于解决眼前客户的问题，还在于把重复摩擦变成配置、组件、评测、模板和产品能力。深入现场与保持产品化并不矛盾，前者提供真实问题，后者让经验产生复利。

完成一次从发现到回流的交付闭环后，读者已经看见了 FDE 的完整工作。下一部分将把这些能力转化为个人职业路径：怎样在有限时间内建立作品、准备求职，或者开始独立服务客户。