同级别沟通协助技巧与案例分析

这种沟通的情景还是很多的。
例如，当你与同事在某个事情上须要合营时，或当你的部门与其他部门在事情上须要协作时，都会发生沟通的情形。
这里所说的情形紧张是指须要对方做出改进、改变的场景。

二、同级别互助沟通中常日发生的问题

由于须要对方做出改进、改变，很可能会涉及到一系列的问题，比如：

我认为你该当有更大的格局。
我之以是这样说，是由于不是所有人都能客气谛听别人的见地。
作为凡人，人们常常是第一韶光采纳“防守”的心态，而这种心态会造成不合营。
因此，作为沟通发起者的你要做好生理准备，把自己的格局放大一些，以避免无效的“争吵”。

在放大你的自身格局，先管理好自己的心态的条件下，我建议：

1. 明确沟通的目标

在沟通前确定自己与对方沟通的目标是什么，即如果沟畅通畅则要达成什么目标，如果沟通不顺畅，则退而求其次的目标是什么，等等。

2. 明确共同的目标与利益，即双赢思维

与对方清楚地解释，为什么这个目标对自己很主要，希望让对方理解自己的动机。
同时，解释如果事情推进下去，对对方的好处是什么，即沟通的结果最好是双赢的状态。
没有人会心甘宁愿地合营一件对自身没有利益的事情。

3. 利用同理心，设身处地地从对方角度思考

我们在思考很多事情的时候每每是从自身角度出发，认为对方理所应该地去合营，涌现的问题都是对方的错。
然而，期望很美好，现实很骨感。
对方很可能有各种困难、分外情形你在当下是无法理解、想象的，因此，对方很可能会“谢绝”改变，由于他可能真的做不到。

这个时候，我建议要利用同理心，换位思考的能力，从对方角度思考，理解对方，以磋商是否可以向前一步，做出可以做的、必要的、有代价的改变。
这也是沟通的成效。
有的时候可以思考，“罗马不是一天建成的”。

4. 审时度势

沟通是个技能活，虽然我们沟通是有目标的，但是要把稳办法、方法，要察言观色，对不同的人采纳不同的办法。
有些人可能很守旧不愿意做出改变、有些人就比较开放，乐意以发展型思维的心态对待互助上的问题，也有人先守旧后开放，这都是作为一个人正常的反应，都是人性。
很正常。

因此，须要我们在沟通中审时度势，掌握节奏，掌握话术，以使沟通趋向于好的结果。

四、案例剖析

然而，在剖析运维数据时，我碰着了以下问题：

问题1：统计信息中标记为故障的内容，实际上很多是用户的咨询类要求。
根据 ITIL 标准，这些应分类为做事要求（work order）。

问题2：对付真正的故障，处理完毕后应记录处理过程和根因剖析。
但很多记录内容草率，缺少有代价的信息，导致我们难以从中获取对产品迭代有用的洞见。

办理问题1的对话

对付分类缺点问题，运维经理反馈说这是由一线的helpdesk团队操作的，质疑我们是否培训了这些团队。
他指出，运维团队在统计数据时不会变动这些数据，也不会主动纠正分类缺点。
这让沟通变得有些紧张。
事实上，我们之前确实没有考虑到这一点，我一贯担心缺点的数据会让管理层误认为产品问题频发，从而导致我须要付出巨大的阐明本钱。

我对运维经理表达了感谢，并坦诚地提到我们之前没有考虑到这个问题，会与一线团队进行沟通。
同时，我也阐明了为什么这些数据对我如此主要。
运维经理听后态度有所缓和，他提出可以直接由运维团队接管这部分数据处理，绕开一线团队（属于其他部门），并表示乐意推动这一改变。

办理问题2的策略

运维经理初次反应时讯问：“你们真的会关注这些信息吗？”他阐明说以前没有人重视这些数据。
他们会定期抽查10%的ticket，以此作为处理规范的审计依据。

我再次表达了我的至心动机：为用户创造他们喜好的产品。
用户在利用产品过程中碰着的问题大多由运维团队处理，这些数据是我们产品改进的关键信息来源。
我强调了数据准确性的主要性。

运维经理虽然表达了理解，但也提到事情量巨大，只能进行抽测，并在创造问题后办理问题。
我讯问了运维团队的抽测方法，理解到他们是将系统中的ticket信息导出至Excel，再通过人工检讨。
我理解了运维团队在事情量和抽测覆盖度上面临的困难。

灵光一现，我想到了今年的OKR，即如何利用AI简化事情流程。
我提出了利用AI技能审计运维事情的想法，运维经理对此表示出极大的兴趣。
目前，我们正在联合研究如何在运维审计事情中引入AI技能的可能性。

本文由 @红杉阁学者 原创发布于大家都是产品经理，未经容许，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。