做了这么多年项目，为什么你始终做不出一款真正的产品？

很多做软件开发、企业服务的人，都有过这样的经历。

客户提出一个需求，我们就按照需求开发；

下一个客户提出不同的要求，我们再修改；

项目越做越多，功能越加越多，系统也越来越复杂。

忙了几年，手里积累了不少项目，看起来经验越来越丰富，

但如果想把这些项目整合成一款标准化产品，却发现困难重重。

项目做得越多，不代表越接近产品化。

有时候，过去积累的东西越多，转型反而越困难。

为什么会出现这种情况？因为项目和产品，从一开始就有着不同的目标。

一、项目是解决一个客户的问题，产品是解决一类客户的问题

做项目，最重要的是满足客户当前的需求。

客户需要什么，我们就开发什么；

客户提出修改，我们就调整；

只要最终能够交付，项目基本就算完成了。

在这个过程中，我们积累的是业务经验、技术经验，

以及处理各种特殊需求的能力。

但做产品不一样。

一款产品不能只满足某一个客户的需求，而是要考虑：

其他客户能不能使用？不同客户之间的需求差异怎么解决？

产品升级以后，会不会影响已经使用的客户？

这就要求我们在开发之初，

就考虑功能复用、模块划分、数据结构、业务规则和扩展方式。

项目关注的是把眼前的需求做好，产品关注的是用一套稳定的系统，

持续满足一类客户的需求。

这两种思路看起来相近，实际做起来却完全不同。

项目开发过程中，很多决定都是围绕当前客户做出的。

为了赶进度，可能直接把某个客户的特殊需求写进程序，

甚至修改底层数据结构。

当时看起来效率很高，但如果以后有十个客户提出十种不同的要求，

原来的系统就可能变得越来越难维护。

因此，项目经验可以帮助我们理解业务，却不会自动转化成产品能力。

有时候，真正开始做产品时，

我们甚至需要放弃原来的系统，重新设计底层架构。

这并不意味着过去的工作毫无价值，

而是过去的系统主要服务于项目交付，现在需要重新服务于产品的长期发展。

二、真正的产品化，不是把所有项目做成一个大系统

什么才算真正的产品化？

我认为，关键在于两个方面：模块化和可定制化。

模块化，就是把一款产品拆分成相对独立的功能模块。

不同客户需要什么功能，就可以组合使用，

而不是每接一个客户，就重新开发一套系统。

可定制化，则是让同一套产品适应不同客户的业务需求。

这种定制主要有两种方式。

第一种是配置。

客户可以根据自己的业务情况，配置字段、流程、权限和功能选项，

不需要每次都找开发人员修改程序。

第二种是扩展开发。

如果现有配置无法满足需求，

客户或者开发团队可以通过标准接口、组件和开发规范，

增加新的功能，并将其与原有产品整合起来。

例如，一款面向企业的客户管理系统，

不同公司可能有不同的客户分类、销售流程和审批要求。

如果每家企业都需要重新开发，成本就会越来越高。

但如果产品本身支持字段配置、流程配置、权限配置，

并且提供标准扩展接口，那么大部分差异都可以通过配置或扩展来解决。

产品化的核心，不是让所有客户使用完全相同的功能，

而是让不同客户在同一套产品基础上，满足各自的业务需求。

当产品的模块和扩展能力足够成熟时，

它就可能进一步发展成一个产品平台。

平台不仅提供现成的业务功能，

还提供可以反复使用的基础组件、核心技术能力、统一的数据模型和标准接口，

让其他功能能够在这个基础上持续开发。

三、做产品，不等于必须开发一套快速开发平台

这里还有一个容易出现的误区。

一提到产品化，有些团队就认为必须先搭建一套完整的快速开发平台。

数据建模、可视化表单、流程设计器、权限配置工具，一个都不能少。

结果产品还没有真正做出来，团队就先投入大量时间开发底层平台。

