讨论关于产品设计

对于产品的设计对于大多数人来说是一个困难的领域，很多组织在此问题面前显得不知所措。我经常被人问起，如何在几个类似的项目的开发过程中实施SCM（其实我认为这个时候应该考虑的是设计的整合，而非SCM制度的建立），如何面对又类似需求但是细节方面又完全南辕北辙的多个项目，如何制定一个产品的需求基线，如何确定是不是将目前的几个类似项目整合为产品的时机。客观的说考虑这样的问题并不是大多数程序员的责任，而是公司高层对于公司发展的战略把握。但是就目前状况来说，基本上很多公司的高层特别是中小公司的高层都没有这个战略决策能力，而事实上的开发决策权还是在于公司的技术群体。
至少在我看来这是我们目前绝大多数中小公司所面临的最重要问题，而且恐怕是唯一战略层面的问题。也是我们最应该关注的问题。但是在国内就这个方面的公开讨论很少，而且各种说法也很幼稚而粗糙。当然这个问题的讨论是困难而难于落实的实际的，原因在于我们还缺少相应的成功实践，其实就是相应的失败经验都缺少。但是这个问题绝对是我们目前所面对的也是最迫切需要解决的问题。
我希望大家参与对这个问题的研究讨论，但是不是踊跃的发言，而是要经过一个深思熟虑的过程，将自己的观点和设想条理化的反映出来。
让我们从确定产品化的时机开始我们的讨论，也就是从一个正像的顺序开始我们的讨论。目前的讨论应该考虑的是产品的来源是什么，究竟对于一个前景的想法是应该落实为一个产品，还是落实为一个项目的事实框架；对于已经存在的项目究竟是不是应该整合为产品；需要整合那么时机应该如何确定。请大家思考这三个问题，并作出你的回答。

这确实是一个很重要的问题。产品化似乎每个老板都喜欢听，也喜欢想象自己已经有了一个成功的产品。但是事实上，也许他不过只是有了几个成功的项目而已。

产品化的思路，当然是从软件重用而来的。将前几个项目中总结出来的可重用的部分提炼出来，打个包，然后起个名字。大多数所谓的产品也就是这样了。

但是，从项目到产品，是需要再设计的。一个成功的产品不是对于以往项目的简单的提炼，而是站在一个更高的角度上，审视过去的项目，然后设计出一个能够涵盖过去项目的产品结构来。

再者，产品化的时机与产品化的能力，需要区别对待。时机是需要判断，以往的项目，所满足的诸多需求，是否已经覆盖了这一领域（或者行业）的大多数通常的需求。而能力，则是能不能设计出一个通用的架构，来满足这些需求。

先说到这里，看看是不是ozzzzzz想要讨论的内容。也看看别人怎么说。

庄表伟
这确实就是我想讨论的问题的一个部分。
产品的生产方式和方法，与项目是不同的；更重要的是产品的设计理念和设计方法也是和项目不同的，产品的内部结构其实也很项目是不同的。但是我想现在我们还是首先应该确定到底需要不需要这个产品的出现。当然这些都是需要一个判断的过程，而这个过程所应用的数据又正好是依靠这些产品和项目的不同所作出的权衡。这是一种矛盾，一种你需要依靠你不完全知道的数据作出的一种判断。
这样的有些艺术化的讨论让我觉得兴奋，因为又太多的未知，所以必然存在更大的空间去创造。

管理学当前的一个领域，是在讨论“商业直觉”或者说“集体智慧”，就是关于企业决策的“科学性”之外的一些东西。也许对我们的讨论会有帮助，但是我也只是听说，没有仔细的了解过。

产品的来源应该来自于市场的研究和观察，不外乎，针对现有市场上已有产品不足，或者专业产品领域，或者未来可能产生重大收益的产品，或者可能对公司产品开发有作用的东西，或者是一些成功项目产品化可能产生更多的效益，或者能够为公司其他带来其他项目的东西。总的来说，产品应该能够符合市场需求，能够有发展成商品（注意是商品）的潜质。

基此，我们就可以知道，如果一个项目或者一个设想能够符合带来收益，符合市场需求，能够开拓市场，能够降低成本之一，分析完风险和成本后，如果成本、开发时间和风险能够满足要求，我想就可以产品化。

