【心得体悟】学习对抗

合作与对抗，是人与人交往的两个常见选项。从小到大，我们往往被培养成为喜欢合作，善于合作的人。但是，对于对抗，大多数人不大擅长。
一次良好的合作，无疑是让人身心愉悦的，参与双方或多或少都能获益。而对抗，往往是零和博弈，一方胜，则另一方败。赢家欢天喜地，输家垂头丧气。甚至，有些时候根本没有赢家，只有双输的局面。

最近，就有一次和领导的“对抗”发生在我身上。

人物介绍

我：开发人员，项目的实际执行者，隶属于部门X。

领导A：我的顶头上司，和我日常接触较多，隶属于部门Y。（是的，和我不是一个部门）

领导B：部门X的大boss，级别比A高，但不是A的直系上司，偶尔会过问项目情况。

对抗是发生在我和领导B之间。

背景

领导A想要推进一个项目M，这个项目M属于公司战略层面要推的东西，技术栈也是采用公司自己（二次）开发的一套东西。

我个人不看好这个项目M。原因有三：
1.和我们目前的架构兼容性差，落地的难度和工作量大。
2.功能，技术方面都不是最先进的，简单说就是不好用。
3.吃力不讨好，即使最终做完了，除了完成指标，没有太大正面效益。

但是一码归一码，领导拍板了，该做还是得做。

由于实现难度大，我们决定遵循敏捷开发的流程，一点一点做起。一共十几个服务，一个一个进行整合。
我带着手下一个开发，从0-1开始做，我主要负责前期做POC，整个流程打通了之后剩下的就由他来做。
过了6个月，我们已经成功地整合完成了3个项目。平均2个月一个服务的速度。接下来预计会提速。
不过，剩下来的工作量还是很大。如果想要短期内完成，需要加派人手。

领导A每周都会和我开几次例会，非常了解项目的进度，也觉得没什么问题。至于需要更多人手，他也暂时抽调不出其他的人，需要和更上层的领导协调。

起因

这一天，领导B和部门X的人开会，我也在（但是领导A不在，因为他不是部门X的）。会上正好聊到最近开发测试阶段的种种问题。

最近的测试是很不顺利，主要是因为启用了新人负责整个测试流程，但是没人说这个问题，大家开始甩锅，最后甩到了运维的同学头上。
我听了一会，觉得他被针对地有点惨，就想帮他解解围，于是我说：他除了日常的运维那些事，也帮我做了部分项目X的活，确实很辛苦。（言下之意是，他已经很努力了，本来也不是他的锅，就别揪着他不放了。）

这时，领导B把注意力转移到项目M上来了，开始问进度。我汇报了一下，她可能觉得太慢，就问，为啥做了这么久还没完成？

我以为她想要听细节，于是说：
1.难度大，前期主要是解决一切技术难题。（展开A,B,C...）
2.xxxxxxx

我第一点还没讲完，领导B直接打断了我，然后开始发火（具体内容省略，not good words）。。。

发展

当下，我的第一反应是：口干舌燥，心跳加速，大脑高速运转，思考该怎么办。

我肯定不能当面撕破脸和她吵，不管谁对谁错，到最后，我肯定是输。（领导A给我评级，但是领导B给我评年终奖）

而且，我的判断是，她有点 over react / 借题发挥 了，因为项目M本身进度是没有问题的。
所以，她的发火的对象是我，但是大概率本质原因不是我。所以，我没有必要 fight back，而是退一步，给领导一个台阶下，这样以后也好相处。

于是我说：客观上是有困难，但是主观上我们要有客服困难的决心。会后我会根据刚才领导的发言对下一步要做的事情重新规划，然后汇报。

解决

事后，领导B也承认，她今天 had a bad day。可能是她听到了太多人的抱怨，站在一个较高的高度，有时很难分辨谁的借口是真的，谁的借口只是偷懒和拖延。她只是希望底下的人碰到了问题能够积极地解决，而不是抱怨有各种各样的问题，所以做不到。

我也和领导A说了了这个事，最终争取到了更多的资源，加速了整个项目M的进度。

总结

这次的“对抗”非常短暂，只是一瞬间，而我也做出了合适的判断和选择。

更多时候，对抗是长期的，是默默的，有可能过程中你都不知道，只有当结果显现时，才发现站在了对立面的人。

这种“对抗”很难预言或预演，当遇到了，也不一定是坏事，而是一次宝贵的经历。

Theose can't kill you make you stronger.