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