产品

最近一直在思考产品规划和产品设计研发的事情，原来谈的比较多的都是关于咨询和实施方面的内容，而对于软件和信息化行业来说，真正可持续的盈利模式仍然是有核心竞争力的产品，能够在垂直细分领域具备有定价权解决实际业务核心问题的产品。有时候我们在考虑类似ERP类综合管理软件产品化的困难，但是实际在某个垂直细分领域，进行核心产品开发并实现产品化是完全可行的思路。

一个好的产品应该是强化业务建模能力和水平，弱化实施人员能力水平，当前阶段要再发展能够刻录张光盘就大卖的产品模式会越来越困难，但是这并不代表产品会全部走向大量的定制化。这里面的核心就是前期的业务建模能力，业务建模和模型设计清楚了，产品本身实施就应该很简单快速的完成，这将是后续产品发展的一个方向。或者可以说，一个好的产品将逐步向一个产品平台发展，在产品平台不断的演进和实施过程中，逐步的迭代增加各种特性的按行业和业务细分的工作包。

一个好的产品一定是解决业务问题并达到业务目标，没有前期的业务建模和全局设计导入，那么好产品可能滥用而变成一个坏产品，所以这本质不是产品出了问题，而是产品使用过程中出现的问题。举了例子来说，现在各个大厂家基本都推出有自己的大数据平台和解决方案，从总体架构来看相差并不大，包括分布式架构，MPP，Hadoop框架的集成，实时流处理等。从这个点上来说，只能算一个平台，那么这个平台能否用好，能否真正解决好业务面临的大数据场景和问题，不是产品本身能够解决的，更加重要的还是业务建模和产品实施过程解决的。但是一个好的产品能够做的是，业务建模本身复杂度很难降低，那么产品本身的实施复杂度一定是可以简化和自动化。咨询和实施都难，在产品的推广过程中带来大量的人力成本消耗和投入，那么产品本身的价值已经很小。

产品不要考虑大而全，而是根据业务场景和需求解决实际的业务问题，那么在这个思维下小产品一开始就应该按照产品组件的模式进行总体架构和设计，方便后期的多个产品组件的进一步功能组装和整合。在产品的研发中需要进一步强调基础平台，所有的产品组件都需要基于基础平台，基础平台+产品组件模式方便后续总体的大产品规划和迭代演进模式。

在产品研发的过程中我们经常借鉴各种开源的产品和项目，经过最近多年的思考，对开源项目的全盘复制和简单的二次封装相当不好。一个完整的开源项目往往满足了诸多的应用场景，设计了不同的功能组件和接口，虽然很完整，但是细节的点上往往做的并不好，即我们花费了大量的时间去将需求适配到开源项目的产品架构上，并容忍大量无用的功能的存在。很多时候我们更应该是对开源项目源代码和设计思路进行借鉴，对底层的各种开源小组件进行复用，而不是对整个产品。在我们进行产品研发过程中，本身也应该有一种开源精神，特别是淘宝大量项目的开源是一种很好的榜样，各个团队都应该学习，有时候只有乐于分享，往往才容易挣脱自我的屏蔽，加强和外界的交流和讨论并加速团队和产品的成长。

一个短期吸引眼球的产品往往更加注重的是前台界面展现和功能，而一个能够深耕细作的产品则更加注重后台领域层能力再是前台展现。特别是我们在规划和研发产品的时候，一定要抓住产品的核心能力，特别是产品的高可靠性，大并发下的性能等，其次才是如何呈现和交互设计的问题。底层设计和能力开放要花时间做扎实，此为产品立足之本，前台功能交互设计要体现足够的简单易用，只是用户的切实感受。对于传统的纵向的产品开发模式，后续完全有可能按横向分层模式进行分组和设计，我最近在思考领域建模和设计的时候，更加关注朝这种模式转型的可行性。

技术是为业务服务的，没有最好的技术，只有能够匹配当前业务需求并具备持续扩展能力的技术。如果不能解决最终的业务场景下的实际业务需求，那么就谈不上一个产品，产品最终的价值是实现业务需求后带来的附加价值，而不是产品本身采用了什么先进的技术，分层的架构。因此我们在构思和规划一个产品的时候，一定要考虑产品的最终用户，产品解决的细分后的业务场景和问题，产品本身能否带来业务流程效率的提升等。

一个完全不需要任何定制开发的产品研发和设计，往往需要付出成倍的工作量，指数级的产品研发复杂度的增加，因此一开始不要去考虑这种模式，而应该更多的考虑特定的业务领域和场景，后续在真正的产品实施过程中经验积累后不断的再对产品进行重构和能力提升，只是一个开始产品必须具备这种可扩展的能力。

产品不缺界面和交互，缺的是一种气质；不缺功能操作，缺的是一种灵魂；不缺纵向操作，缺的是横向协同；不缺系统分析和设计，缺的是业务分析和建模。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密