comment 0

设计项目中的进度把控

手头的项目现在虽然接近尾声了,但每天还是比较忙。这个项目从过年后一直做到现在,进度落后了2个月。我是半路接手的项目,之后发现,在项目管理方面上存在的问题远比设计上遇到的问题多得多。

嗯,还是先来讲一个段子吧。

粉色的笔
  我们公司的销售问客户,你觉得是我们公司的产品好,还是华为的产品好。客户想了想说,还是华为的好。销售急了,怎么可能,你们提的需求,我们两个月就实现了,华为那边搞了四个月才出来。客户不屑的说,是,我要的是一只“红色的笔”,华为四个月以后,给我的就是一只“红色的笔”。而你们公司,两个月给我了一只“粉色的笔”,又花了四个月的时间给改成“红色的”。销售无语了。
  Hardy评语:任何一个产品都需要按照正常的开发流程和步骤进行,越着急,东西反而越达不到要求。再说了,时间都是客户压的,你们不压,我们慢慢做,怎么能做成粉色的。华为牛就牛在人家坚持原则,时间不够宁可不做,也不做一个差品出来。

对的,我想说的就这个时间,其实这是个项目进度的问题。

本来嘛,项目计划是制定的很理想的,执行起来就遇到了很多的不可控因素。

1,合作问题:

甲方为了省钱,让自己的广告公司帮忙出视觉效果图,本来,这部分工作原计划是由设计公司来完成。这样一弄,就有几个问题:

a,人员不可控,不知道对方够提供设计什么水平的人力,初级?中级?还是高级?也很难控制他们能分别投多少人力,虽然我们能提要求,但不能做决定,这个对项目进度影响很大。

b,进度不可控,因为是分开办公,我们直接面对客户,有时他们感受不到那种进度的压力,以及对一些关键点的理解会有差别。

c,质量不可控,有时要讲清楚一个问题有时会费时费力,需要多次进行“反馈-修改”的迭代,这时沟通的成本就很高,远没自己同事之间配合默契。

2,工作分配问题。

甲方为了省钱,把前端的工作量拆成了2部分:把HTML+CSS的页面制作给了设计公司,把JS编写分给了开发团队。并且,甲方告诉开发:“我们找了一个做交互很牛逼的设计公司”。开发听了很高兴:不用写JS了,太好了,还能学习学习。甲方告诉设计公司:“你们只用做HTML的静态页面就可以了,别的给开发做”。设计公司也很高兴:只做切图啊,这简单,几天就可以搞定。

于是,就出问题了:

a,设计公司方面,以为只做静态HTML页面,就只预留了很短的时间,报价也很低。结果在后面时,当设计公司把做好的静态页面给开发时,开发说不能用,然后甲方就逼迫设计公司把JS效果也做出来,为了保证开发进度,设计公司还是先做了一部分JS,然后开发就不再说什么了。但这时,因为先前没讲清楚,这就遇到了一边做一边扯皮的事情。而且,由于之前预留的时间也很短,这就使前端压力陡增,页面质量也很难保证,问题颇多,需要多次反馈修改。

b,开发方面。因为甲方最初预想是把js交给开发来做,但开发很清楚,这是前端的工作量,所以开发一直都不做这一部分,而且甲方一直都没有办法说服开发,所以这部分工作还是压到了设计公司头上。

c,关于js,甲方的失误是很明显的,由于不懂技术,就想当然的把本是一块的工作拆开来,这直接影响到了各方的计划排期、人员配置,以至于在后期面临诸多临时调整,页面的开发也是遇到诸多问题。

3,页面确认问题。

做设计,总会有意想不到的修改,因为在设计的产品没有发布之前,对甲方来说,怎么改都没关系。特别是和我们合作的多是传统行业,设计,对他们来说,很多时候并不是他们核心业务,所以他们有时候并不理解设计公司,觉得设计公司所做的事情太虚,很多时候,他们对设计能给公司带来的价值也是半信半疑,设计公司也是可以理解这一点的。

但理解归理解,并不是说,理解你了就可以让你随时无休止的修改。交互设计线框图的存在,其根本目的就是为了降低修改成本的。正常的流程是,交互稿确定之后,做视觉页面,视觉稿确定之后,做前端开发。关于页面确认,在这个过程中就出了问题。

a,设计公司方面,缺少页面确认的意识。有时多是甲方口头认为交互稿可以了,然后设计公司就以为确认了,接着等到视觉稿出来做完前端页面了,甲方说,某某页面不能那样做,某某地方做错了。这时再来修改就会很麻烦,而且甲方也不承认之前确认过。

b,关于修改,设计公司缺少评判的标准。修改主要分两部分:确认前的修改和确认后的修改。对于前者,是可以接受的,因为确认后就可以走下面的流程。对于后者,就需要定义清楚,哪些内容是可接受的修改,那些内容是需要追加工作量的修改。

c,缺少对甲方的约束。页面的确认验收应该是一个很严肃的事情,有时为了保证时间,大家多会流程从简,口头确认,当然这对于内部团队是完全可以的,但对于设计公司来讲,这种做法是会让自己栽跟头的。因为利益的关系,当对方拿不出对自己不利的证据时,人就会出尔反尔。说句题外话,很多人应该都看过那个“你们立字据”的漫画吧,或许,那还真是个有效的好方法,这不是笑话。

