对此，作者分享了两个日常沟通中实用的小技巧，一起来看下吧。
工作中协作困难、甚至引发冲突？闭上眼睛，试想一下。你就会发现背后原因，基本都是沟通不到位。
所以，团队协作或者有效冲突管理的基础，其实更在于改善沟通环境，提高沟通效率。
关于协作沟通有太多道理和方法论，老生常谈，而沟通对于产品经理来说，就像被老板怼一样，都属于日常工作中。
所以，协调沟通的典型特征是：沟通对象丰富（上至老板，下至产品经理）、沟通链条长，沟通时间占比大。
而协调沟通能力本就属于软实力，高度依赖公司大环境，且非一朝一夕之功，说些放之四海而皆准的大道理，大家又都知道，也没太多实际价值，就结合这两天工作思考，说些务实的话，可供参考。
这两天，镜同学频繁的视频会议、评审会、各种培训讲解，运营协调，被怼之后又被怼，需要协调沟通解决很多事情，累得同时，复盘了一下，发现最接地气但有效的沟通方法，其实有两个：
第一，搞清楚对方真正的需求，明确自己的需求，一对比分析，问题的解决方案有时候自然会出现。
举个例子：
前天，我们产品部正常组织新功能的需求评审会，技术总监突然决定，这次先不让开发人员直接参加评审，他单独参加再转述给开发。
理由是开发时间紧，任务重，不能耽误太多时间，说是让产品经理单独给他评审，然后把需求文档先发给开发。
他再结合需求文档和他的理解安排具体的开发工作，开发有不懂的再问产品经理，如有需要，可以再评审。
虽然没有明确说不让公开参与评审，但事实上，就是不让开发人员直接参与评审。
产品经理当时就懵了，也协调沟通了，但是没有结果，然后就跟我反馈了上述。
一开始我也是诧异的，敏捷开发，评审会是最高效的工具，如果只是开发内部自行理解，既有偏差风险，后续还可能会有沟通成本。
于是，我去找技术总监沟通，经过深度交流，最后才了解到原来老板对技术部的KPI指标有新的调整。
这里的需求就是指的是当月只要评审上会后，产品经理列入已评审的需求就算，哪怕月底评审的需求也算。（简单说，只要完成了需求上线，绩效就可能高，完不成绩效就低，那就还不如不评审）
这就明确了，这个需求开发预估需要2-3周，一旦上会评审，本月就纳入了考核，而又完成不了，就影响他们考核。
我们产品的需求是要尽快完成需求传递，他们真正的需求是不要被考核，于是，我们最终达成共识：正常需求评审，但不列入新需求，作为某需求A的子需求。
产品经理让开发参与评审有错吗？当然没有。
人技术总监说时间紧，回头再评审有错吗？也没有错。
KPI指标合理吗？似乎合理又不合理。
我们的解决方案合规吗？似乎不合规又合规。
那彼此的问题解决了吗？
都解决了，组织效能也没有受到影响。
很多时候，我们都需要挖掘背后的原因，不愿意配合一定是有他的逻辑的。
牢记：先要找到真正原因，其次才有可能找到解决方案。
第二，想要说服别人，诉诸利益，而不是讲道理。
《穷查理宝典》里不止一次提到，如果你想说服别人，诉诸利益而不是诉诸理性。
你去想，我们所谓的协同和沟通，本质上都是想将我们的想法加之他人，并希望获得认可。
那我们我们单纯的按照制度、流程去推进，行不行？
答案是可能行，但有不可控的依赖条件，需要根据对接人具体分析，有些人就是好解决，好沟通，有些人就是不好协调。
另外，制度本身也是有弹性的，你肯定遇到过：对方在制度范围内，可以选择配合，也可以有完全的条件可以合理的不配合你的工作。
那怎么办？
很多时候，我们需要站在他的角度，找到对他有利，对我们需求也有利的共同点，寻求最大公约数。
这种例子太多了，比如，你想让开发高效配合你解决某个问题，对方漫不经心，你告诉他咱们得为了团队荣誉而战，得抓紧啊，有没有用呢？不置可否，因人而异。
但是，大多数情况下，不如明确说：今天这个bug要解决，不然你整个周末就得全天加班来干啦，就别想五五开黑啦。
总的来说呢，这两个方法也有递进关系，首先要找到问题的本质，其次要诉诸于利益，站在沟通对象的角度去思考。
另外，这两点都只是沟通方法，要正大光明的去思考，因地制宜，不要使坏了小心思，适得相反。
工作中，我们都不可避免地会被协同困难所打击，因沟通不畅所困扰。
这正是因为沟通无止境，困难重重，需要披荆斩棘，可前路上仍有可为师者，或为人，或为物，或为事，或为史。
我们需要做的不过是，保持谦卑之心，不停步的追赶。
正如孟子所说，不耻不若人，何若人有？
