最近在跟一个需要多个部门协作的项目，借助第三方公司的用户和流量，引流到我们的产品。我们(A部门)这边是提供商品类目，对方(B部门)提供流量入口，流量入口部署在F部门(跨公司)生态环境里。
用户完成商品购买的链路中（浏览商品，下单，支付，支付结果），使用了F部门的平台，B部门的入口，消费了A部门的商品，唤起了C部门的支付收银台，使用了D部门的统一订单和支付路由服务，而A部门-业务系统的运维管理权限在E部门。其中支付收银台嵌入了聚合支付，又使用了F部门的支付服务。从购买这条链路看，分工如下：B部门负责和F部门对接，A部门和B部门对接，但需要协调C部门、D部门、E部门一起排查问题。
临近上线周期还有几天，我们发现F部门提供的平台服务与自身的支付服务兼容性不好，严重影响购买体验。B部门负责和F部门协调后，更换了兼容性更好的平台服务，结果发现以前正常的支付收银台却无法走通流程。而发现问题时是在临近上线的当天晚上，B部门与F部门协调切换平台服务获批准的消息临近下班才才告知我们A部门，此时再去协调C部门、D部门、E部门，人都不在岗位了，B部门此时请来大领导，给我们施加压力，让我们晚上必须解决。没有办法了，只能和领导商量去一个个协调这些部门的同事一起排查问题。
在排查问题的过程中，我们(A部门)发现D部门支付路由数据传递设计方式不太合常理，要么让D部门更改设计，但是会影响到线上跑的几十个业务；要么让E部门改我们A部门的业务运维转发配置。E部门负责的小伙认为，为了兼容D部门不合理的设计，去改已有的配置，没有充分的理由是不会改的；何况更改配置还需要临时赶到公司，也不是一时半会儿能改好的。我们抓包测试C部门其他业务完成支付后结果页跳转情况，发现D部门的设计确实很奇怪，但C部门并没有通过运维改配置来实现正常跳转，而是在业务服务端做了一个跳转中转。
此时临时上线中转服务没有经过测试验证，风险也挺大的。而所有矛头似乎指向D部门的奇葩设计。奇怪的是这个支付路由设计已经在线上跑了接近2年，也有几十个业务接入了，为什么这时候才抱怨说设计有问题？一家之言不能说明问题，于是我们赶紧联系D部门的负责人，通过咨询才知道这样设计有一定的道理，他们对接多个业务，为了兼容支付结果数据需求最大的业务才这样设计的。
那么只能硬着头皮先尝试更改运维配置，避免耽误了B部门的业务上线，到下个上线周期再考虑中转服务了。根据这个思路，找到曾经做过该配置的C部门的小伙帮忙配置，在测试环境测试通过后，同时请E部门负责的小伙授权配置，终于实现支付完成后正常跳回业务支付结果页。
复盘整个排查问题的过程，总结以下几点：
1、整个链路的相关人员都应该咨询到位，业务方、运维方、平台方、类似业务方会站在自身的角度表达问题，听一面之词容易被带偏。
2、E部门运维小伙表达的观点是对的。虽然这是最快的解决问题的方式，但是单纯判定他不愿意更改配置也太过于狭隘，应该深层次挖掘原因，尝试多种沟通方式尝试让他协助更改配置，解决燃眉之急。
3、需要多部门配合的业务，绝对不是靠执行层个人的人脉和跑断腿来解决的。作为项目发起方-B部门和主要参与方A部门，在规定的上线时期，前两天就应该给相关部门通气到位。尽管受限于F部门的服务，前期应该沟通到位哪些人应该协助推进项目，不然在紧急时刻才让其他部门来协助，效果得不偿失。这次要不是找到C部门和E部门的同事来支持，估计问题依然难以解决。
4、在做项目的过程中，会发现有言行不一致的协作者，表决心的时候耿耿的，但是需要协助的时候却非常有技巧的进行推诿，让下游业务部门急的像热锅上的蚂蚁。以后遇到此等情况，项目前期向相关负责人下好拜帖，后期紧紧跟进执行层。也有做事不留名的热心肠同事，但是一定注意前期需要沟通好，万一造成损失不要让别人背锅，这就是担当吧。
总之，在项目周期里，产品经理在任何时候是任何人的翻译，在一堆混乱里优雅的推动项目的进展，也是一种修行。