关于规则、定义,把这些事先定义清楚,一方面可以保护自己,把各自的责任划分清楚,另一方面也可以避免项目执行时遇到的各种反复、纠结、扯皮之类浪费时间彼此伤害感情的事情,同时,这也可以更加体现自己的专业性。

以上,是我在项目中遇到的主要影响项目进度的问题。当然,还有一些我觉得是常规的影响项目进度的问题。例如,需求评估、项目的合作执行方式、报价方式、人员交接等,这个需要单独研究,我现在就不展开了。

ok,以上是问题,接下来说说经验,主要讲讲协作。

这次做的是网站项目,涉及到的页面有近400个,算是我做过的较大的项目了。前前后后,也是涉及到了很多人。光是交互页面的线框图,最多时就有6个人同时在制作。这里就有一个很重要的问题:多人协作。协作的原因很简单:某件事一个人干不了。所以需要多个人一起来做。而协作要解决的问题最主要有两个:版本控制和冲突。

关于版本控制。以前都是通过文件命名来做控制的,那时几乎每天一个版本号,有时一天好几个版本号,文档管理起来麻烦,有时还会出错,那还只是自己做的其中一个模块,到后期时,文档逐渐变大,这个项目文档的体积也是迅速飙升,数量每天线性增长,管理上,也是越来越麻烦。虽然也有分模块来做然后再合并,但还是会遇到类似问题。其实,版本控制这件事,压根就不应该让人来做,因为它机械、枯燥、重复,而机械重复的事情是最适合交给机器来做的,机器会高效且可靠,比人靠谱多了,把这部分摆脱,人就可以拿出更多精力来思考,来做事情。

Axure

交互设计的线框图原型,主要使用axure来制作。这次,也真切的感受到axure强大的地方不在于他方便快捷的交互效果实现,而在于它能够方便的实现多人协作,你能感受到一个有效率的工具是多么的强大。这里很感谢盆地观察,他写了一系列的关于搭建Axure协作服务的文章:

axure的协作可以是基于svn的,每一次check in,都相当于一次保存,都会在服务器里保存一个版本,并有简单的文档记录,并且,可以保存从项目开始到结束的所有版本。这样就很方便的做回溯。通过多用户的建立,你也可以看到每个人每天都改了哪些模块。

另外,这次的项目让我对axure也有了新的认识:axure里的交互效果,在原型制作阶段真是一点用处都没有。

以前,经常听到有人讲,动态面板是axure的精髓,我那时也是很认同的。现在想来,那时的认同,更多是因为我处在学习软件的阶段。现在开始认识到,动态效果也仅仅是axure作为一个工具实现交互效果的精髓。对于网站的原型设计来讲,并不是一个必须掌握的东西。

为什么这么讲?

因为,就项目本身而言,交互设计的存在,其价值在于在开发前期可以用原型来快速讨论解决方案,减少后期的修改成本,因而,更需要关注的是页面结构、信息架构、页面与页面之间的逻辑关系,而这些,单纯的线框图+文字描述就足够了,那些tab切换、移动东校、表单交互的效果,真的是不需要care的。因为:

1,这个东西需要消耗较大的精力来调试效果;
2,这种效果的增加也会拖慢整个文件的响应速度;
3,这种交互效果的多人协作操作起来会比较困难,特别是复杂效果,很容易起冲突。

在使用Axure进行协作时,每次check in,它都会简单的告诉你:你修改了哪些页面,新增了哪些页面,删掉了哪些页面。但对于项目来讲,还是不够的,我们还需要更细化的记录。

Google Docs

不得不再次感叹,google是一家伟大的公司。在线文档协作,还真没找到比他更方便好用的了,虽然它在墙外。google docs的多人协作,可以实时看到大家的编辑情况,我们每天把反馈的问题整理到google docs上,让大家都可以及时看到,然后修改,改过的就划掉;然后每天将修改的页面记录到另一个文档中作为日志,这样每天都很清楚大家做了什么,这也是对axure记录的一个补充,在配合axure记录的情况下,可以清楚准确的追踪到修改的内容。这一方面方便我们自己做回顾检视,另一方面,也是我们做事情的重要证据。

上面两个工具的协作功能,不知道让我们的效率提高了多少倍,减少了多少麻烦,如果没有这些,后面的工作真是不可想象。

关于协作,就暂时说到这里,SVN功不可没。其实,使用SVN做版本控制,在程序界是再正常不过的,几乎是常识的存在。因为,编程不仅是一项脑力劳动,更是一个体力劳动,程序编写的工作量巨大,但多人配合良好,这么多年,他们都在高效的解决着这类事情,这里面必然有很多我们可以学习的方法。其实,岂止是编程,其他领域,如建筑设计、工业设计、金融、土木等各个成熟的行业,都有诸多有效的理念或经验,了解那些东西来指导界面设计的过程,会是非常有价值的。嗯,这是另外一个话题了。

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注