增加你的影响力:为别人的决定辩论

2018-01-21 朱赟 嘀嗒嘀嗒 嘀嗒嘀嗒

题图:by 丫头非常骄傲


看到这个标题,很多人可能不知道我到底想说什么。先想想下面一些情况吧。


你在一个组中,不管是老人还是新人,很多不论是原始的设计,还是产品的需求,还是已有的代码架构,一定有很多决定不是你做的。各种大大小小的决定,有些是在你参与之前已经在那了的,有些是别人决定后告诉你的。


这时候,你一定会遇到一些类似这样的情况:别的组的工程师过来问你,你们组为什么要这么改代码啊?或者你是一个工程师,产品经理问你,你知不知道为什么这个地方有 bug,或者这个为什么不能这么做?再或者一个新人问你,这个设计似乎有问题啊,为什么要这样?


当然,你可以说:

“这是我们组产品经理决定的,你去问他们吧。”

或者:“这是那谁谁谁的代码,已经走了,谁也不知道他为什么这样做。”

或者:“这个一直就是这样了,我的改动只是 refactoring,没有动原来的逻辑。”

再或者:“谁谁谁告诉我要这样做,我也不清楚为什么。”


换句话说:你觉得别人是在质疑一件东西,而你做回答的第一反应,是这个不是你的责任或者问题。如果这个设计还是决定有点 stupid,也不是你 stupid。(当然也不排除你真的一无所知,但除非是你刚接手的项目,或者是比较特别的情况,否则还是有点儿说不过去。)


那么接下来会发生的事,很可能就是这个对话到此结束。因为对方发问的出发点,更多时候是了解情况,找到一个可以商议改进,解决问题的人。很多时候,根本不是为了追究责任。那么既然你接手了,或者参与了,你的回答虽然撇清了你和任何历史遗留的问题或者决定的关系,别人也没法觉得你是这一块的真正 owner。除非别人对话的目的就是吐槽,你可以跟他一起吐槽,增进个人感情。如果别人有建设性意见,可能也不会跟你沟通了。


情况如果反过来呢?当你开始基于一些决定,或者已有的设计,甚至已有的代码开展新的工作的时候,你就把自己认为是所有相关问题、设计的真正主人。你就需要去做下面的一些功课:

  • 别人问的问题,你多少了解一点历史情况。可以根据历史情况,客观的帮助解释。比如,这样做确实不够通用,但是当时因为时间紧急,并且没有现在这么多的场景的应用。所以这个设计在那个时候其实是有道理的。或是因为别的资源限制,这个决定是在当时的限制下的决定。

  • 别人问的问题,其实也是你比较困惑的问题。那么作为团队的一部分,你其实比对方更应该对问题的答案感兴趣。为什么你没有在组里试图去了解这个问题?或者你应该接下来找到相关的人,去了解其背景或者初衷。

  • 别人问的问题,其实是你和组里别人已经争论很久的问题。虽然最后的决定和你的想法不一致,但是为什么会这样做决定,对方一定有说服你的理由,哪怕是技术无关的理由。那么这应该就是你为这个决定辩论的理由。如果对方的理由都没有说服你,那为什么你同意这个决定呢?如果你还是觉得不同意,那么,你应该和自己人先商量清楚。如果你觉得完全不能妥协,那么你应该和相关的人讨论。一旦达成一个统一,你就应该为这个决定辩护。而不是为自己之前的、被说服的想法辩护,对决定吐槽。因为对于没有参与这个争论的人来说,听了你的片面说法,对解决问题没有太大的帮助。


特别想说最后一点。工作中难免遇到一些人,当他跟你争论的时候,没有足够的理由,当时同意或者默认你的观点。可是离开会议后,跟别人一交流,又改变主意,或者完全不把自己的同意当回事。这样的人几乎不可能成为工作中的决策者,或者被委以重任的人。因为他既不能在和不同意见争论时坚守自己认为正确的看法,也不能在自己被说服取得一致后对推动整个项目的进展有任何贡献。因为他其实是不能为一个决定辩论,又不愿为自己表面同意的另一个决定辩论。


在过去两年的工作中,这可能也是我转变最大的一个地方。我也能清楚感受到这个意识的转变对我带来的正面影响。现在手上的项目总共已经有三十多人参与了。在带项目的过程中,会有各种决定,各种争论。很多时候,最后的决定并不一定是我最开始的想法。


每一次争论,在拿到统一之前我会尽最大努力去为自己的的想法辩护,但一旦发现对方说服了我,拿到一个大家都同意的方案,哪怕是和我的想法完全相对,我也会很坚定的去按照这个方案去沟通,遇到问题我会用我知道的情况去为这个方案辩护。告诉提出疑问的人为什么是这样。根据情况,如果对方是找茬儿的,我反而不会说这是谁谁谁的主意。如果对方表示赞同,我也会说这其实是谁谁谁的想法,视情况而定。


如果后来问问题这个人提出的疑问是之前讨论完全没有考虑到,并且理由强到足以推翻之前的 agreement,那么,我们也应该把问题重新搬上桌面,和之前做决定的人一起重新讨论,而不是默默的让这种冲突或者决定的错误引起更多不同人的困惑或者大家完全有不同的想法或者理解。问题在那,错误在那,不处理,就早晚要反噬。这种情况不应该太频繁,但是工作中也并不少见。


当然,对于自己一无所知的提问,或者真的和自己无关,或者自己并不是为这个为题辩论的最佳人选,我也会把问题引导到合适的人那里。如果这个人已经不在公司,那一定相尽办法找到一个现在的责任人。


总之,任何一个问题,都会有一人对其负责。很多时候,你是有机会对其负责的,只是你选择了不。好处是你不担什么责任,但是职场中,如果你认为你只对你从头到尾一手做的东西负责,或是只对完全由你决定的东西负责,那么最后,你几乎不用对任何事情负责。


回到文章的标题,什么时候我们应该为别人的决定辩论,又为什么要为别人的决定辩论?如果你仔细看了上面所说的,你应该也就明白我的意思了。


如果你确实是一个问题,一个项目,一块代码现在的负责人,哪怕一些决定不是你做的,你也应该想办法为其辩论或者解释。如果完全是垃圾,你就应该尝试去推进一些改变。把问题、错误归咎到别人的决定,只会让你慢慢在沟通和协作中被无视。


觉得不错,分享给更多人看到
嘀嗒嘀嗒 热门文章:

亲身参与“引力波”项目之体验    阅读/点赞 : 55310/363

说说 Code Review    阅读/点赞 : 29680/314

我的编程之路    阅读/点赞 : 17059/314

迷茫和进步    阅读/点赞 : 14860/361

说说跳槽这件事    阅读/点赞 : 14005/307

从一条读者留言说起    阅读/点赞 : 13835/411

10%,和那背后的 90%    阅读/点赞 : 13518/351

我的博士生导师    阅读/点赞 : 11227/298

程序媛的碎碎念    阅读/点赞 : 9766/370

嘀嗒嘀嗒:我和微信公众号这一年    阅读/点赞 : 7328/354

嘀嗒嘀嗒 微信二维码

嘀嗒嘀嗒 微信二维码

嘀嗒嘀嗒 热门头条文章