软件行业大面积亏损之从业者及第三方顾问视角4-交付“工作量”真正有意义的基础是“产品标准+业务定制+应用迭代”的三位一体

在上一篇《软件行业大面积亏损之从业者及第三方顾问视角3-厂商千万别再被交付“工作量”误导了》的回复里，代爱军老师提到“太多的私有化定制，耗尽了所有该有的利润空间！没有标准化的软件是没有生命力的”。

定制是客户角度的当前实际业务现状，标准化是厂商角度为了不被交付“掉坑”以及希望能力可复制的快速发展面临的当前实际情况。

但这两个其实不是非黑即白更不是水火相克，厂商可以通过技术平台化（或者低代码）来实现产品的“标准化”，客户可以通过厂商实施交付团队在“技术平台化”的基础上结合自己的实际业务实现“业务定制化”

正好前两天看了吴昊老师的《AI时代软件产业重新分工：底座归平台，结果归交付，价值归运行》，帮忙补充了第三点“应用迭代化（价值归运行）”，以前也专门写过《把版本的迭代权和维护交给客户而不是公司CTO-昊哥的“个性化需求能否先定制再合并到标准版本中”读后感想》就包含交付的定制化和运行应用迭代化。

当然，这些更适合厂商提供的是CRM、ERP等业务性系统而不是工具软件，适合那些想做标准软件但面对的目标客户又都是相对非标的个性化业务。

产品技术平台化（标准化底座），业务交付个性化（定制化结果），应用运行迭代化（落地化价值），三位一体。

产品技术平台化（标准化底座）、业务交付个性化（定制化结果）。

第一个产品要足够的底层灵活性而不是面对客户的具体业务应用要去代码开发，比如低代码或者零代码，比如很多SaaS厂商的PaaS等。

第二个实施交付团队要能真正理解自己面对的每个具体客户实际个性化业务，在产品平台化的基础上通过配置来快速最重要的是可见即可用地实现（避免需求在和开发传递时候的失真）

这两个好理解，而且从目标方向到落地责任部门都非常明确，技术平台化考验的是厂商产研团队，业务定制化考验的是厂商交付团队（需要客户参与的具体业务更重要但是否能调研/理解/落地也取决于厂商交付团队的专业性）。

这两个最关键的是每个厂商根据自己的目标客户以及战略看是否适合自己，如果适合，投入资源以及耐心一步一个脚印，虽远虽难但行则必至。

产品的平台化可能相对容易落地，比如很多saas公司开始搭建自己的paas，低代码公司本来就是剥离了直接给客户交付而是借助业务专业第三方的标准化产品。

交付的定制化因为相对远离公司高层相对最关心的营销业绩及研发成本等，交付的定制化又非常需要能理解客户业务的长期积累，所以可能很多公司会不断在救火和观望中徘徊，而很难脚踏实地去搭建体系甚至哪怕只是开始。

应用运行迭代化（落地化价值）难度更高，即使是十多年来最强调CSM的SaaS厂商，在这个角度也很多磕磕绊绊甚至完全盲点，因为应用运行迭代化（价值）是一个动态，几乎完全取决于“技术平台化（标准化底座）、业务个性化（定制化结果）”这两个基座，前两个如果不具备，应用运行的迭代不断落地价值就只能是望梅止渴和空中楼阁。

产品技术平台化（标准化底座）是基础，如果自己当前面对的客户绝大多数是非标的业务场景，想做相对比较标准的产品，就一定是平台化的低代码或者paas，从技术上做到标准化，才有可能在面对客户的个性化需求的时候，交付团队能快速响应而且不会陷入写代码定制的泥潭。

业务交付个性化（定制化结果）是关键，核心要素是“平台化的产品”和“理解客户业务的顾问”，如果再加一个第三是专业的项目管理能力。详见《个人能力模型和团队负责人能力模型》

应用运行迭代化（落地化价值）是水到渠成，过程可量化、结果可显性、体系可持续的个性化交付让客户的应用已经完全基于实际业务而和实际业务真正融合，在实际应用中遇到的应用深化和细化，客户经过学习可直接维护的平台化产品可以大大减少需求失真和避免需求传递带来的不可控和低效，也就是以前写过的《把版本的迭代权和维护交给客户而不是公司CTO-昊哥的“个性化需求能否先定制再合并到标准版本中”读后感想》。

这个时候，交付工作量，真正可以成为客户和厂商相对能对齐的合理项目成本评估。