码农何苦为难码农（如何做平层管理）

        最近在做一个项目的时候，出现的一件事件让我很恼火，事情是这样的：周五下午确定，我们中心会紧急接入一个业务，该业务会对接我们中心的两个模块，先是前置的那个版块和该业务联调相关接口之后，业务接口人就下班了。这个时候通知我们说，我们也要和该业务对接并联调接口，并强调该业务当天就要上线。码农的悲剧事件就这样上演了。
要对接一个业务，首先当然是要查看他们的接口了，询问其接口之后，得到的结果是之前和我们中心的另外一个业务已经对过了，接口没有问题，于是她就下班了。在确认接口没有问题之后，自然是开始编写自己业务的代码，时间是晚上6：30，在编写调用业务api的时候，由于没有给予任何接口文档，代码头文件也没有给予注释，只能先询问之前和业务联调的同事是否知道接口的调用方式。询问的结果是，他们只关注他们自己的调用的接口，所以联调也只联调了那一个接口，其他的接口怎么调用他们没有联调，也不知道。无可奈何只能打电话找该业务的接口人，结果打手机没有人接，连续拨了N次依然没有人接，可能没有听到也是正常的，我准备等会再打（后来她说认为是骚扰电话....所以就没接）抱着大家都是码农的想法，我也不想去找她的leader告状什么的，我就先把剩下的逻辑写完，不知道的参数就根据自己的理解先填上，准备等下再来填。这样等我把剩下的代码全部写完，已经是晚上9：00了。
       先试试自己的理解对不对，我就开始调试，结果自然不如意，只能再试着拨打电话，结果还是打不通，连续拨了几遍，依然不行。没有办法，项目进度限制只能找她leader，已经是晚上10：00了，结果leader电话连续拨打几次之后才拨通，结果就是他打电话给业务接口人，让她处理。终于联络上了该接口人，（电话为什么不接？以为是骚扰电话），电话的结果是各个参数的意义她已经给到了之前和她联调的另外的同事，在我耐心的“请问”之后，总算给了一些具体的意义。“感天谢地”的根据她提供的信息再次修改之后，问题依然没有解决，电话她，说就是这样调用的，如果还是错误，她也没有办法了。
      大家都是码农，你的累我是可以理解的，好不容易下班了想休息，被打扰了大家也都不高兴，我也能理解。既然这样，那我只能想别的办法了，这时已经凌晨1：00中间又找了几个同事"请教"了，但是这些人都不是具体负责该业务的，虽然被打扰，但是还是有点“不爽”的给予了建议。有时候事情就是这样“多磨”，无论怎么调整参数，甚至于我枚举了所有的输入条件，依然没有得到好的结果。既然不能，那就暂时放下，做其他的事情，（周五晚上通宵）。
       到了周六上午，再次联系该业务的接口人，她马上将他们业务的代码发给了我，但是他们业务的代码调用方式和我们完全不一样，我们根本无法参考，电话给出的结果是，我们就是这么调用的，你们不能调用，我也没有办法了，然后给了一个人的电话，说可以找她解决，然后不管了。通过这个人，我终于找到了一个在公司加班的一个同事，这个同事态度很好，虽然占用了他的个人时间，但是在他的耐心查看代码之下，很快就找到了问题。问题也终于解决了。
      说出这样的故事，并没有说那位业务接口人职业素养很差的意思，也不是说码农怎么苦逼的要加班通宵，真实的意思是遇到了这种问题，应该怎么处理？这样的问题，作为码农应该基本遇到过（如果没有遇到说明工作经验不够），也就是在平层关系（你没有直接管理对方的权限，甚至于人家不在乎你）在遇到问题的时候如何让对方重视你的事情，从而协助和帮助你解决问题。
     首先:   做为码农，如果回家之后被电话吵着还要继续干活总是不高兴的，如果是老板虽然不爽，但是还是得干活。但是如果是其他人，比如这种其他业务的人，可能就没有什么好脸色了，不接电话，不理，或者干脆一推。这种时候，就必须要通过她的老板告知她，该项目很重要，她必须要尽快配合，自上而下的管理方式是最直接最有效的方式。
      其次：只要是需求，就必须要认真了解是什么需求，在没有明朗需求之前，不能贸贸然的就决定该需求是否简单，比如这里涉及到了外部接口，就必须要先和接口人对好了接口之后才能允许她走，或者她必须承诺在家可以及时支持，而不是盲目的相信她说的话，从而产生不可预知的后果。
      再次：在接口没有被调试通过时，遇到问题的时候，接口人有义务和责任去协助发现问题，立场应当强势的告知她，你需要来处理这个问题，而不是退让。如果不能推动，则马上向上反馈。