“沟通是产品经理的常规武器之一。在我看来也是最重要的一种武器，沟通能力不行，那么很可能就意味着你在工作中没有那么顺利。我从技术转型PM的时间不多，不过也有了一些关于沟通方面的自己的积累，现在尝试对这些积累进行实体化的总结。”

我将沟通分为以下六个方面。

1. 注意沟通逻辑

面对一项复杂的功能时，需要给小伙伴们去讲述你的产品逻辑时，一定要注意你讲话的逻辑，请确保大多数人能够在花费最少的代价，最短时间内明白你的需求，没错就要这样做，那如何做到讲话简单易懂呢？我用的方法其实就是把自己讲话的要点进行二叉树结构化（可能是技术出身，干啥都离不开技术O(∩_∩)O），从父节点开始，一个流程一个流程的讲述。不要试图想用一段话将整体内容全部概况，不现实的。既然是概况，就以为着细节是遗漏的，最后做出来的东西，跟你想象的东西大概率是不一样的。

2. 说话语速

绝大多数人在给别人将事情的时候，未经组织的发言都是自认为大家能够听懂的语言。所以PM在跟小伙伴们进行沟通的时候，一定要放缓语速，给大家一个短暂的接受与消化时间。在沟通需求时，可能一个功能需求没听懂，可能会影响下一个功能需求，毕竟产品内的功能都是关联性的。试问，在放缓语速的情况下一遍过的需求舒服，还是机关枪一样的语速，对着小伙伴们来回来去的突突5、6遍（如果他们很享受这个过程，当我白说~）？

3. 带着原型说话

老话讲，好记性不如烂笔头，其实说的就是图形界面的重要性。将需求以及交互体现在图形上来说，对任何人都更直观，更容易理解。将需求中要注意的地方一一标注出来，并写清楚为何这样，讲清前因后果以及用户场景。这样的话，在开发过程中，开发人员能够专心的进行coding，相关没遇到一个问题就需要过来提问，这样对双方都是一种很奢侈的浪费，毕竟workin/out（我给命名的，意思是说在工作时进入忘我状态，该状态下的工作效率确实是高到可怕。可惜的是，进入这样的状态所花费的时间有点长）耗费的时间却是不短。

4. 带着解决方案说话

曾经纯银大大说过这样的一段话。“推动产品观点的时候，除了论证观点的正确性，更重要的是提出观点背后一整套的实施方案(哪怕粗一点，哪怕只是可行性强的解决思路)，这样才有推动力。重要的产品改动都是牵一发而动全身，不解决“动全身”的那些疑难点，你的产品观点再怎么正确，别人的接受度也是很迟疑的，推进速度也是很缓慢的。”这段话我一直看作是我的警句。推动力在我看来其实就是大家对工作的积极性，积极性从哪里来，就是大家对工作的喜爱，我一直认为兴趣驱使工作是最轻松也是最高效的。大家对你的产品观点都表示或多或少的迟疑的时候，会带着问号去工作，试问这样又怎能全身心的投入？

5. 避免争吵，尝试从对方的角度考虑问题

在遇到双方意见不统一的情景下，需要考虑是否将需求放入了典型的用户场景中，让场景来说明一些，不要谈自己的观点，所有逻辑全都是建立在场景的基础之上的，脱离了场景，也就成了无稽之谈了。如果还是有不同意见，那么这时候要静下心来从对方的角度考虑问题，是什么问题导致对方对你提出的需求有抵触，短时工作量、开发难度亦或是觉得与其无关。经过分析后，对症下药，将这需求的完成与其KPI联系上，让他知道做完这个功能会对整个产品有多大的帮助，亦或是能在以后帮助他减少多少工作量。

PS：这些特质只是个人工作经验中的认识，不代表标准答案，仅供探讨，还望各路前辈指点。

                                                                                                                                                                                                          -----来自一野蛮生长的产品经理AJ