什么是产品化，作为一个程序员，我的理解就是一个配置库一套代码一组表结构。
为什么要产品化，听过的、能想到的大概就是：从长远上能减少项目实施成本、规范行业业务标准、树立品牌。
在很多问题或事情上，是什么和为什么都很容易弄清楚，至于具体怎么做，很少谈到。
有这么一个真实故事：
有一天boss和大家开会：公司项目比较多，很多项目的需求都是大同小异，当做出来的系统却不一样，每个地方都得安排团队去做，公司决定产品化，要做出品牌，做出规范……。
接着部门就分到2个项目，项目1为烟厂A做一套质量管理系统（QM系统），项目2为烟厂B做一套生产管理系统（MES系统），QM是MES的一个子系统，所以把QM做成一个产品，到时候可以同时给2个烟厂使用。
烟草质量管理，就是制定检验标准，采集生产过程和成品检验的质量数据，对质量情况做判断，最后出报表，汇总给烟厂所在的中烟公司。
在此之前，公司没有关于质量方面的任何项目和相关资料，这就意味着一切从零开始。
老大决定QM划分为2部分，上位机和下位机，下位机负责采集各种生产机器和检验仪器的数据，上位机对数据进行分析处理，由2个小团队。
在烟厂A待了半年，主要收集和整理业务需求，接着就开工了。
因为上位机和下位机分属2个团队做，所以就先在一起设计出了数据库结构，下位机团队留守烟厂A开发，上位机团队到烟厂B去了，协助MES的需求调研，同时开发上位机。
在MES需求调研中，QM部分以烟厂1的业务和烟厂2的用户讨论，除了部分微调外，也确定了。
就这样，半年又过去了，QM系统出来了，在烟厂1也上线了。
又半年过去了，MES系统也做完了，准备上线，问题来了，QM系统在烟厂2无法通过测试，仪器型号和局域网搭建方式与烟厂A不一样，下位机无法采集到所有数据，上位机业务流程有问题。验收时间越来越近，项目面临着失败的风险，最后决定，为烟厂2重新开发一套QM系统。
最后，本次产品化失败了。
常常就是这样，项目方式实施→产品化，新项目试点→产品化失败→项目方式实施。
企业管理软件的产品化，应该是建立在同一个项目多次实施经验上，虽然无法百分之百确定所有可能的需求，但是至少有90%以上的把握。
没有大量业务支持、仅仅依据1、2次项目经验或者某个项目用户的需求来做产品规划，往往还是演变成多个项目方式实施。
为什么这么说呢？
对于同一个软件，每个用户对它的需求期望都不尽相同，很难找到100%满足用户需求期望的软件，那么，这时候需求符合度就决定了一个用户是否会去使用某个软件的一个比较重要因素（当然，同样需求符合度的软件，用户肯定会选择体验比较好的，不过这不是要阐述的内容）。
互联网用户数量基数大，这就意味着你的软件总能找到需求符合度较高的那部分用户，只要宣传到位，总会有人去使用，哪怕1个，不从经济角度考虑，软件就是成功的。
但是企业管理软件不同，它的用户比较固定并且人数不多（在公司内部，一个软件最多最多的情况下，用户数量也不会超过10万吧，大部分时间能有100个用户就算不错了），只要其中有1~2个用户说软件和他们的业务需求不一致，那么就表示在这个软件有问题，这里我们需要把整个公司当作一个用户来看待。
如果是以项目实施，我们可以进行无限的需求变更，哪怕是推翻重做，直至与用户需求达成一致。
但是软件产品就不同了，对于内部开发来说，往往意味着是一个配置库一套代码一组表结构。
我们该如何进行变更，使得软件在满足某部分用户需求的前提下，又不影响另外一部分用户的使用，并且仍然保持一个配置库一套代码一组表结构。
根据项目经验，如果用户需求变更不影响关键业务流程，通过增加配置基本就可以做到，但是这只是我们单方面意愿而已，现实往往不与人愿。
那能不能让用户改变自己的业务来适应软件，某个程度上是可以的，前提是系统能够在完成用户工作需要的同时，极大的提高用户的管理水平和业务水平。
不过这个做法比变更软件更难做到。
既然大量的进行变更和改变用户业务都不太现实，怎么确保一套产品化的软件最终不会拆分成多套项目代码？
还剩下一个方法，放弃那些可能导致产品被拆分的用户，似乎这个想法更傻。
这么说，那还不是多项目实施，既然项目都做完了，还要产品化做什么？
产品化，并不一定是要一开始就把一个软件做成一个产品，而是最终能够把一个软件做成产品，从长远上减少项目实施和运维成本、规范行业业务标准、树立品牌。
产品化过程就是业务的整合过程，业务整合就是尽可能的找出所有的业务分支。
单个项目的实施，往往就只针对那个项目需求，所以从需求分析→系统设计→功能实现，都很少有人去考虑其他的业务分支，纯粹的流水线式实现，而业务分支，往往又是造成需求变更比较重要的原因。
同时，对业务的熟悉理解程度，也和人员有关。
当要把一个软件产品化，或者把多个系统整合成一个平台时，不管是需求分析、业务整合、表结构设计、系统设计， 一个长期接触用户、实施和运维系统的员工，肯定比新接手的员工有明显优势。
这个优势在业务分支的考虑上特别明显。没有大量的业务知识，你怎么会知道某个业务需求，有这个分支、还有那个分支。
业务分支没考虑到，就可能影响系统的设计和表结构的设计，最终导致这个项目的系统无法直接扩展配置，在另一个项目上实施，只能分解出另一套代码来修改。
所谓，智者千虑必有一失，我们没办法把所有的业务分支都找到，如果新项目有新的业务分支怎么办？
这就说到规范行业业务标准了。
在整合业务的时候，我们与用户的角度是不同的。
换个说法，我们的起点比较高，是站在用户的肩上看问题的，想得更多，看得更远，经过长期的积累，去劣存优后，对于管理和业务的理解和水平，我们就会比用户更深刻，也比用户走得更快，我们可以很自信的和用户说，这个业务流程就该这么走才是最高效的。
当一个软件成为产品后，用户都在使用后，是否就完了？
当我们还在考虑是否从windows XP升级到windows 7时，微软已经开始了windows 8的研发了。
行业是在不断发展的，如果我们就此止步，经过一段时间后，之前建立的优势就会慢慢消失。
我们得保持警惕，时刻关注行业的发展趋势，熟悉最新的业务，使软件产品始终走在行业的前沿。
久而久之，就形成了一个品牌。
以上观点，只是我从一个程序员的角度对产品化的一些理解，如果好的不同见解，希望大家分享一下。