我们每天都在通过各种方式与人沟通，但是这些沟通是真正有效的吗？我们是否总是在不知不觉中，被沟通障碍牵绊住了前进的脚步，沉浸在消极的工作情绪之中却还不自知呢？
以下是我在工作中总结的一些沟通心得，在此与大家分享。
项目中常见的沟通方式：
通过文档沟通：
- 优点：不受文字数量的限制，内容具体；便于查阅存档及日后的统一管理；适合描述功能多、业务复杂的项目；适合跨部门协作的项目；
- 缺点：不容易建立统一标准；面向不同角色，阅读时不容易找到重点；费时；理解成本高，沟通效率低
通过邮件沟通：
- 优点：打破时间和空间的限制；便于查阅记录；方便为多人发送附件；比较正式，适合报告工作进度或通报项目状况等
- 缺点：正文不适宜太长；传递信息不即时（有时容易被忽略或丢失）；不清楚语言环境有时容易误读；不利于处理争议或敏感问题
通过IM沟通：
- 优点：沟通方便；容易消除紧张情绪；截图、发送文件方便；可多人对话；适合相熟的同事之间沟通，畅所欲言；适合解决争议不大的问题，
- 缺点：容易被忽略；一些复杂的问题很难描述清楚；容易误解；查询记录时不是很方便（里面可能夹杂了不少无关内容）；不利于解决争议；过于随意，不适合说重要且紧急的问题
通过电话沟通：
- 优点：即时、有效，沟通效率较高；适合解决紧急但不太重要的问题
- 缺点：不利于传达微妙的情感；特别复杂的问题仍不容易说清楚，有可能引起误会；不方便查看图片等（可配合IM使用）；不便查找记录
面对面沟通：
- 优点：真实、拉近距离（很多误会可由此解开）；便于说明复杂问题；沟通效率高
- 缺点：无记录；沟通成本略高；多人沟通时效率可能较低；一旦陷入僵局回旋余地较小（面对面沟通时心态一定要平和，以解决问题为目的）
会议沟通：
- 优点：集思广益、开拓思路，更多角度了解他人的观点；适用于跨部门、协同解决问题、头脑风暴等
- 缺点：若方法不得当会导致效率极低（如果需要在会上做出决定，最好先提前一对一沟通，有备而来）
特点比较（世事无绝对，仅供参考）：
适用环境（世事无绝对，仅供参考）：
了解时间管理的人都知道，要优先处理重要但不紧急的事情；其次要处理好既重要又紧急的事情。因此在沟通中，要充分的重视文档、多人会议、面对面沟通、邮件等沟通方式。对于一个基层员工，要特别注意掌握面对面沟通和邮件沟通的方法。
总结：每种沟通方式都有各自的特点，很难彻底舍弃其中的任何一种，在工作中应该根据情况选择适合的沟通方式。
比如说：在项目开始之前，可以通过多人会议进行头脑风暴征求大家的意见；策划中撰写需求文档；文档写完后先面对面给其他项目人员讲述一遍思路，之后再配合IM、电话等方式即时解决后续问题；制作原型的过程中可以随时请大家在IM上提意见；通过邮件定期监控项目进度和问题；发现项目成员有负面情绪了，赶紧面对面沟通一下，……
项目中常见的沟通问题：
中国人的性格比较含蓄，又怕伤和气。既不善于主动提问，也不善于表达内心想法。于是项目中常遇到这样的情况：
1. 用文档代替正常沟通。
很少有PM发完文档，会快速跑过来给你讲一遍他的思路。这也是人之常情，人家都没问，干嘛自己要跑过去说呢。不过有文档的好处就是，别人看到不懂的地方会去问。
2. 用正常沟通代替文档
对于大型或复杂的项目，需要文档来解释说明，这是其他任何一种沟通方式也无法取代的。文档的缺失，不利于大家正确理解项目，也不利于发现问题。这样出来的结果很难令人满意。
3. 视觉或前端没看懂交互稿要表达的意思，或者是感到存在问题，却没有提出来。
作为交互设计师，我会尽量把交互稿做的精致些，配上详细的说明，但最后的结果总是不如预期理想。
4. 还有很多大家当初没发现的问题，制作完却成了大问题……
……
面对这些问题，我也在不断的思考解决方法，目前想到的如下：
1. 作为PM，还是要尽量写需求文档。首先，需求文档对理清PM的思路非常有帮助，可以通过它发现自己还有哪些地方没考虑周全；另一方面，它是设计的重要参考依据，靠简单的沟通不可能遍历到所有的用例和需求点；第三，文档可以帮助其他项目成员有针对性的提出问题，而不是感到困惑和无所适从。
也许有人会问，如果交互设计师从一开始就参与到项目中，甚至是参与需求的确定，还要写需求文档吗？答案是肯定的。需求文档可以规范的把需求要点有序的整理起来，对后续提高项目效率非常有帮助。
2. PM不写需求文档怎么办？
将心比心，没有人不热爱自己负责的产品。PM不写需求文档，一定有自己的立场和原因。作为项目组成员，可以总结自己在项目中需要知道和了解的问题，列出一份清单，请PM回答。相信每个PM都不会拒绝为大家回答问题吧。如果觉得对方回答的不清楚，可以继续细化问题，直至回答清楚为止。
3. 需求文档到底要写什么内容，是一个难题。到底什么样的需求文档能合理的概括重点内容，让后续工作顺利进行呢？我觉得这是一个长期的摸索过程，需要PM和交互、开发等角色一起讨论，通过长期的项目实践逐渐得到最适合当前团队、项目状况的文档格式。
前提是：PM及每一个项目成员要认识到大家是一个共同协作、平等互助的团队，而不是领导和被领导的关系。
4. PM不仅提供需求文档，还应向团队主要成员整体讲述一遍思路。前期沟通主要传递想法；中期沟通解决不断发现的问题，迭代需求；后期沟通确认问题是否得到解决。
5. 其他角色以此类推。
类似的项目如果做的多了，在这个过程中，就会逐渐形成规范机制，使得后面的工作越来越轻松。
通过沟通把握微妙的情感：