如果非要概括性的来总结下沟通的重要性，可以参考经典沟通书籍《沟通与说服必读12篇》中对沟通作用的说明（要提升沟通能力，我个人强烈建议你好好看看这本书）：
沟通有利于消除彼此的误会，确立互信的人际关系。
有利于同事之间营造良好的工作氛围，增强组织的凝聚力。
有利于协调组织成员的步伐和行动，确保组织计划和目标的顺利完成。
有利于改善人际关系社会是由人们互相沟通所维持的关系组成的网。
书中大概是这样说的，我记不太清。下面我们具体来聊聊沟通在团队协作中的重要性。
你在工作如果遇到一个问题，你会怎么做？马上转头问一下身边的同事？还是先考量一下这个问题的所有已知信息，看看缺少哪些重要信息，是否有途径获取这些信息，然后再分析一下问题可能造成的影响，以及造成问题的原因。如果发现造成问题的原因未知，但影响恶劣，你是否会准确地找到能帮你分析问题原因的同事，并且请求Ta帮你一起解决这个问题，消除恶劣影响？
今天遇到一点小事，让我近期积攒了很多对于沟通效率的感概一下子激发了出来，想写一写这个话题。
下午的时候，测试的同事递给我一个测试机，说“快帮忙看看文案有什么问题！“，我接过手机一看，是一个转账的页面，于是我问同事”你是说文案有错误，还是感觉有哪个场景缺少文案？“同事回答道：”我觉得这个转账的文案有缺陷。“我黑人问号脸”缺陷?!“感觉还是不够具体。之后又来回沟通了10分钟，我终于明白了同事的需求，问道”你是不是想让我帮忙想想这个转账的页面还有哪些可能的场景？“同事点头。
这是让我非常纠结的10分钟。我在工作中经常碰到这种情况。这让我不禁想起曾经远程办公过的前公司，同事们在沟通中用的语言往往都是非常清晰地表达核心问题。并不是说现在的同事就素养不高，我猜测可能平时大家非常忙，一忙就容易乱，团队从来没有思考过沟通效率这个问题。而这个问题其实非常重要，很大程度上影响着一个项目的整体进度。
从刚开始工作，我就慢慢养成一个习惯，在写邮件里，清晰地向对方说明，”我做这个事情的目的，我打算如何做，我需要你帮忙做什么“。并且我会把期待对方做的事情加粗甚至标红。
工作中与同事沟通，请尽量将你的需求和问题具象成一条可执行的任务。如果有必要，再附上简单的Context说明，也就是为什么需要这么做，让同事理解Ta完成了这个任务能帮你解决什么问题。
最近在看二爷邱岳在”极客时间“上的专栏，他提到，需求变更往往是因为产品经理对于用户需求的分析出现了偏差，而导致满足需求的手段发生了调整。我深以为然。同理，在日常工作的沟通中，如果因为你的表达而使同事没能正确理解你的需求，导致返工，会非常浪费时间和精力，你也会落一身的埋怨。
工作中，我还有一个特别让人头疼的烦恼——我司PM写的PRD全是文字，偶尔配上一两张截图。PM喜欢用纯文字来描述功能逻辑，这让阅读PRD变成了阅读理解，难度颇高。有一次我为了理顺自己的思路，在读完PRD以后，花了一下午的时间画了一个逻辑流程图。在分享给设计和开发同事后，得到同事们的纷纷好评。因此，如果有必要，在日常工作的沟通中，如果有必要，除了口头表达、文字表达，请尽量尝试图表、流程图、思维导图等形式来表达你的需求，真的能让执行方省掉很多做阅读理解的时间。不管你是做什么样的工作，只要在工作中需要与其他同事沟通，该原则都可以适用。
此外，我认为沟通之前，有必要先彼此之间建立稳固的信任。在日常工作中，即使沟通的表达没有问题，但是落实到实践上，还是会有延误甚至由此引起的争吵。我虽然不是PM，但是却作为局外人，经常旁观这样的争吵，总结起来， 认为问题出在产品和开发之间的信任度上。也就是说，开发同事不信任产品，认为产品的需求都是垃圾，没有经过很好的思考和数据的推演，而是产品自己异想天开的需求；与此同时，产品经理也不信任开发同事，认为开发对他的需求提出异议，只是因为过于懒惰不想干活，对于需求则是能拖就拖，不想配合他完成任务。
我的室友也是做产品经理的，用他的话来说，那就是产品经理要么凭专业实力，要么凭自己的个人魅力，总之要先征服开发的兄弟们，之后的工作开展起来，才会比较顺利。
关于工作中沟通的小事暂时吐槽到这里~
