那些年，我们一起合作时头痛的事

会计考友

【简介】
　　不做大项目，很难理解多人合作有多么艰难。真正参与到项目中，才发现责任分配模糊、懒于沟...
  d: s  P& ~  i/ W  I& k' ?+ a
- T, F, `) w; n5 E
5 m  v6 `9 w( [. o: a

　　不做大项目，很难理解多人合作有多么艰难。真正参与到项目中，才发现责任分配模糊、懒于沟通、越俎代庖干涉他人决策等都会让项目进展陷入僵局。虽然合作中常能感受到别人给自己带来的麻烦，但我们却很难发觉自己也在给别人带去痛苦。越是自信，越难发现自己的失误。
　　花了些时间，总结了下自己的经验教训，又访谈了不同职位的合作伙伴和好朋友，总结了一些各个职位与其他职位合作时最头疼的事。兴许可以帮大家看一下别人眼中的自己。
7 {4 G0 g+ w" x产品经理
- l- P8 c4 T8 g+ W

& J2 D: A2 _0 n* b1 {( c4 |( s
) K0 ^3 [* q8 k, z面对交互设计师的痛苦：
% k" _& {; i1 r' F- S: n9 l& W　　1. 不主动帮忙提供解决方案，而是先PK需求。
　　怎么办好呢：交互认清自己和岗位定义，采取积极配合的态度，多提建设性的意见；同时在需求构思阶段产品最好能拉上交互一起讨论，同时为需求寻求客观的用户数据支持。
5 H  Q8 B: Q' T/ e) w3 H　　2. 闷头画稿不沟通，画出一套自己满意的稿，却和自己预期相差很大。
4 U* D: J3 [$ y　　怎么办好呢：建议交互画粗糙纸面稿，经频繁沟通讨论，再绘制精细纸面稿。再次确认沟通后，才用软件绘制精细线框图。逐渐细化，把矛盾逐批解决，不至于积累到最后爆发。
1 W! j+ P% ~* ]3 ~- N5 o- V9 `针对交付衔接：
6 w8 Q+ ^8 g; T: ~; L: e  C  O　　1. 各个角色在交付文档后，承接人的理解会走形。
/ h! R  L. Z4 C1 u　　怎么办好呢：各种交付物在交接时要由负责人在交付评审会上逐条讲解，以实现充分理解。交付物只是用来备案的，不是用来沟通的。
　　2. 对上游的交付物和交付时间有疑问，不直接询问相关责任人，而是先来询问产品，再由产品转告。
　　怎么办好呢：对特定角色的工作有疑问，要直接咨询此人，同时确保产品被知会到。

交互设计师

  B: C/ _% j6 X& ?0 O( V
1 I" O* k1 N1 t7 ^7 V面对产品经理的痛苦：
. i1 p; n% m0 ?# U　　1. 功能点照抄竞争对手，以至于界面无需思考，照抄即可。
　　怎么办好呢：请产品经理讲清楚每个功能点背后的用户需求和真实的生活场景，描绘该产品对用户的生活会带来怎样的帮助。
+ J: ~/ S9 G$ f/ _+ ^! R" G9 W5 f　　2. 需求思考不清楚，经常变更。
　　怎么办好呢：争取参与前期的需求制定阶段，辅助产品经理讨论清楚用户使用场景和功能点，然后再列述下来。各合作方在需求评审会上公开确认需求。
　　3. 过度干涉控件布局等细节。
: Z' \' O$ m4 U　　怎么办好呢：产品经理应首先专注于挖掘靠谱的用户需求，并清晰地列述功能点和帮助用户实现的目标。这些用户目标就是用来衡量交互方案是否有效的客观目标。切忌用主观标准否定设计方案。
面对视觉设计师的痛苦：
2 H; o# F+ I) ?$ T' [　　1. 以美观之名更换控件，扰乱任务流，忽视对相关页面的影响。　
　　怎么办好呢：交互应该设计中期就拉入视觉一起讨论，让视觉知道每个控件的用意，同时坦然接受视觉对交互方式提出的合理建议。
0 b' F+ r$ `9 z　　2. 调整控件布局，扰乱元素的主次关系
: h8 {( W/ W9 ]) t/ R& U8 N) r　　怎么办好呢：同上。