Web2.0的理想开发模式

来源:百度文库 编辑:神马文学网 时间:2024/05/03 12:13:03
2.0是个新玩意,至少是观念上的——从内容、模式到对已有技术的重新组合应用,乃至超小型团队、超小型应用的开发方法。让我们先撇开重量级和轻量级之争,且不管确定的需求和文档的重要性,做一回离经叛道的开发者(很酷?);不同于企业应用,甚至不算一个有明确目标的系统;我们只有一些小小的想法,如何快速实现、立即推出、并根据用户反馈迅速而频繁地改进,才是我们要解决的问题。
1)演化而不是设计出来
将跌代、螺旋的思想发展到极致:哥几个说一下我们要做什么然后马上就动手了,没准相互之间都不知道彼此会做出什么东西来。开始的时候东西惨不忍睹,慢慢的今天改点明天改点,用户也跟着参与讨论,才有新特性的灵感。用户都会对新的东西感到好奇,甚至惊喜,那就到位了;这是一种跟重量级的庄重系统所不一样的感觉,很有趣的体验。
不知不觉跬积小步,聚沙成塔,一段日子之后许多功能和特性逐渐稳定并形成自己的特色,然后你会发现用户已经习惯了你的设计,对手在模仿你的设计(呵呵,已经有点晚了),于是你才知道什么是你。经历这一过程磨练的东西可真是宝贝。FeedBurner那群人玩的所谓Hackathon,无非就是这么回事。
2)界定范围,别跑远了
想法别太大,一心想干大事者必定失败。虽然有福前辈的标题有点吓人,不过道理可是真切。想得大,格局就要大,心态也不同,考虑的太多下手思虑也就太多,未免犹豫。《细节决定成败》里说把简单的事情做到极致就是绝招。
想好做什么,就别朝三暮四了,至少等把这个想法做到No.1,再说别的。耐得住、守得住才能等到“剩者为王”的那天。
3)用团队的头脑风暴代替需求文档
没可能写详细的文档,花几周写几十页的文档也太不2.0了,不是这味儿。何况文档的写作有演进的速度快么?倒不如用团队Wiki,或者内部论坛来的爽快,东西也可以顺带记录下来,免得遗忘。没有的话也得要有人记录每次讨论的要点——好主意来得快忘的也快。
4)挖掘用户反馈
用户的反馈是金子,但是又是毒药,因为用户并不真正知道他要的是什么。这一点凡是跟用户沟通过的都知道——双方讲的是不同的语言。但是用户使用过程中的动作却能真确反映设计对于用户需求的理解和最终效果。
5)需要阶段性目标和里程碑
这点更多的是对团队成员而言的。做了一段日子后总会觉得疲了,失去耐性了,需要一点激励和刺激。虽然没有需求和设计,只有想法,但是设立几个明确的结点/里程碑对鼓舞士气相当重要。每达到一个目标就应该放松一下、调整一下 :)
6)细节决定成败
用3个小时争论一个文本框的位置,也许不值。但是当一个用户就在这个框子上卡住,觉得不爽而离去的时候,你就会觉得这3个小时多么值得。对于一个设计良好的网站我是这样认为:用户不察觉设计的存在,用的很自然爽手那就对了;如果用户关注一个奇特的设计,说明这个地方太奇怪了让人没法直观到明白,就要改;用户觉得不爽,一定是某些小小的细节,比如线条位置、字体的大小等共同作用的结果,这几个微不足道的地方会使得用户离开。有必要的话可以找从没见过系统的人来量化评估交互设计.
关于用户体验、设计的人性化,是很大的学问,可以看看这些书。
以上所述,总结于众多“小而美”团队。风语者的这张“小团队、大事情”的概念图理的不错。