今天和老大谈话，老大提到产品思维和用户思维。说在和客户沟通时，客户说用友金蝶SAP是产品化思维，你们公司（作者删除20字）是用户化思维。我们更喜欢用户化思维的企业。
什么是产品化思维什么又是客户化思维？
产品化思维并不是单指做产品，而是指一种做系统做项目的理念，就是，在考虑用户需求，提供1解决方案时，优先是考虑自己产品的特性，从产品出发，让客户匹配产品，解决方案更考虑普适性，而减少考虑个性化。这种做法的直接后果客户响应周期长，就是降低了客户的满意度。但是有利于自己产品的完善和发展。产品化思维的第二层意思就是，无论是做产品，还是做定制化开发，都要抱着组产品的心态去做，才能做好，这样做出来的项目才有生命力。
客户化思维则反之，一切以用户需求为导向，用户指哪打哪，缺乏自己的专业立场，目标是最大化提高用户满意度，一般采取贴身服务方式，立即响应，积极迅速，用户满意度高。这类企业一般缺乏产品，以定制化项目为主。用户当然欢迎这种思维。
其实这两种思维是一个硬币的两面，只是侧重点不同，各有优缺点。最完美的结合就是，以产品为核心，为基础，结合用户需求提供定制化方案，就是产品+定制。
我是赞成产品haul思维的，无论是做产品，还是做项目。
产品化思维的特点就是，在碰到一个需求时，要对需求进行抽象分析，归纳总结，满足须有，而不囿于需求。考虑需求的普遍性，给出一个适应大多数具有同类需求的场景，采用业界规范的处理模式，来实现需求。这就比如艺术来源于生活但高于生活，同理。
具有产品化思维的人要达到一下要求，一是有丰富的开发经验，而是有丰富的领域知识，再要熟悉设计模式和业务模式。设计模式大家都知道，就是单例模式，装饰模式，订阅模式，观察者模式等等 18大模式，设design pattern 中有讲。业务模式就是业务规范，对某一业务场景、业务类型的标准实现方式，从软件复用的角度讲，业务模式实现的是就是大粒度的业务组件。
产品化思维的模型如下：
（1）收到需求，对需求进行抽象分析，归纳总结，结合自己的领域知识和业界标准（技术领域的标准，业务领域的标准），设计实现方案
（2）基于设计方案，按照工程化的方法，采用设计模式，基于OO、以及面向接口的思想、同时考虑插件式、个性化入口的扩展方式，用组件化的思路，进行详细设计，开发和测试，到最终交付
（3）将开发的组件交付项目使用，验证，并进行优化。
这三个环节形成一个闭环。确保交付的组件，满足业务需要，通过配置一定程度上满足个性化需求，质量稳定、可扩展的，使用场景较多的可复用组件。
产品化思维对人和组织的要求：
（1）产品化的理念深入人心，在组织层面大家要达成共识
（2）产品化委员会（名字不重要），它的职责是制定开发标准，产品化开发流程，发现公共组件，评审甚至设计组件实现方案（技术层面，业务层面），监督产品化开发流程的贯彻执行。委员会成员技术专家，业务专家，项目专家，并且有绝对的权威。在软件开发领域没有民主，只有集中，就像pm一样，技术权威和业务权威时必须的，否则很容易乱套，文人相轻，技术业务也一个尿性，没有绝对权威，绝对是自说自话，山头林立。说道这里，有人会说，经验在丰富的人也会犯错误，怎么能不讲民主呢？这背后的逻辑是，经验丰富的人，10件事中可能会犯1次错误，菜鸟10件事中会犯9次错误。
（3）老大一定要坚定支持，并绝对相信并授权委员会。
（4）产品化组件可以来自专职的团队，也可以来自项目组。
（5）用工程化和项目管理的理论知道下，确保项目过程、开发过程透明。只有这样，才能确保项目外部人员，项目内部成员，获取项目资产，从中发现可能的公共组件。
从某种意义上来讲，产品化思维是利己（最终利客户），是自己的利益最大化；而用户化思维则是利他主义（乐了客户，苦了自己），客户的利益最大化，造成的后果就是我们可能服务最牛逼得客户，但是自己过得确很苦逼。因此我绝对支持产品化思维。