接地气：产品日常沟通的两个实用小技巧

文章插图
对此，作者分享了两个日常沟通中实用的小技巧，一起来看下吧。
工作中协作困难、甚至引发冲突？闭上眼睛，试想一下。你就会发现背后原因，基本都是沟通不到位。
所以，团队协作或者有效冲突管理的基础，其实更在于改善沟通环境，提高沟通效率。
关于协作沟通有太多道理和方法论，老生常谈，而沟通对于产品经理来说，就像被老板怼一样，都属于日常工作中。
所以，协调沟通的典型特征是：沟通对象丰富（上至老板，下至产品经理）、沟通链条长，沟通时间占比大。
而协调沟通能力本就属于软实力，高度依赖公司大环境，且非一朝一夕之功，说些放之四海而皆准的大道理，大家又都知道，也没太多实际价值，就结合这两天工作思考，说些务实的话，可供参考。
这两天，镜同学频繁的视频会议、评审会、各种培训讲解，运营协调，被怼之后又被怼，需要协调沟通解决很多事情，累得同时，复盘了一下，发现最接地气但有效的沟通方法，其实有两个：
第一，搞清楚对方真正的需求，明确自己的需求，一对比分析，问题的解决方案有时候自然会出现。
举个例子：
前天，我们产品部正常组织新功能的需求评审会，技术总监突然决定，这次先不让开发人员直接参加评审，他单独参加再转述给开发。
理由是开发时间紧，任务重，不能耽误太多时间，说是让产品经理单独给他评审，然后把需求文档先发给开发。
他再结合需求文档和他的理解安排具体的开发工作，开发有不懂的再问产品经理，如有需要，可以再评审。
虽然没有明确说不让公开参与评审，但事实上，就是不让开发人员直接参与评审。
产品经理当时就懵了，也协调沟通了，但是没有结果，然后就跟我反馈了上述。
一开始我也是诧异的，敏捷开发，评审会是最高效的工具，如果只是开发内部自行理解，既有偏差风险，后续还可能会有沟通成本。
于是，我去找技术总监沟通，经过深度交流，最后才了解到原来老板对技术部的KPI指标有新的调整。
新增了当月需求完成率（需求完成总数/需求计划总数）。
这里的需求就是指的是当月只要评审上会后，产品经理列入已评审的需求就算，哪怕月底评审的需求也算。（简单说，只要完成了需求上线，绩效就可能高，完不成绩效就低，那就还不如不评审）
这就明确了，这个需求开发预估需要2-3周，一旦上会评审，本月就纳入了考核，而又完成不了，就影响他们考核。
我们产品的需求是要尽快完成需求传递，他们真正的需求是不要被考核，于是，我们最终达成共识：正常需求评审，但不列入新需求，作为某需求A的子需求。
产品经理让开发参与评审有错吗？当然没有。
人技术总监说时间紧，回头再评审有错吗？也没有错。
KPI指标合理吗？似乎合理又不合理。
我们的解决方案合规吗？似乎不合规又合规。
那彼此的问题解决了吗？
都解决了，组织效能也没有受到影响。
很多时候，我们都需要挖掘背后的原因，不愿意配合一定是有他的逻辑的。
牢记：先要找到真正原因，其次才有可能找到解决方案。
第二，想要说服别人，诉诸利益，而不是讲道理。
《穷查理宝典》里不止一次提到，如果你想说服别人，诉诸利益而不是诉诸理性。
你去想，我们所谓的协同和沟通，本质上都是想将我们的想法加之他人，并希望获得认可。

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：