只有8%的人能搞定这些冲突

只有8%的人能搞定这些冲突_第1张图片
冲突

研发团队中天天都有冲突发生:

  • (C1)开会讨论网站的技术方案,张三坚持用 Node.js + Express + MongonDB + AngularJS + Bootstrap ,李四一定要用经典的 LNMP ……
  • (C2)有一个 Bug ,前端的王五觉得是后端的问题,后端的赵六觉得是前端的问题,两人争执不下,谁也不愿意修复……
  • (C3)阿金发现袁大头进度落后,要求他加班赶赶,袁大头没办法,答应加班……
  • (C4)孙八因为技术原因否定了一个需求,可产品经理认为这个效果会严重影响用户体验必须要做……
  • (C5)钱久和卢十三因为一个接口参数传值还是传引用在办公室骂仗……
  • (C6)领导安排你们部门暂停手上即将发布的项目,研究新的项目,你情感上不能接受,想等手上项目发布后再开始新项目,领导向你解释了新项目对公司眼下的重要意义,并告知了其紧迫性,你衡量后同意了……
  • (C7)线上的直播流媒体系统出了一个崩溃 Bug ,无规律,一天一两次,王飞负责修复这个 Bug ,他在一段代码里加了一个空指针判断,测试了两天,问题不再出现。作为经理的你认为他没有找到真正的原因,希望他继续排查问题,从根源上解决……

如果你是经理,或者你是当事人,你会怎么处理?

托马斯-基尔曼冲突模型

托马斯-基尔曼冲突模型(2003年提出),是世界领先的冲突解决方法,它从坚持度和合作度两个方向出发,划分了 5 种常见的冲突处理方式:竞争、回避、退让、妥协和合作。如下图所示:

只有8%的人能搞定这些冲突_第2张图片
托马斯冲突模型

我们先简要解释一下 5 种冲突处理方式。

竞争:高度坚持且不合作,又称为强迫策略,指的是牺牲一部分成员的利益,换取自己的利益或是团队整体的利益,其特征是正面冲突,直接发生争论、争吵,或其他形式的对抗,为了取胜不惜任何代价。

回避:不坚持也不合作,冲突双方意识到冲突的存在,但试图忽略和放弃冲突,不采取任何措施与对方合作,也不维护自身利益,希望一躲了之。

退让:不坚持且保持合作,指一方愿意把对方的要求和利益放在自己的要求和利益之上,做出自我牺牲,使对方达到目标,从而维持相互友好的关系。

妥协:中等程度的合作,中等程度的坚持。冲突双方都让出一部分要求和利益,但同时也保存一部分要求和利益。其特点是没有明显的赢家和输家,他们愿意共同承担冲突问题,并接受一种双方都达不到彻底满足的解决方案。冲突双方的基本目标能达成,相互之间的关系也能维持良好,冲突能得到暂时解决,但也有可能留下了下一次冲突的隐患。

合作:高度坚持且高度合作。冲突双方既考虑和维护自己的要求和利益,又充分考虑和维护对方的利益,尽可能地使双方的利益都达到最大化,最终达成共识。合作方式的特点是冲突双方相互尊重与信任,对于自己和他人的利益都给予高度关注,坦率沟通,澄清差异,致力于双赢。合作的方式能使冲突得到完全消除。

管理者如何处理团队冲突

现在我们从管理者的角度,结合事情的重要性和紧迫性来看看,在什么情况下应该采用什么冲突解决策略。

注意,如果管理者不是冲突双方之一(比如C1),这时管理者要解决冲突,矛盾关系就会因为管理者的介入而发生演化:

  • 管理者站在某一方的立场上,通过说服或者强迫另一方来解决冲突。
  • 管理者不站在任何一方的立场上,引导冲突双方自己采取一种冲突解决方式。
  • 管理者不同意原来冲突双方的办法,提出了新的方案,冲突就变成多方。管理者要采用竞争(强制)策略解决冲突时,就会同时强迫原来的两方。

当事情又重要又紧急,必须快速决策时,管理者可以采用竞争策略,强制性的解决冲突。

像 C2 这种冲突,假如这个Bug 紧迫性很高,当天必须修复,凌晨就要上线。那经理可以采用竞争策略(强制策略),强制王五从前端解决(因为这样更快也更易于测试和更新)。