实际上，产品化产品和快速开发平台，并不是同一个概念。

从产品的核心能力来看，大致可以分为两类。

第一类是快速开发平台。

这类产品主要用于构建业务表单、审批流程和数据流转。

它的核心价值，就是让开发人员能够通过配置，快速搭建不同的业务应用。

第二类是专业业务系统。

例如ERP、CRM等大型业务软件。

这类产品的核心价值，不是让用户从零开始设计所有数据表和业务流程，

而是产品本身已经沉淀了相对成熟的业务模型、数据结构和业务功能。

用户购买ERP，是希望直接使用采购、库存、财务等业务能力，

而不是先花几个月设计一套ERP。

所以，专业业务系统应该优先做好自己的业务模型和功能模块，

再根据实际需要提供配置和扩展能力。

不要为了实现产品化，先把自己变成一个平台开发团队。

产品真正要解决什么问题，决定了它应该具备哪些能力。

四、真正决定产品能不能做好的，是底层架构

对于专业业务系统来说，技术架构当然重要，

但重点不是使用了多少新技术，而是能不能长期稳定地支持产品运行。

产品需要面对不同客户、不同数据规模和持续不断的版本升级，

因此底层架构至少要考虑几个问题：

稳定性、性能、可扩展性、开放性和维护成本。

界面是否足够漂亮固然重要，但不能为了追求新技术或者炫酷的效果，

让整个系统变得复杂，增加后续维护的难度。

技术方案应该服务于产品，而不是为了使用某种技术而改变产品的设计。

同时，架构还需要支持组件化开发、版本管理和相对独立的部署。

这样做的好处是，一个模块需要升级时，不必每次都牵动整个系统；

不同团队也可以按照统一的规范开发各自负责的功能。

对于需要长期迭代的企业软件来说，

这些能力远比单纯追求技术的新颖程度更加重要。

五、权限、数据、流程，这几个基础模型必须设计好

如果要开发一款可以长期迭代、服务不同客户的业务产品，

基础模型的设计非常关键。

其中，至少有三个方面需要重点考虑：权限模型、数据模型和流程模型。

权限模型解决的是谁可以查看、操作和管理哪些内容。

数据模型决定了业务数据如何组织、不同业务对象之间如何关联，

以及系统如何支持后续扩展。

流程模型则负责业务如何流转，

例如一张采购订单需要经过哪些审批环节，由谁审批，

以及不同情况下应该如何处理。

这些基础能力如果直接写进每一个具体功能中，后续修改就会非常麻烦。

例如，某个客户要求增加审批环节，

如果每个业务模块都使用各自独立的流程代码，

那么每次调整都可能涉及多个模块。

更合理的做法，是让业务功能与流程、权限尽可能分离。

开发人员在实现一个采购功能时，主要关注采购本身的业务逻辑，

而不需要把所有权限判断和流程处理都重复写进代码。

与此同时，人员、组织、岗位、角色等基础数据，

也应该具备清晰的结构和标准接口，方便与企业现有系统集成。

基础模型设计得越清晰，

后续开发新功能、调整业务规则和适配不同客户时，就越容易控制复杂度。

六、业务功能可以扩展，但不能什么都随意修改

产品化还有一个很重要的设计问题：哪些内容可以让客户修改，

哪些内容必须保持稳定？

很多系统会预留自定义字段，让客户增加自己需要的信息。

例如，采购订单可以增加供应商等级、项目编号或者内部备注等字段。

这种方式确实能够提高产品的适应能力。

但自定义字段并不意味着所有业务需求都能解决。

如果新增字段只用于展示和记录信息，处理起来相对简单；

如果这个字段还要参与价格计算、库存扣减、审批判断等业务逻辑，

设计就会复杂得多。

因为专业业务系统中的数据结构，往往与业务规则紧密关联。

以ERP采购订单为例，订单主表、明细表以及收货、结算等相关数据之间，

