对产品化的再思考

以下思考比较零散，想到哪里说到哪里。

产品和项目完全是两回事，如果我们基本都是项目型的产品，要想从项目化系统演化为成熟的产品是相当困难的，同理如果是定制项目型一开始要考虑太多的产品化要素也相当困难。项目型往往是磨合，熟练业务和技术，形成产品化和平台的意识，很多时候真正要做产品化的产品，还得抛弃掉原来的系统重新做。

什么叫真正的产品化？真正的产品化产品重点是模块化和可定制，一套产品要满足多个用户的需求。可定制又包括两个方面的内容，一个是用户本身可配置，一个是用户本身可以通过组件提供的接口进行二次开发。越是成功的产品往往模块化和可定制能力越强，产品本身变化为一个产品平台，而产品平台本身重点又在核心基础组件和技术组件，核心功能组件，核心底层数据架构和模型的提供。

产品化产品和快速开发平台是两回事情，很多时候我们一说到做一个产品化产品就容易理解为要做一套快速开发平台，数据建模，界面可视化表单设计，可视化工作流等全部都得做。产品化产品本身分两类，一类是本身确实就是一个快速开发平台，这类适合单纯的业务表单+工作流流转的，如现有的各个厂家推出的BPM产品，原来rational公司做的CQ缺陷和变更管理工具等；还有一类是大型业务系统类产品，如大型ERP系统，CRM系统，这类产品重点不再是数据建模和表单建模，因为专业化的业务系统需要在产品里面本身就有完善的数据模型和业务模型，这是产品的核心价值。

由于对于快速开发平台在前面的文章都已经谈到过，在这里仅仅谈第二类产品如何做好产品化的问题。

在纯粹的技术架构层面，需要有足够的稳定性，性能，可扩展性，开放性，技术架构选择重点在底层架构而不是在UI层，重点在稳定，性能和简洁而不是多么绚丽。这是做产品的基本要求，各种最新的技术往往并不适合应用到做产品中，包括我们原来用ext，flex做产品，最终都又回归到传统的html模式。技术架构本身要支持组件化开发，版本管理和独立部署。

在基础平台层面，我们需要的是几个核心底层模型，包括权限模型，数据模型，流程模型。流程+权限做到完全的可配置是做一个产品的基础。真正的做到功能和权限，功能和流程的完全解耦，做单独一个功能的时候不再关注权限和流程方面的内容。在这个层面涉及到人员，组织，岗位，角色等基础数据，这些数据必须要有完整的标准开放接口，可以和外部系统集成。

在功能层面第一点，我们谈到的功能本身的可扩展性是存在适当控制的，即功能本身底层数据结构不能发生大变化，但是业务单据对象的数据项和属性可扩展和定制，这个是我们在做产品的时候必须要考虑的问题。用户可以根据自己实际情况启用不同的定制字段来满足业务需求。业务表都预留自定义字段，但是自定义字段往往很难参与相关的业务规则和逻辑计算。一个业务功能涉及到的底层表结构定了一般也很难做大变化，因为很多业务规则完全跟数据结构相关，如ERP采购订单四层表结构，这个是很难做大变动的。要想真正做好产品化，必须在底层模型设计上多下功夫，多考虑模型的可扩展性和通用性。

在功能层面第二点，规则可定义，我们在实现一个产品化的产品的时候，哪些规则是可能会发生变化的，这些规则能否抽象出来，做到规则可自定义，不管是规则配置还是脚本函数，如果做到规则可定义，那么产品对业务需求的满足度会极大的加强。在这里不一定是要复杂的规则引擎才能做，我们可以通过较简单的方式来实现规则自定义。

再完善的产品要想简单的通过配置就满足所有客户的需求是不可能的，业务类产品的重点是在底层数据模型，业务功能模块设计和业务规则实现。为了满足产品化要求，必须有完善的二次开发和可扩展接口，这部分二次开发可以是客户开发，也可以是我们开发，但是二次开发后的内容通过编译和打包后能够很好的和原有产品化部分模块整合在一起。传统ERP软件采用的接口表模式，我们也可以采用标准的组件API接口如webserivce方式，支持脚本代码，支持自建项目在满足开发规范和约束情况下的集成等。