UED团队合作与开发流程优化

今年对我来说真是折腾的一年,年初3月份到被调到杭州去封闭开发(就是如今的雅虎口碑分类信息),半年后,9月末又回到了北京雅虎,投身于火热的“雅虎关系”中。可以说08年一半的时间在杭州做项目,感触颇多,也有很多要总结的。

谈到UED(用户体验设计)团队合作,就得先从团队的组成讲起,(接下来的描述都使用字母简称)
雅虎的UED团队配置包括:ID(交互设计师),UR(用户研究员),VD(视觉设计师)和WD(前端开发工程师)
口碑的UED团队配置包括:ID(交互设计师),VD(视觉设计师)和WD(前端开发工程师)

角色大概就是这样了,在实际项目中如何安排出场顺序就有些学问了。

在开发保姆分类行业化的时候,角色进入开发流程的情况是这样的:
之前的流程

PM(产品经理)编写PRD文档,并与交互设计师讨论,由交互设计师产出产品原型,得到产品确认后,召集VD,WD,ENG(后端工程师)开kickoff,宣布项目启动,接下来就到真正实现的阶段了。

从上图可以清晰的看出VD的介入点,原型完全结束后才开始视觉设计,产出一些效果图经确认后交有下一环节WD开始切页面、制作交互功能,WD完成所有页面后交给ENG套程序,最后联调,测试,上线。

到项目后期时间很紧张,因为项目实现一共就2周左右的时间,WD和ENG联调是占时间比较多的环节,所以经常加班到很晚。项目总结会上分析了一下各环节的配合和运转情况,ENG的工作是前松后紧,项目后期很疲惫,原因有以下两点:

  1. 前期一段时间拿不到UED方面提供的交付物,没法套页面;
  2. 与WD联调要占很多时间,WD交付时时间剩下不多,就得加班赶了。

UED成了瓶颈?还是其中哪个环节拖延了时间?
其实都没有。我们再来review一下上图,发现如下图这个区域似乎很空闲,那能否把这块利用上呢?

可利用区域

这块属于UED团队内部合作,当然我们可以想办法改变这种流水线般递推式的流程,并行开发,立体使用这块时间。来看下图:

我来解释一下,前期PM和ID的配合基本不变,但ID在这种开发方式中,所要承担的工作变的更多。
在与产品确认了原型之后,VD和WD同时加入开发,根据产品原型,前者做表现,后者做结构和行为,这也是起初“Web标准”所倡导的“表现与结构相分离”的思想,各做各的,互不影响。

注意,这次UED的伙计们玩的时候,可别忘了ENG,我们优化工作流程不就是为了帮助ENG改善开发前松后紧的状态吗!ID可以去与ENG交流:
ID:“你们要从什么页面开始做起?”
ENG:“我们先做表单逻辑,请先为我们准备表单原型、效果图和静态页面。”

ID这时候是半个PM(这只是与PM频繁换位中的一次),去协调VD和WD,并告知我们制作页面的优先级,这个优先级可以以ENG开发顺序为指导,并更快的给出相应页面经确认过的原型。
Tips:我把原型发布在局域网服务器上,可以通过浏览器访问到,这样可以方便PM确认,也便于VD、WD、ENG实时查看最新确认的原型。这样做还有一个好处就是,ID是产品原型的唯一出口,大家都到我指定的地址查看最新原型,避免因邮件传来传去,造成版本混乱,VD,WD做完一看“呀,咋都对不上呢?”

优化后的流程在做交友分类时得到使用,并收到很好的效果。同样的项目,不同的方法,可能带来的就是更高的效率。不要在项目结束以后抱怨“如果能再多给我3天,一定能把它做的更NB……” 。从项目开始时就找一个适合团队合作和项目实现的好方法,要比事后诸葛更着人喜欢 =)

参考:
1. 看千鸟整理的一个图,其中DEV应该对应我们的ENG,其中DEV应该对应我们的WD(Web Developer):

2. 还有一个小软件,能帮你快速建立起局域网共享——迷你Web服务器

UED团队合作与开发流程优化

分享到朋友圈


20条评论

  1. 哟,心弦也来了,呵呵.
    阿里你是清楚的.减少角色是方法之一.就现在的配置,如何培养团队默契,让专业的人做专业的事,是长久之计.

  2. @千鸟,借用你的图,是为了更直接的看到各岗位的能力分布,对上面我描述的一堆文字有个感观印象,呵呵

  3. WD和VD虽然可以几近同时开始做,但似乎WD可以先做的东西还是太少了,最多就是能把框架搭好,而这部分作业在一个成熟的网站框架内做的话,量是很少的,几乎用不了多少时间。反而大量的视觉实现,要等VD的图出来。因为做ID的时候,一般也会倡导尽量避免做ID就去拘泥与设计细节。。。。。@_@

  4. @Amer,别忽略了VD,也是有相关设计规范的。只有WD有框架,整体速度还是带不起来,要靠每个环节都更专业化,才能缩短整体时间。所以就要求各个岗位均衡发展,避免短板效应。

  5. 最近一段时间个10几个人的团队在一个项目,项目进展严重有问题。
    本文给了很多启示。
    ID在这你们项目中担负的职责很重啊,对能力要求很高。

  6. @William,是的,ID通常要起到承上启下的作用,这就要求这个岗位懂得的技术方面比较多,除了做好自己专业以外,相关领域知识结果越完整,工作方法就越合理,随之效率才能真正提高。当然这不是一个人的事,要带动全团队才行=)

  7. 好文章,我最近也在琢磨这个事情。
    这样子好处不用说,坏处就是一旦某个环节出现反复评审与修改,就会导致与之叠加的环节的同步修改。不过问题应该不大,毕竟在追求速度的开发中,没有太多机会去反复斟酌。

  8. 偶有问题,UED作为一个部门存在,谁来审核和检查UED的工作?按项目分,PM主导整个项目,ID相当于策划和协调项目,那么UED里的人,就是按人员分配给给PM?

  9. @Eling,目前大概有两种形式,一种是来活到UED后分配人去跟;另一种是随产品走,几个人一直跟某一个产品线.至于谁来审核UED的工作,我想一般还都是老板,很少有公司让最终用户给产品打分的吧,这部分得分直接得不到,但可以间接产生,就是根据相关的分析数据.量化UED工作才更有说服力,无论对老板还是用户.

  10. 效率是会提高,但出来的东西质量就不一定能保证了,效率不是评定产品好坏的标准。人的精力有限,1个人干3个人的活,顾得这个顾不了那个。我接触过一个公司,产品的头跟我说交互设计师一点用没有,他要求产品经理也要做交互等等。我很为这个产品担心,我完全相信他产品经理的能力,只是质疑这个头头的想法,用赤壁里的台词说就是“你过时了”

  11. Pingback: UED | 世纪无线

发表评论

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

*