产品化的理解.doc

产品化的理解大家的产品化（以下为我与部分人员沟通的，不一定全面）开发工程师对产品化的理解产品化，就是做成一个完整的产品给用户。提供阶段性功能的代码库，帮助文档、漂亮的DEMO、SampleCode等。产品发布后需要先进入一个维护阶段在进入下一个开发阶段。测试工程师对产品化的理解评审通过标志一个产品的结束，提供完备的文档，未解决缺陷列表等。提供DEMO方便用户简单修改在分发。资料开发工程师对产品化的理解产品化，包括要提供SampleCode（不需要提供DEMO），各种文档提供电子版即可，不要提供印刷品。UI工程师对产品化的理解产品化需要的工作就是界面和统一风格的图标，然后是后期的用户体验。大家是否对产品化也有同样的感受啊？什么是产品化那么到底什么是“产品化”？在认识产品化之前，先认识一下“产品”：产品（product）是市场上任何可以让人注意、获取、使用、或能够满足某种消费需求和欲望的东西。对于咱们来说产品就是作为开发结果的软件，以及一些相关的工件（文档、发布版介质、培训材料）。咱们的具体产品是什么我就不多说了。产品化，我简单的查了一下Web翻译词典，大体有三个翻译：1. productization：直译，产品化，就是把东西变成产品的过程。 2. commercialization，直译，商业化，就是把东西变成商品的过程。 3. Transition，直译，转移，变迁，过渡，可以理解为东西的一种变迁或者过渡的过程。 4. 一般情况下，我们可能会采用第一种译法。但是我发现第三种用法是最国际化的，采用了中国的中庸之道，含糊不清。它是指两种状态之间的关系，表示处于第一个状态的对象将执行某些指定的操作，并在发生指定事件和满足指定条件时进入第二个状态。当发生这种状态变更时，即触发了产品化（转移）。简单的总结一下，我对产品化的字面理解。1. 产品化是一个过程。 2. 该过程中咱们要做的是把东西变成产品。 3. 产品化的结果就是要向用户交付产品，即软件和一些相关的工件。 4. 对于整个项目来说，可以对应咱们的第四、第五阶段，验证阶段和发布阶段，即将带来的是商品（一般是beta版本和最终版本）；可以使某一个迭代周期中的验证阶段和发布阶段，即将带来的是潜在商品（一般是alpha版本的产品）。 5. 产品化以发布产品为里程碑。 6. 产品化的最终目标就是数钱数到手发麻。 软件产品化其实前面说的也是只软件产品化，现在专门来说一下。软件产品大抵分为：通过软件（如MS Office）、系统软件（如MS Windows）、管理软件（如青铜器）、开发软件（如SuperMap iServer）。对于前两种软件来说，产品化就是一次开发，一万次挣钱。对于管理软件来说，产品化就是要啥给啥，改改在发，循环代码，不断挣钱。前三者良好的产品化可以降低开发成本，缩短周期，节维护费用省，迅速普及占领市场，有效改善客户满意度等。对于他们来说，软件产品化，即用户无需为软件添加或调整代码和语句即能完成软件的安装配置、应用初始化、系统管理、用户使用的全过程，并且软件至少能满足 80%以上的用户某一组应用需求。对于第四种开发软件来说，当然希望产品化跟钱三者做到一样（老板很高兴）。但它的产品化的确达不到前三者的状态（老板不高兴），当然，我们可以不断向这个方向去努力（老板有点高兴）。前两种的产品化老板也是知道，咱们是不可能（虽然他一直想这样，并不断的窃喜）。那就想第三种即管理软件学习吧，并走上具有SuperMap特色的产品化道路，让老板高兴（老板高兴，大家都高兴）。谁的产品化从上面的三点可以看出，产品化并不是研发人员的工作范围内，如果让研发人员考虑业务的发展和策划，市场细化、商业计划等那产品化的风险就很大了（老板应该不会高兴）。主要就在于研发人员对产品化的理解很有风险。前面大家看到了，研发人员理解的产品几乎与老板最关心的“钱”没有关系。老板是不会冒这个风险的，因为什么风险也没有没钱的风险大。那产品化，到底谁来做啊？这个问题就没有技术含量，一个过程不是一个人能完成的。我们看看研发中心-质量体系文件列表的第四第五阶段参与人员就知道了。我简单的列举一下：04 验证阶段参与人员05发布阶段参与人员资料开发工程师(TDE)平台项目审批委员会(PPAC)市场代表(MKR)知识产权专员(IPC)技术支持工程师(TSE)技术支持工程师(TSE)客户培训工程师(CTE)维护团队(MTT)测试工程师(TE)产品开发团队领导(LPDT)系统工程师(SE)产品开发团队领导(LPDT)配置管理工程师(CME)平台项目审批委员会(PPAC)从上面的列表可以看出，想要钱，人人都要出力。我的产品化最