通常存在明确的关联关系。随意改变底层结构，可能影响多个业务环节。

因此，产品设计需要提前考虑哪些字段可以扩展、哪些数据关系不能随意改变，

以及扩展字段如何参与业务计算。

真正的可扩展性，不是允许用户随意修改所有东西，

而是在保证核心业务稳定的前提下，为变化预留合理的空间。

这也是为什么产品开发不能只关注眼前的功能，

还需要花足够的时间研究底层数据模型。

底层设计越合理，后续满足新需求的成本就越低。

七、业务规则要能够调整，而不是每次都修改程序

除了数据结构，业务规则也是产品化过程中必须重点考虑的部分。

不同企业可能有不同的业务规定。

例如，同样是采购审批，有的企业规定超过一万元需要部门经理审批，

有的企业规定超过五万元才需要审批，

还有的企业会根据采购类别、供应商等级等条件决定审批流程。

如果这些规则全部写死在程序中，那么每次客户提出调整，

都需要开发人员修改代码、测试和发布新版本。

当客户越来越多时，维护成本就会不断增加。

更合理的方式，是把可能发生变化的业务规则识别出来，

尽可能通过配置或者脚本的方式进行管理。

简单的规则，可以采用条件配置；复杂一些的规则，

可以使用脚本函数或者规则引擎。

但并不是所有产品都必须开发一套复杂的规则引擎。

具体采用什么方式，应该取决于业务的复杂程度和实际使用需求。

关键在于，

提前区分哪些是相对稳定的业务逻辑，

哪些是客户可能经常调整的业务规则，并为后者提供合理的修改方式。

当规则可以灵活调整时，

同一款产品就更容易适应不同客户的业务要求，也能减少重复开发。

八、再完善的产品，也不可能通过配置满足所有需求

做到这里，是不是一款产品就可以完全不需要定制开发了？

显然不是。

不同企业的业务流程、管理制度和系统环境存在差异。

即使产品已经具备完善的配置能力，也很难覆盖所有特殊需求。

所以，专业业务系统除了标准功能和配置能力，

还需要提供规范的二次开发接口。

二次开发可以由产品团队完成，也可以交给客户自己的技术团队完成。

关键是开发出来的功能，能够按照统一的规范，与原有产品稳定地整合。

具体可以采用多种方式。

例如，通过标准API或者Web Service接口，与外部系统交换数据；

通过组件接口扩展现有功能；

对于适合脚本处理的业务逻辑，也可以提供受控的脚本扩展能力。

如果客户需要开发独立的业务模块，

也可以在明确接口、数据规范和版本兼容要求的前提下，将其接入原有系统。

这里最重要的不是采用哪一种技术，而是建立一套清晰的扩展规范。

如果每次二次开发都要直接修改产品核心代码，

那么产品版本越多，维护难度就越大。

相反，如果标准功能、配置项和扩展功能之间有明确的边界，

产品就更容易持续升级，也更容易形成稳定的开发生态。

一款真正成熟的产品，不是永远不需要定制开发，

而是能够把定制开发控制在合理的范围内，

让大多数客户使用标准功能，少数特殊需求通过规范的扩展方式解决。

这才是产品化真正要追求的方向。

从项目开发走向产品化，并不是简单地把过去做过的项目整合起来，

也不是先开发一套庞大的技术平台。

它需要重新思考产品的目标、底层模型、功能模块、业务规则和扩展机制。

项目经验让我们知道客户需要什么，

产品设计则决定我们能不能用一套系统，持续满足更多客户的需求。

项目可以靠不断投入人力完成交付，但产品要想长期发展，

就必须把重复出现的需求沉淀下来，

把变化的部分设计成可配置、可扩展的能力。

当一套系统不再依赖开发人员不断修改代码，

就能适应大部分客户的需求时，它才真正开始具备成熟产品的特征。

——END——