那些年,我们一起合作时头痛的事
不做大项目,很难理解多人合作有多么艰难。真正参与到项目中,才发现责任分配模糊、懒于沟通、越俎代庖干涉他人决策等都会让项目进展陷入僵局。虽然合作中常能感受到别人给自己带来的麻烦,但我们却很难发觉自己也在给别人带去痛苦。越是自信,越难发现自己的失误。
花了些时间,总结了下自己的经验教训,又访谈了不同职位的合作伙伴和好朋友,总结了一些各个职位与其他职位合作时最头疼的事。兴许可以帮大家看一下别人眼中的自己。
产品经理
面对交互设计师的痛苦:
1. 不主动帮忙提供解决方案,而是先PK需求。
怎么办好呢:交互认清自己和岗位定义,采取积极配合的态度,多提建设性的意见;同时在需求构思阶段产品最好能拉上交互一起讨论,同时为需求寻求客观的用户数据支持。
2. 闷头画稿不沟通,画出一套自己满意的稿,却和自己预期相差很大。
怎么办好呢:建议交互画粗糙纸面稿,经频繁沟通讨论,再绘制精细纸面稿。再次确认沟通后,才用软件绘制精细线框图。逐渐细化,把矛盾逐批解决,不至于积累到最后爆发。
针对交付衔接:
1. 各个角色在交付文档后,承接人的理解会走形。
怎么办好呢:各种交付物在交接时要由负责人在交付评审会上逐条讲解,以实现充分理解。交付物只是用来备案的,不是用来沟通的。
2. 对上游的交付物和交付时间有疑问,不直接询问相关责任人,而是先来询问产品,再由产品转告。
怎么办好呢:对特定角色的工作有疑问,要直接咨询此人,同时确保产品被知会到。
交互设计师
面对产品经理的痛苦:
1. 功能点照抄竞争对手,以至于界面无需思考,照抄即可。
怎么办好呢:请产品经理讲清楚每个功能点背后的用户需求和真实的生活场景,描绘该产品对用户的生活会带来怎样的帮助。
2. 需求思考不清楚,经常变更。
怎么办好呢:争取参与前期的需求制定阶段,辅助产品经理讨论清楚用户使用场景和功能点,然后再列述下来。各合作方在需求评审会上公开确认需求。
3. 过度干涉控件布局等细节。
怎么办好呢:产品经理应首先专注于挖掘靠谱的用户需求,并清晰地列述功能点和帮助用户实现的目标。这些用户目标就是用来衡量交互方案是否有效的客观目标。切忌用主观标准否定设计方案。
面对视觉设计师的痛苦:
1. 以美观之名更换控件,扰乱任务流,忽视对相关页面的影响。
怎么办好呢:交互应该设计中期就拉入视觉一起讨论,让视觉知道每个控件的用意,同时坦然接受视觉对交互方式提出的合理建议。
2. 调整控件布局,扰乱元素的主次关系
怎么办好呢:同上。
视觉设计师
面对产品经理的痛苦:
1. 用主观的“我不喜欢、我觉得不好看”来否定设计稿,无法用客观的词汇描述预期效果。
怎么办好呢:产品经理应该将对视觉方案的要求书面留档,并以此为作为评估设计方案的客观标准。
2. 经常变更需求,并且天真地认为所需要做的调整超级简单,一秒搞定
怎么办好呢:产品不要低估调整视觉方案的工作量。视觉也可以在初稿阶段试试产品经理的口味,多倾听一下彼此的意见。
3. 对自己的审美能力很自信,对设计稿指指点点说“要这样移、那样调”
怎么办好呢:视觉风格方面产品经理应充分信任视觉设计师的审美能力,给建议时也要态度诚恳,淡化盛气凌人的感觉。
面对交互设计师的痛苦:
1. 布局控件时不与视觉沟通,直接丢一套线框过来。
怎么办好呢:交互邀请视觉参与线框图的设计阶段。
2. 设计的交互稿没新意,太老套死板,了无趣味。
怎么办好呢:交互要多玩多看多体验,丰富自己的设计储备库,以便厚积薄发提出让人眼前一亮的设计。
面对开发工程师的痛苦:
1. 改参数,并坚称自己做的更美观。
怎么办好呢:视觉对于自己责任范围内的设计稿参数标注要尽量详尽,给出完备的视觉设计稿作为客观的衡量标准。在开发完成后要及时走查,并跟进问题的解决。
2. 不用切图素材,用代码来实现效果。
怎么办好呢:视觉首先要确保给出的切图素材十分完备;开发也要克服惰性,将视觉素材充分利用起来。
3. 对像素、肌理、阴影不敏感,看设计稿不仔细,实现效果与视觉稿差异很大。
怎么办好呢:对开发容易忽略的视觉细节,视觉设计师要与面向开发讲述。交付的设计稿只是备案,不是高效的沟通方式。开发同志们是没有视觉那样的像素眼的。
开发工程师
面对产品经理的痛苦:
1. 对产品前景没有充足考虑,每次发新版本代码都需要推到重来。
怎么办好呢:产品经理要明确产品发展的大方向,并将远景清晰地阐述给合作伙伴,以便开发在搭建程序时为未来留好空间。
面对交互设计师的痛苦:
1. 设计稿缺少细节:每个页面可响应事件的区域,响应的动作,操作成功和失败的反馈。
怎么办好呢:交互设计师除了描绘页面之间的跳转关系,还应该将页面内部所有的事件响应文档化,减少开发的误解。不要怕麻烦。
面对视觉设计师的痛苦:
1. 没有定量标注设计稿的每一个细节。
怎么办好呢:请视觉认识到定量标注细节对于开发无损地实现视觉稿的重要性。开发是没有精力去猜或者量一个特定参数的。
2. 切图不完备,遗漏细节,需要开发自己用代码补。
怎么办好呢:每一个细节的素材都切图切出来,并系统地使用文件名命名方法,帮助开发理解。
一遍看下来,有没有觉得背上冒冷汗呢?一切依着自己的性子往前走,真的很难发现自己有哪些地方做的不对,不知不觉就给别人留下了心灵的创伤。其实合作也很简单,多积极参与一下上游的决策,知根知底;多耐心向下游讲解一下那些只存在于自己脑子中的主观想法,倾听一下他们的建议和疑惑。多往彼此那边靠一靠,心就能挨得近一点。
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:CDCer 来源: 腾讯CDC
- 标签: 合作
- 发布时间:2012-04-22 14:51:02
- [55] Oracle MTS模式下 进程地址与会话信
- [55] IOS安全–浅谈关于IOS加固的几种方法
- [54] 如何拿下简短的域名
- [53] android 开发入门
- [52] Go Reflect 性能
- [52] 图书馆的世界纪录
- [49] 【社会化设计】自我(self)部分――欢迎区
- [49] 读书笔记-壹百度:百度十年千倍的29条法则
- [38] 程序员技术练级攻略
- [32] 视觉调整-设计师 vs. 逻辑