有人的地方就有江湖，有江湖的地方就免不了冲突。
于是乎，日常battle（撕逼）就占据相当大一部分工作，消耗了团队大量的体力和精力，倍感心累。我曾经听一位技术负责人无奈吐槽：感觉自己天天没干啥事，尽撕逼了。。。由此可见冲突对团队造成的巨大痛苦。
那么，作为项目经理，我们面对冲突可以做些什么呢？
首先要调整心态，从积极的角度看待问题。团队就像人一样，有冲突表明团队还活着，具备无限可能性，而最怕的是团队在沉默中一步步走向死亡。基于冲突，我们可以认识不足、发现新机会、了解彼此，从而创造新的价值。
其次要做到公平公正。项目经理作为相对独立的第三方，往往会在冲突发生后被拉入战局，裁定孰是孰非。我们占据着得天独厚的优势地位，充分利用好自己的裁判员角色，就事论事，要做到不偏不倚，以理服人。要特别注意不能拉偏架，否则自己也会成为冲突的一份子，“剪不断，理还乱”，反而还会降低自己的公信力。
那么，具体怎么做呢？
PMBOK中介绍了五种方式：
但美中不足的是，书中对冲突解决方案的适用场景却所说不多。要知道什么时候用什么样的解决方案，需要我们根据冲突产生的原因来判断。而产生冲突的原因基本可分为沟通问题、立场问题和利益问题这三类。
沟通问题
这种最为常见，具体表现就是问题没有沟通清楚，双方各说各话，钻到牛角尖里面出不来。举个例子，技术发现某迭代全是p0需求，一个迭代肯定做不完，于是找产品沟通，要求对p0需求进行区分，并提出了按照p0-p100的顺序排列，方便技术按优先级顺序提前了解需求；可是产品一听就不乐意了，需求的优先级是按照需求的重要程度来的，不能因为高优先级的需求多就说这个需求不重要啊。于是乎，两个人在优先级问题上讨论的越来越激烈，虽然都想解决问题，但奈何谁也说服不了谁，甚至动了肝火。我们站在全局的角度来看双方的诉求，就会发现产品坚守的是优先级的标准，而技术关注的则是需求预审的先后顺序，优先级怎么样其实无所谓。发现这点，解决的办法也就出来了，我们在优先级之外增加一列序号，用于说明同等优先级下我们最想交付的需求是什么，然后技术按照这个序号来依次查看就好了。
这里，我们运用合作的方式直面问题，抛开不同频的沟通，真正去理解双方诉求，从而有效的解决双方冲突。
立场问题
有这么一个事，A团队和B团队原本独立发展，可是A团队某个项目需要B团队支持，但B看完需求后说，这个基础的功能我们都有的，再加上一个通知就好了。这下把A团队给整蒙了，你B团队作为偏中台的产品线，咋还做起前台的业务来了？！这是典型的团队发展过程中的边界问题，特别是在大公司，很容易就陷入了“招人-人员冗余-研究新业务”的恶性循环，形成“无界”的大公司病。
站在双方的立场上，其实都能理解。A团队作为项目发起方，新项目可以解决自己调研发现的业务痛点，提升团队影响力；而B团队也不愿放弃这个机会，且开发工作量更小，可以更快的满足需要。但理解归理解，冲突还是需要解决，不能让项目被搁置。
这时，我们就要跳出A或B的立场，站在更高一层--公司产品体系的立场来处理这个事情。从职责定位来说，A团队面向业务，B团队属于中台支持型团队，那么这个解决业务痛点的项目就需要B团队妥协，为A团队提供支持，而不能掣肘。
利益问题
一段牵扯到利益，事情就麻烦了，必然会是双方谁也不肯后退一步。我曾经亲眼见证利益不一致的双方各种battle现场，而且即使是在双方项目经理的组织协调下，连基础的需求管理流程都无法统一。究其原因，甲认为乙是自己的乙方，应该以自己的需求为第一优先级，甚至要把乙融入到甲的团队中；而乙认为甲只是自己的资源之一，要依靠自己吃饭。
在这种不清不明的利益纠葛中，从一般层面已然无法解决，最后只能借助外力，将冲突上升到两个团队的领导层级，然后双方一起开一个碰头会，缓和两个团队之间的矛盾。但是转身，两个领导去私下聊结算的事情去了。哈哈哈，大佬果然是大佬。
补充说明
细心的你可能已经发现，回避和命令这两种还未聊到。这主要是因为回避无法真正的解决问题，而在扁平化的互联网环境中，讲究的是平等探讨，命令相对较少。不过，如果冲突双方已经陷入情绪之中，那我们果断的要先选择回避措施，等双方恢复冷静之后在来处理，避免大家在情绪激动下做出一些无法挽回的事情。而如果遇到一些特别轴的人或事，大家也不要以为领导们不会运用命令的权力，而且还要打绩效呢。
以上，就是想要分享的内容。
加油呀！也欢迎大家一起来玩！
