我们的经验是首先创建产品平台，平台的设计采用微内核的方案，内核包括系统的技术框架，组件的集成引擎和一些公共的工具组件，平台外围功能采用组件化的方案，包括不同的批价算法组件，适配组件，配置组件等。按照用户群的需求以及商务策略把内核和相关组件打包成不同的业务产品，如移动版，电信版和联通版等。

    运营商的规范升级以后，同时也要对产品平台上的相关组件进行升级，并发布新版本的业务产品。所有的业务产品组成了一个计费的产品族。

    这种策略在一些大型的软件企业里应用非常广泛，比如微软的window产品系列：window Server，window profession，window home，分别覆盖企业用户，商务用户和家庭用户这三个有着明显需求差别的用户群。国内腾讯公司的QQ和TM也是一个成功的案例，用两个不同风格的软件覆盖娱乐人群和商务人群的社交需求。

2.用户的典型性需求

    所谓典型性需求是此类需求具有普遍性的特征，比如在报表要提供10秒钟自动刷新数据功能。这类需求往往可以引导产品规划方向，因为使用深入的用户提出的需求多，而且需求的价值越大。

    对待这一类的需求，一般对应有两种配置方式，一种是粗粒度，一种是细粒度。跟据用户的偏好和使用的环境，在系统安装阶段配置，配置影响的粒度一般是组件级，小到对象级，比如office安装过程中，引导用户选择需要在本地安装的程序模块，比如word，excel，dbaccess等。另一种是系统中的各种配置项，影响的主要是对象级以及程序的逻辑，比如firefox中的系统配置项，以及window的注册表。

    利用这两级的配置管理，基本上能解决用户需求的差异化，但采用这种办法的前提是已知用户的可能需求并预先做了定义和开发。对于不可预知的需求，需要通过二次开发接口来解决了。

3.用户的本地化需求

    用户本地化需求的满足程度，响应时间和用户的满意度关系非常密切，要提升用户满意度必须关注本地化需求的实现。而软件产品的大规模推广带来的本地化需求的工作量非常大，不仅会影响企业的利润率，而且提高了产品自身维护的风险。所以大型的软件产品都会提供一些本地化需求开发，比较典型的是sap，sibel，把产品实施和本地化开发的工作全部外包出去。

    在产品定义阶段，需要重新评估产品的范围，以及在产品范围内可能的用户本地化需求，对其中非核心的，可以通过外挂接口实现的功能规划出二次开发接口。比如运维平台短信派单模块，安排短信派发的二次接口，产品实施的时候，通过开发相应的短信接口类，适配不同的短信网关，短信协议，然后把该实现类挂接到系统上实现短信工单排饭的功能。

    二次开发接口的优点是增强了系统功能的扩展性以及缩短了需求的响应时长，缺点也是比较明显的，当二次开发接口过多，过于复杂超出了产品管理的能力时，会在产品升级的时候带来很多问题，比如开发程序被覆盖，接口变更导致功能无法使用等。

三、总结

    相比定制化开发，产品化的模式提高了复用水平，降低了研发和维护成本，但是提高了管理水平的要求，特别是规划，需求以及交付管理。笔者见过很多中小公司，产品化运营以后不经没有提高经营效益，反而因为产品前期投入过大，后期维护成本过高而陷入泥潭。所以产品化运营是否成功的关键在于业务积累和管理水平。前者是规划产品方向，能否取得市场竞争优势的核心;后者是产品化目标的保证，是能否切实降低研发维护成本的关键。采用定制化还是产品化，取决于企业的发展水平以及企业的竞争优势，没有好，只有适合。

    对于产品的需求管理，不应该套用定制化的那套解决办法，应该把需求分析放在合适的产品层次上考虑需求的实现方案，如果原有的解决方法需要平面思维，那么在产品化的需求分析需要的是多层次的立体思维模式。