工作一上午，小A揉着酸痛的脖子来到茶水间。
“哟，出差刚回来？”小A回头一看，原来是老D。“对啊，刚回来两天，时差还没倒过来呢。”
“这趟过去怎么样？”
“还没来得及谢你呢，上次咱们聊的工作坊效果挺好，交接的还算顺利，就是有几个点让我有些担心。”
老D来了兴趣：“来，聊聊？我看能不能帮忙出出主意。”
“我也正想找你支支招呢。这次过去了解了一些具体情况，发现客户那一侧的几个接口人分工和职务跟之前听到的信息有些出入。客户这侧的PO（Poduct Owner）是从别的区域外派过来的业务专员，负责环境维护的技术人员其实只挂个名，实际的工作都交给另外一个人做，这些倒都不算什么，最让我担心的是两个人，一个是主管内部系统开发的当地领导，一个是客户总部过来的技术指导。”
“嗯，这两个人怎么了？”
“这个当地领导吧，总爱冒出些不切实际的想法，其实对业务和功能该怎么设计一知半解，还老喜欢提需求。这也罢了，最糟心的是那个技术指导，说是技术指导，其实就是十多年前做过不到半年的程序员，早已经脱离编程很久了，但特别能挑我们的毛病，今天说这个功能做的有问题，明天说那个bug修的太慢，还老吵吵说他们当年写代码的时候如何如何，真是把我烦的头都大了，还不能不理他。”
“那你刚刚提到的另外几个人呢，他们对我们的态度如何？”
“PO这个人能力还是挺强的，对业务的了解还真不赖，合作起来也讲道理，关键时刻挡了很多客户领导的各种天马行空的需求，客户领导也肯听他的建议，可以说是很靠谱了。挂名的那个技术人员基本不管事，都交给他手下一个年轻人做，这个年轻人经验不多，很多技术活搞不定，不过好在因为年轻，也不会瞎折腾，愿意问愿意学，现在也上手一些了。”
“是嘛，那这个处境也没那么坏。咱们先来画几个图，把这几个人都归归类吧。”
“来小A，你看看这几个人都应该划分到哪个象限里。”
“嗯，先说PO，这个人对项目的影响力很高，到目前为止都还挺支持的，可以放到第一象限。挂名的技术也不管事，比较居中。他手下毕竟影响力有限，是在第四象限中间靠下的位置。客户这个领导应该在第二象限偏右上方，那个技术指导，按这段时间的观察，他应该也在第二象限，但是在左上方。”
“不错，那我们再来看另外一个图。”
“你来看看这几个人都应该划分到哪一类里。”
“同盟者挺好理解的，这个同床异梦和敌对该怎么区分呢？”
“我们先来看看这几类的划分标准。同盟者不用说了，就是那些和我们意见一致，双方高度信任的人。挑战者是指虽然信任我们，但在具体做的事情方面跟我们意见不同，比如产品定位、业务需求、功能设计之类，你刚刚描述的客户领导听起来八成是属于这一类的。同床异梦者恰恰相反，他们觉得在做的事情是对的，但并不愿意由我们来做这件事。最糟的情况就是敌对者，既不觉得现在做的事情是对的，也不愿意跟我们合作。最后就是骑墙派，观点摇摆不定的那些人，不过说实话，在大多数情况下，我们觉得某个人是骑墙派只是因为我们对他的了解不够，没有听到对方的观点，了解加深后一般会发现这个人也是旗帜鲜明的归到某一类里的。”
“受教了。这么说来，我觉得PO是我们的同盟，技术的两个人的话，也可以先算做同盟吧。客户领导确实是挑战者，而那个技术指导，我觉得是个彻头彻尾的敌对方。”
“好，那么接下来，我们就得看看对这几类人分别该如何应对了。首先是同盟者，千万不能因为这个人已经是同盟就忽视，对于这样的人，我们更应该保持关注，确保我们的关系是稳固的，有风险的时候也尽早和这些人商量，毕竟他们是我们的支持者，可以一起来解决问题，而他们遇到困难时我们也要及时的提供帮助，互惠互利。对于挑战者，我们要做到客观中立的进行沟通，把关注点聚焦到如何解决分歧、达成共识上，尽可能在双方的观点间寻求平衡位置和替代方案，不能因为观点不同而影响我们之间的关系。同床异梦者的话，虽说和我们关系不好，但我们的共同点是有着同样的目标，向他们展示我们的合作意愿以及我们能如何帮助他们达成所愿会很有帮助，双方最好能阐明彼此在这个目标下的诉求，在尽量满足彼此的前提下推进合作。敌对者就比较棘手了，如果能挖掘到对方的诉求和核心利益点，可以尝试把他往别的类别转变，比如寻找到共同目标之类，之后再用其他类别的应对方法进行管理，否则就得想办法控制他对项目的影响力，而这种控制往往是更难的。”
“原来如此，那这个骑墙派呢？”
“这种啊，我们刚刚也提到了，这种多数情况下是由于我们了解的信息不够，应该创造机会加深了解，更准确地判断出这个人到底是属于哪一类的，然后再制定具体的应对策略。说来说去，这些办法的核心都是一样的，就是想尽一切办法把各个类别的人变成我们的同盟者，哪怕是短期的、有前提的同盟，如果实在变不成，那就想办法降低这个人对项目的影响力，不过这个难度就大喽。”
“有道理啊，让我想想该怎么应对这两个不是同盟者的人。”小A陷入了思考。