但是决定着产品化后，工作却不仅仅是在于技术上的，却有更多方面的工作要去做。一个项目如果需要1分资源，要转化成产品则至少需要9倍的资源和成本。因为你面对的用户更多了（容错性要高，易用性要好），可能很多情况下，你不能够到客户现场安装培训（容易安装部署），文档要易懂（最终客户文档，演示文档，技术文档，销售文档，解决方案），技术支持力度增大（怎么及时相应客户要求，在线支持），授权管理（怎么控制客户的安装和部署），是否支持在线升级，产品的版本控制（可能特定情况下，经常要做定制的半产品化工作，怎么把这些变更合并到主干），bug的管理。不过还有更重要的非技术因素，比如市场的宣传、造势，合作伙伴、分销网络、代理网络等等。

产品开发，应该从需求部门，比如市场、客户那里得到需求，最好需求越清楚越好，然后做界面原型，这个原型最好是跟技术不是很相关的部门来做，主要从客户的思维和操作习惯、易用性去考虑。给需求部门演示，如果通过再来进行下步的系统设计。系统设计和开发，大家都轻车熟路了：）就不多说了

我同意这种观点，我想这种判断过程就是一个评估的过程，评估这个东西作出来后能够有所收益。这个应该就在前期的风险评估和收益评估里面。

产品设计这个题目本身就很庞大了，而且现在要讨论到大概是产品设计之前的命题——要不要这个产品。

这更加是一个天马行空似的问题，不同的行业、公司、团队会有不同的答案。胖子提到三个问题：“目前的讨论应该考虑的是产品的来源是什么，究竟对于一个前景的想法是应该落实为一个产品，还是落实为一个项目的事实框架；对于已经存在的项目究竟是不是应该整合为产品；需要整合那么时机应该如何确定。”

我想为了便于讨论，是不是可以列出一个checklist，作为“上产品”之前的问题列表，大家讨论哪些问题应该放入这个列表中。

比如：
1、该行业是否有明确规范的需求
2、公司的技术人员力量
3、公司目前资金情况
4、公司组织架构
等等

不知胖子认为这样讨论可否？

wangzy就提到一系列需要考虑的好问题，可以把这些问题规范化为chekclist

怎样把做产品和做项目有效的集合起来，在实施类似项目的过程中逐渐完善自己的构架、积累起自己的组件库。最后是不是形成产品是一个水到渠成的事情。即便不是产品也没关系。
当然，我说的这个是企业项目。这类项目的关键不是产品或者开发，有很大的精力在实施上。从这个角度来看，企业信息化建设中用的产品多数也是半成品，不过大部分开放性和定制性强的产品都可以看作是半成品。

庄表伟
实际上我准备这个问题已经用了非常长的时间，但是很多地方依然感觉很困惑。
首先我重复一开始就说过的话：“但是就目前状况来说，基本上很多公司的高层特别是中小公司的高层都没有这个战略决策能力，而事实上的开发决策权还是在于公司的技术群体。 ”同时我也重复一下你说的重要的话，也是我要说的话：“从项目到产品，是需要再设计的。一个成功的产品不是对于以往项目的简单的提炼，而是站在一个更高的角度上，审视过去的项目，然后设计出一个能够涵盖过去项目的产品结构来。 ”
其实我想我们应该讨论的是技术层面的问题，而非管理层面和市场层面的问题，这些部分应该是公司的市场人员和管理人员责任，我们不可能也不必要去成为一个完人。
我们所应该作的是给战略决策层提供他们需要作出战略决策所需要的数据和我们的对于技术复杂问题的自主判断。
其实对于产品的设计问题，我最想讨论的是它和项目的不同，是它不能和项目的开发所混淆而不是和项目的开发所谓的结合。但是这个问题需要在我们搞清楚战略决策这个上游问题以后才可能很好的解答。所以我只能先提出这个问题，让大家思考。
我们要思考的是，当你的决策层认为这里存在一个需要，你是把它转化为一个产品还是一个开发框架？你的判断动机和判断理由是什么？
当你的决策层认为需要将一些项目整合为一个产品，你如何判断这个产品的开发所需要的资源是什么？
当你的决策层需要作出一个产品需要升级的时候，你需要提供的这次升级所需要的技术资源是什么？
这些基本的问题，我们有必要建立一个基础性的解决checklist，或者至少是一个概念上的理解过程。而当这个工作完成以后，我们就将讨论我最想讨论的，也是最能成为我们这个技术人所关注的产品结构设计和产品的实现的问题。