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