最近在看《Joel说软件》,这家伙插科打诨的讲述风格着实让我耳目一新,在愉悦中借鉴些可贵的经验还是蛮享受的。
在书中有一节提到了对于原型的看法,Joel认为原型不能搞得太复杂,稿纸原型是最好的方式。特别是界面的布局、色调这些东西完全可以用铅笔潦草的表示。当然Joel说得有一定的道理,但是这并不能适用于任何类型软件的开发,就像Joel在书中提到的XP、RUP这些方法学不能适用于游戏、嵌入式的开发一样。
我认为Joel所说的原型做法,适合用于产品的开发中。如果还要更详细的限制一下这个产品的概念,那就是不要直接和客户打交道。在这种情况下,原型只要做到让开发人员明白页面的大体布局、整体风格以及业务流程的走向,就已经达到目的了。而使用稿纸原型则远远比花上几个月的时间做出一个精美的GUI原型实惠方便的多。
但是对于直接面向客户的项目,或者和客户联系较紧密的行业产品,做一个漂亮的原型还是很重要的。而对于基于Web的企业应用,则要做一个漂亮的页面原型。这个页面原型不需要有任何后台程序支持,业务逻辑可以用页面间的跳转、假设的数据简单表示。
很明显,这个页面原型是有双重意义的。首先它和上面的稿纸原型一样,面向开发人员;另一面,它用于向客户展示,是和客户沟通的媒介。在项目或者产品还没有成形之前,第二点尤为重要。首先,它可以形象、具体的和客户进一步沟通,以便把握客户真实的需求;且它可以使客户对你的项目或者产品充满信心,给客户服下定心丸。
由于页面原型产生于整个工程的早期,这使得它往往与实现的结果有所出入甚至差别很大。这时该不该回过头来同步原型(当然这个原型不是稿纸原型)呢?我认为大多情况下,这是没有必要的,尤其是对于风格上的修改。修改页面原型是件费力的事情,而且很少有人会喜欢从事这方面的工作。你可以采用更灵活的方式来表达这种变化——就是Joel提到的稿纸原型,因为处于开发阶段时,就很少会有客户参与进来(不知道有多少完全采用XP),即便还有客户代表参与在面,想必他也不会对稿纸原型有何异议吧。
这时,有人会提出来:当交付的时候,客户会大叫,系统实现的怎么和当初给我们演示的不一样呢!我认为是沟通的问题,首先你在用页面原型给客户演示的时候,就要给客户将明白,让客户不要误解这就是最后要实现的样子。当然如果碰上了难缠的客户,那一切都难说了……
作为原型——不管是涂鸦在稿纸上的,还是制作精美的网页——当它们的使命完成后,就要尽早的抛弃掉。