今年对我来说真是折腾的一年，年初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的工作是前松后紧，项目后期很疲惫，原因有以下两点：

前期一段时间拿不到UED方面提供的交付物，没法套页面；
与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服务器

原文链接：http://blog.b3inside.com/essay/teamwork-and-optimize-flow/

更多UI博客精选