“原型”的几层意思 （转）

大中小

2007-4-4 14:22:12【作者】 姜玲 【进入论坛】

本文关键字 ttnn 2006年05期

刘庆 20060511

昨天，在公司等着报销呢，两位不大认得的同事过来，想了解一下客户需求的问题，因为他们奉旨开发"原型"，我对他们说的原型不是非常明白，到底是个什么玩意儿。从他们的迷惑中看，似乎也不怎么了了。之前，曾听起过这么一回事，要针对几套方案开发一些东西，其目的呢，我猜想一是用于售前演示，二是作为产品化的前奏。

从二人游离的目光中，我以为他们并非真的想从我这里得到什么信息，恐怕只是领导的要求吧，跟我意思意思而已。因此，也没有多少热情跟他们说，说一些不用负责任的言论当然简单，信口开河而已。现在都想不起来当时说了些啥。

晚上在旅途中，闲来无聊，不禁寻思这个事。他们的困惑之源还是在于，不知道这个"原型"其目的究竟为何，无从下手。可以试着将它展开一下。

说起"原型"，是软件工程里面常见的词，可以是prototype，可以是demo，也可以是POC。现在在集成商、厂商那里，称呼为POC是比较流行的。它的全称是Proof Of Conception——概念证明。可以认为它将主要精力放在与用户交互的环节上，譬如说"仪表盘"，第一次听到这个词，会奇怪，你给他解释，"就像汽车里面的仪表盘，能够指示出一些性能指标的进度，并起到告警作用"。即便如此，还是抽象的，因此就做一个实实在在的界面给用户看。哦，有些指标可以用红绿灯来表示优劣程度，有些真的可以用跟汽车仪表盘差不多的东东展示，而且用鼠标点进去，还可以查看到明细。原来这就是"仪表盘"。

可以看到，POC的目的是偏向局部的，面向功能的。客户问，"啥是即席查询？啥是专题？啥是星型模式？"这些都可以一一用直观的界面表示出来，然而他们是割裂的，是系统内部的事。

POC给客户以直观的认识，它对客户说，"我做给你看"。

但转念想想，这种POC是解决了客户对概念模糊的疑惑，也就是说已经知道了问题所在，知道了这些概念是为解决它而提出。但在BI应用，还有很多问题有待抽象，因此还没有到概念这一步，首先要给客户证明的，是一套解决方案。

集成商就是干这个的，应标的时候，会给出方案建议书。可惜看看建议书的内容，大多不会将客户遇到的问题介绍清楚，多数是给出一些产品的组合，这未免流于形式了。其实，这种解决方案是要将企业的组织结构都协调起来，并非仅仅是产品组合和功能。例如，一个经营分析系统，在建议书里面给出若干中应用，报表、OLAP，那么这些应用都是哪些部门、哪些人员、在什么时间点用到呢？能否提供一个"场景"直观表达方案的应用呢？这样的方案书太少。

可是这种方案不像POC那样有形，POC可以是机器上的一个程序，运行起来可以交互，而解决方案原型，可能有软件界面，还可能有预定的流程、模拟的角色、操作场景。因此，它告诉客户说，"这事得这么干"。

如果说POC和解决方案原型都是向客户表达最终完成的系统是什么的话，所谓"原型"，还有一层意思，那就是面向项目实施的，可以称之为"试验田"。

在BI项目实施中，类似的项目、类似的业务，却因为项目组的分散，缺乏集中控制，因此诸侯割据，大家作项目的方法，甚至结构都相差甚远，实施成本非常高。因此，形成实施方法论，作标准化，甚至产品化也是很多人关注的话题。早先，曾设想过一种方式，让BI实施人员作模型、作ETL、作报表，都像是在士兵装卸枪支。

这需要建立一个演练环境，尽量跟实际环境相似，模拟数据源接口、数据仓库模型、ETL，以及前端展现等，其中最难模拟的是数据量和需求变化，除此之外，剩下的工作就是从复杂到简单的抽象过程（当然，这也非易事）。在这件事上，自己曾经开了个头，之后却因为不在其位，也就不谋其事了。但想想，有这样一个环境确实是好处多多，可以让客户看到实实在在的效果演示，可以让项目组成员快速掌握实施方法，可以对分布的项目组进行统一的指导。

Painlet 20060511

在软件工程里学过原型开发模型，个人理解，对于应用软件来说，就是搭个架子，先完成最简单的一个代表流程，然后不断修改扩充迭代....

------------------以下为引用--------------------快速原型法(rapid prototyping)快速原型法是近年来提出的一种以计算机为基础的系统开发方法，它首先构造一个功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。原型就是模型，而原型系统就是应用系统的模型。它是待构筑的实际系统的缩小比例模型，但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改，直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。

Sunforward 20060511

原形从目的上扣太宽泛了，我觉得可以理解为是个时点概念。缩小比例，试验功能、验证业务可用性模型都是原形，功能齐备完善的也可能是原形。原形是当前产品的前身，自然也包含了验证时的各个功能体。

Kkidd 20060512

新发现这个地方，不错。感觉原型在bi中做前台操作比较适合，能够演示即将开发的东西要做成什么样子，如果用文档，来描述和客户确认比较麻烦，后台的数据做原型好像比较难吧,没有见过.

刘庆 20060515

kkidd说的这个"原型"我理解就是POC，是一种辅助沟通需求的手段，是面向客户的，也就是适合前台操作。而另一种后台的数据作"原型"，其实就是上面提到的试验田，是面向项目实施的，帮助项目成员迅速掌握实施方法的。也许最初的"原型"的本义并没有这种含义（没有考证，不知道），但在人们说起这个词的时候，有时候确实包含了不同的意思。 其实也可以理解后面这种"原型"是辅助沟通架构的手段，一般来说，虽然有架构说明书，有一些什么实施规范，但文字的东西当然比较难懂，如果又实实在在的程序、接口表现出来，那当然一看就明白这个架构是什么了。例如ETL吧，你规定了每个job应该这样命名，流程应该那样运转，如何去测试一个job，如何去重新运行一个流程，哪些些忌讳的东西，有个系统演示给项目成员看，岂不清晰。并且，建立了这个环境，就可以在此基础上进行优化实施方法，例如有些项目的数据量过大，那么可以考虑在这个原型中尝试新的流程控制，例如分地市处理（当然，此中的缺陷在于无法模拟实际的大数据量，所以无法去优化性能调优方法，只能优化流程）。  这跟很多企业的培训教室也是差不多的，每个员工上岗，需要教他们一些规矩，每天干什么事，该干什么不该干什么。对于那些项目实施比较分散的，这种试验田式的原型系统的确挺有必要的。