今天跟领导吃饭讨论起这个话题，虽然这已经是一个老生常谈的问题，但是每次提起都会引起很多的讨论。人人都知道产品化的重要性，但是如何落地一直都是困扰传统软件从业者的难题，借此机会 谈谈自己的看法。
首先很重要的一点是明确产品化的目标，回答清楚为什么要产品化。产品化不是最终的目的，而是通过产品化提升项目快速交互能力。交付即是说明产品质量得到用户的认可，通常是产品通过帮助客户完成业务工作 ，或者帮客户达成某种业务目让客户感到满意，因此产品化的基本工作是满足客户需求，并提供具有创新性的解决方案，是外在目标。而“快速”二字要求产品化过程中要从分考虑产品功能在不同项目中的复用性，从而减少重复投入，降低维护成本，这是产品化的内在目标。
明确了产品化的目标，我们需要思考如何在公司内部实行产品化。在这之前我们需要明确几点认识。第一，产品化要解决的不是技术问题，而是一个复杂的管理问题。产品化思维应该固化为一种意识存在于公司每一个人的脑海中。大到每一次业务的决策，小到每一行代码的编写，都应该问一下自己，这个决定和写下这句代码是否有利于产品。
做产品的第一个要求是专注。决策者要考虑是否需要安排专门的人进行基础数据产品相关工作，让一个人同时做产品又做项目是不可取的，因为做项目的目标和做产品的目标是不同的，甚至很多时候是冲突的，一般人很难平衡处理这个问题。
做产品的第二个要求是坚持。当项目人手吃紧的时候，决策者能否坚持不让做产品的人员投入项目之中。这样的选择每天都在遇到，管理者必须时刻询问自己，这样做是否有利或者不利于产品化推行，决定了做产品，就要坚定不移执行下去，不要因为一时应急而扰乱产品计划，最终让产品化成为空谈。
做产品的第三个要求是复用。一个技术负责人在觉得开发某个模块或组建的时候，首先应该询问自己这个模块是否已经被他人实现过。而一个程序员在准备编写某个类或者接口的时候需要有觉知地询问自己这个类或者接口是否已经被实现。有意识的地考虑考虑是否有现成的成果可以为我所用，更多的时候做产品是整合而非创新。避免同样的成果在公司内部有多个版本，大道一个组件模型，小到一个接口和函数。通过建立技术评审或者代码走查机制可以避免重复的劳动。
做产品的第四个要求是迭代。天下武功唯快不破，产品化的修炼要求以快速迭代为推动力。做产品不能像项目那样需求，设计，开发，测试，部署一条龙呆板实行。这样的方式即便是用在现在的项目上也存在很多问题。产品迭代的思想中最重要的两个概念是周期性和完整性。周期性要求在明确产品总体目标的前提下，对产品目标进行分解，按照一定的周期进行设计、开发、测试、部署。通过汇报收集反馈，并作为下一阶段产品优化的内容。完整性要求产品每次迭代汇报都以完整的流程为基础，也就是要求我们快速将完整产品骨架搭建起来，在此基础上不断完善功能，避免一上来就陷入细节。
产品化道路不会平坦，在一个传统项目型的公司推行更是难上加难。要求从老板、管理层、技术层都统一认识，强化产品化意识。在产品和项目之间做好平衡和取舍，基于自身状况指定可行的产品计划，稳步推进。对于产品化之路，用那句老话来说就是方向对了时间就是朋友。