像 C1 这类冲突,假如张三和李四都只是为了技术理想坚持己见而不考虑团队现实情况,作为技术管理者,你知道再这样一周一周讨论下去,项目的开发时间就会非常紧迫,甚至会错过交付期,那你就可以强制终止讨论,拿出你心中的合理方案,给出理由,要求大家采用。

像 C5 这类已上升到谩骂或肢体层面的冲突,作为管理者,应该立即采取强制措施,物理分割冲突双方,避免进一步的恶劣影响。隔离开冲突双方后,再来了解冲突的原因,然后在双方之间居间调停,或者根据公司规章制度,强制性处理,比如罚款、辞退等。

当事情重要但不紧急时,可以努力寻求以合作的方式解决冲突。

回到 C1 个冲突,假如当下处于技术预研和选型阶段,离这个阶段结束还有 2 周,那你作为管理者,就可以让张三和李四继续竞争,你来澄清项目的目标,设定要考虑的因素,引导大家围绕着项目目标来分析,这样冲突就可能通过团队成员的相互论证而以合作的方式解决掉。

在你的引导下,张三和李四按照第一章方案选型一节提供的思路来分析,发现团队里有人懂JavaScript,有人熟悉 MySQL ,没有人用过PHP ,他们在快速实现 MVP 的目标下很快达成了一致:用Node.js + Express + MySQL做后端,用 AngularJS + Bootstrap 做前端,用 Ubuntu Server 作服务器,用 Nginx 实现反向代理。

这样,冲突就以合作的方式得以解决。

回避策略可用于以下情况:

  • 冲突的事件微不足道,不重要也不紧急;
  • 问题根本没办法解决;
  • 解决问题的时机还不成熟,收集信息比立刻决策更重要;
  • 冲突双方都在非理性的情绪中;
  • 处理这个冲突会可能引发一个更大的冲突时。

当别人给你带来麻烦,但这种麻烦你可以承受,你真的理解别人得到冲突的利益更重要,你愿意维护关系的融洽胜过理性上的对错,那就可以采取退让策略来解决冲突。

C3 中的袁大头就采取退让策略解决了“领导让加班他不想加”这个冲突,因为他觉得项目进度更重要。

作为管理者,如果团队成员之间发生了冲突,事情本身不是那么重要也不那么紧急,但双方都不愿意让步,找到你协调解决,这时可以分别了解双方的诉求,看看能否通过沟通,让一方做出让步,最终让冲突以退让的方式解决。

假如你和某个团队成员发生了冲突,也可以考虑引发冲突的事情到底重不重要,你是否有坚持自己要求的必要,如果没有必要或者影响不大,就不要在这类事情上和团队成员整个你死我活,适当让步一下,让开发者的要求得以满足,能促进你们之间的关系。

这也是技术管理者应该意识到的一点:不是什么事情都有必须坚持的原则,不是什么时候都必须要赢过下属。

妥协策略可用于下列情况:

  • 目标十分重要但过于坚持己见可能会造成更坏的后果;
  • 对方做出承诺不再出现类似的问题;
  • 时间十分紧迫必须尽快采取一个妥协方案,问题又不是原则性问题;
  • 问题很复杂,在要求期限内很难完美解决;
  • 事情紧急但不是很重要,或者属于非原则性问题。

C7这种冲突,在软件研发团队中经常会出现。很多软件系统出现 Bug ,都找不到真正的原因,只好贴膏药来避免问题出现。这样并不能从根本上解决问题,但是考虑到线上缺陷的时限要求,或者版本的交付期限,你只能选择妥协——即接受这种贴膏药的修复方式。

但作为技术领导者,你一定要意识到,这种贴膏药的方式,是有后患的——因为问题没有真正解决,程序员添加的类似膏药的代码,很有可能只是堵住了触发 Bug 的某一个条件,很可能还存在其他触发 Bug 的条件,在将来的某一刻,它会再次引爆这个 Bug 。所以,当这个时限紧迫的事件过去之后,你还是要安排 Bug 所有者查找真正的原因。

作为管理者,冲突处理是必修课,只有恰当的处理冲突,才能维护关系健康,促进团队合作,塑造团队文化。当你再次面对冲突时,一定要先停下来想一想:

  • 冲突的原因是什么?
  • 我准备用哪种方式处理冲突?
  • 还有更好的处理方式吗?

这样会有助于你用恰当的方式解决冲突,避免给团队造成严重的不良影响。

你可能感兴趣的:(只有8%的人能搞定这些冲突)