题图：by 丫头非常骄傲
看到这个标题，很多人可能不知道我到底想说什么。先想想下面一些情况吧。
你在一个组中，不管是老人还是新人，很多不论是原始的设计，还是产品的需求，还是已有的代码架构，一定有很多决定不是你做的。各种大大小小的决定，有些是在你参与之前已经在那了的，有些是别人决定后告诉你的。
这时候，你一定会遇到一些类似这样的情况：别的组的工程师过来问你，你们组为什么要这么改代码啊？或者你是一个工程师，产品经理问你，你知不知道为什么这个地方有 bug，或者这个为什么不能这么做？再或者一个新人问你，这个设计似乎有问题啊，为什么要这样？
当然，你可以说：
“这是我们组产品经理决定的，你去问他们吧。”
或者：“这是那谁谁谁的代码，已经走了，谁也不知道他为什么这样做。”
或者：“这个一直就是这样了，我的改动只是 refactoring，没有动原来的逻辑。”
再或者：“谁谁谁告诉我要这样做，我也不清楚为什么。”
换句话说：你觉得别人是在质疑一件东西，而你做回答的第一反应，是这个不是你的责任或者问题。如果这个设计还是决定有点 stupid，也不是你 stupid。（当然也不排除你真的一无所知，但除非是你刚接手的项目，或者是比较特别的情况，否则还是有点儿说不过去。）
那么接下来会发生的事，很可能就是这个对话到此结束。因为对方发问的出发点，更多时候是了解情况，找到一个可以商议改进，解决问题的人。很多时候，根本不是为了追究责任。那么既然你接手了，或者参与了，你的回答虽然撇清了你和任何历史遗留的问题或者决定的关系，别人也没法觉得你是这一块的真正 owner。除非别人对话的目的就是吐槽，你可以跟他一起吐槽，增进个人感情。如果别人有建设性意见，可能也不会跟你沟通了。
情况如果反过来呢？当你开始基于一些决定，或者已有的设计，甚至已有的代码开展新的工作的时候，你就把自己认为是所有相关问题、设计的真正主人。你就需要去做下面的一些功课：
-
别人问的问题，你多少了解一点历史情况。可以根据历史情况，客观的帮助解释。比如，这样做确实不够通用，但是当时因为时间紧急，并且没有现在这么多的场景的应用。所以这个设计在那个时候其实是有道理的。或是因为别的资源限制，这个决定是在当时的限制下的决定。
-
别人问的问题，其实也是你比较困惑的问题。那么作为团队的一部分，你其实比对方更应该对问题的答案感兴趣。为什么你没有在组里试图去了解这个问题？或者你应该接下来找到相关的人，去了解其背景或者初衷。
-
别人问的问题，其实是你和组里别人已经争论很久的问题。虽然最后的决定和你的想法不一致，但是为什么会这样做决定，对方一定有说服你的理由，哪怕是技术无关的理由。那么这应该就是你为这个决定辩论的理由。如果对方的理由都没有说服你，那为什么你同意这个决定呢？如果你还是觉得不同意，那么，你应该和自己人先商量清楚。如果你觉得完全不能妥协，那么你应该和相关的人讨论。一旦达成一个统一，你就应该为这个决定辩护。而不是为自己之前的、被说服的想法辩护，对决定吐槽。因为对于没有参与这个争论的人来说，听了你的片面说法，对解决问题没有太大的帮助。
特别想说最后一点。工作中难免遇到一些人，当他跟你争论的时候，没有足够的理由，当时同意或者默认你的观点。可是离开会议后，跟别人一交流，又改变主意，或者完全不把自己的同意当回事。这样的人几乎不可能成为工作中的决策者，或者被委以重任的人。因为他既不能在和不同意见争论时坚守自己认为正确的看法，也不能在自己被说服取得一致后对推动整个项目的进展有任何贡献。因为他其实是不能为一个决定辩论，又不愿为自己表面同意的另一个决定辩论。
在过去两年的工作中，这可能也是我转变最大的一个地方。我也能清楚感受到这个意识的转变对我带来的正面影响。现在手上的项目总共已经有三十多人参与了。在带项目的过程中，会有各种决定，各种争论。很多时候，最后的决定并不一定是我最开始的想法。
每一次争论，在拿到统一之前我会尽最大努力去为自己的的想法辩护，但一旦发现对方说服了我，拿到一个大家都同意的方案，哪怕是和我的想法完全相对，我也会很坚定的去按照这个方案去沟通，遇到问题我会用我知道的情况去为这个方案辩护。告诉提出疑问的人为什么是这样。根据情况，如果对方是找茬儿的，我反而不会说这是谁谁谁的主意。如果对方表示赞同，我也会说这其实是谁谁谁的想法，视情况而定。
