第 6 章 · 定制化的诱惑，项目制的账

企业软件项目里，有一种需求最难拒绝：

“这个功能别人可能不用，但我们确实需要。”

客户往往没说错。

他的组织结构、审批规则、历史系统和客户合同都摆在那里。标准产品若完全不理，项目落不了地。供应商为了拿下合同，也很容易答应：可以定制。

第一次定制，双方都满意。

第二个客户又有一套“确实特殊”的规则。第三个客户要求兼容旧版本。项目越做越多，产品里长出一片谁也不敢删的分支。

销售说这是大客户需求，交付说不改就验不了收，研发说再这样下去版本没法维护。每个人都有道理，公司却越来越像一家人力外包企业。

这就是定制化最麻烦的地方：单看每一次决定，都可能是对的；连起来看，生意却不一定成立。

先别急着骂定制

把定制化说成中国客户的坏习惯，解释不了问题。

企业买软件，本来就是为了让自己的业务运转。税务、合规、行业规则和组织权限不同，产品当然要适配。制造业的生产方式不一样，银行与酒店也不会共用一套业务流程。

定制至少有三种来源。

第一种是行业和监管真有差异，不做就无法使用。

第二种是企业形成了有竞争力的独特流程，软件若强行标准化，反而会抹掉优势。

第三种只是历史包袱。旧系统怎么做，新系统就要原样保留；某位领导习惯看一张表，于是几十个字段都成了“核心需求”。

前两种可能值得做，第三种最容易把供应商拖进坑里。

麻烦在项目现场很难一次分清。客户会把三种需求都叫“业务需要”，供应商也未必有勇气追问。毕竟说“能做”有机会签合同，说“不值得做”可能当场出局。

上线、验收、采用、结果，是四件事

项目制喜欢明确边界。

什么时候完成需求确认，什么时候上线，哪些功能算交付，出现什么问题算缺陷。边界越清楚，双方越容易签合同和付款。

这套方式并没有错。没有里程碑，复杂项目会失控。

问题是，容易验收的东西不一定是客户最想买的结果。

系统上线，只说明它进入环境；通过验收，只说明合同约定的功能大体完成；用户采用，说明工作真的开始迁移；业务结果发生，才说明这笔投入可能有价值。

四件事之间没有自动关系。

一个功能可以全部上线，用户继续用 Excel；用户也可以天天登录，只是因为公司强制要求；使用量很高，利润却没有变化，因为系统只是把原来正确的流程做得更快。

供应商若只对前两件事负责，会把精力放在功能清单和验收材料上。客户若只在验收时认真，项目结束后没人继续推动，最后也会把失败归给系统。

双方都按合同完成了动作，企业却没得到原来想要的结果。

按人天收费，会长出什么行为

项目成本最容易计算的是人。

几名顾问、几名开发、做多少个月，乘出一个报价。客户觉得直观，供应商也容易管理。

但计价方式会悄悄塑造行为。

如果收入主要来自投入多少人天，需求越多、周期越长，短期收入越高。把一项重复工作做成产品，下一次少派人，反而可能减少项目金额。

公司嘴上说产品化，销售目标和交付收入却奖励定制，团队最后还是会走回老路。

这并不意味着按人天收费一定坏。需求不确定、责任边界难量化时，人天可能是双方最能接受的办法。问题在于，一家公司如果永远只卖人天，就很难证明自己比另一支同样能加班的队伍贵在哪里。

复杂度会变成收入，也会变成债。

今天多收的钱，可能是明天升级、运维和人员交接时要还的账。

FDE 也可能成为更贵的外包

FDE 强调贴近客户、快速解决真实问题，很容易让人产生好感。

可若没有产品底座和复用纪律，它比传统项目制更危险。

一个能力很强的工程师进到客户现场，什么问题都能接，接口不通就写一个，流程缺失就补一套，数据不干净就手工清。客户会非常满意，因为终于有人把事情办成了。

等这个人离开，团队才发现，知识全在他脑中，代码只适合这一家客户，产品主干也没有吸收现场成果。

这不是 FDE 模式成功，只是出现了一个更贵、更难替代的驻场开发。

Palantir 对自家前线部署工程师的描述里有一个容易被忽略的前提：工程师是在配置和扩展既有软件平台，而不是每到一家客户就从空白项目开始。现场工作之所以可能产生规模，不只是工程师厉害，还因为背后有东西可以反复使用。

没有这个前提，前线越强，后台可能越空。

每次项目都要留下点什么

定制与产品化不是二选一。

更现实的做法，是每次项目都把差异拆开：

只属于客户的数据映射和权限配置，留在客户侧；
行业反复出现的对象、状态和异常，沉淀成行业模型；
常见系统的接入方式，做成连接器；
验证效果的方法，做成评估集；
上线、回滚、审批和监控，做成通用控制能力；
现场踩过的坑，写进交付手册。

第一次仍然可能很重。第二次如果还和第一次一样重，就要问到底沉淀了什么。

所谓复用，不是把客户 A 的代码复制给客户 B。能复用的是解决问题的骨架，客户差异通过配置、映射和有限扩展进入。

这要求前线团队愿意把经验交回产品，也要求产品团队愿意承认现场发现的问题比原先路线图更重要。

两边都不容易。

项目制的解药，还是新马甲

FDE 给项目制带来一个值得期待的变化：它把关注点从功能完成拉向客户结果。

如果一个团队从一开始就约定业务指标，用真实环境验证，跟到采用与效果，再把现场成果沉淀回产品，贴身交付确实可能形成复利。

可 FDE 也提供了一个很好听的新包装。

原来叫驻场开发，现在叫前线部署；原来是客户提什么做什么，现在说“与客户共同创造”；原来按人头收费，换一套术语以后价格更高。

判断两者的办法不在职位名称，而在三件事：

这一单结束后，客户的业务结果有没有变化？团队留下了什么可验证的能力？下一家相似客户是否能更快、更稳地交付？

如果三个问题都答不上来，名字再新，生意还是旧的。

第一部讲企业怎样拥有数据，第二部讲数据为什么没有自然变成行动。走到这里，问题已经摆明：最后十米缺的不只是软件功能，也不只是一个聪明模型，而是一种能穿过需求、组织和交付边界的责任安排。

接下来，AI 会让这件事变得更可能，也更危险。

本章资料

场景说明：本章定制需求、验收与计价场景为企业软件行业常见机制的综合描述。