程序员的的高效沟通之道

程序员的的高效沟通之道

今天想分享出来的是另一些东西,与技术无关,却又无比重要。至少我希望看完这篇文章,能让你少一些无意义的加班。

问题出在哪儿?

如果列出程序员最讨厌的五件事,可能最首位的就是需求变更。实际上把所有产品需求的变更都归咎于产品经理本身能力问题,并无助于提高工作效率。

为了说清这个问题,我们来一起回顾一下,一般公司内部的 问题->需求-> 实现 的工作流程。

我们来假设,所有需求的建立,本质上都是为了解决某一问题, 我们将这个问题叫做问题A。
为了解决问题A,产品经理提出相对的解决方案,我们叫它需求B。
研发人员针对需求B,制定实现计划,将需求落实为代码,我们叫它结果C。

看起来很正常,似乎没有什么不妥对不对?
然而实际上,从我个人的经验上来讲,正是这种工作模式,很可能造成大量的需求修改。

实际上很多人看到这里应该反应过来了——整个工作模型,就是一个典型的悖论模型。最可能带来长期加班与需求修改的部分,往往不是C没有完美实现B,而是——C最终发现不能解决问题A


近两年来,我总是反复提醒新人刚做需求的时候,不要先纠结需求的哪个部分是否好实现,哪个分支条件没有考虑到,而一定需要问清楚的是——你的需求,要解决什么问题?

当你手里握着锤子的时候,你看什么都像钉子,这是在学习算法的时候很容易体会到的事实(比如判断N个矩形的包含关系,当你不知道什么是线段树之前,你的算法往往是低效的)。人终究只能在自己有限的知识和视野内提出有限的解决方案,所以大部分时候,产品提出的方案B,并不能解决问题A,或者从技术角度讲,有更加优雅高效的解决方案。

这也是为什么我去一家公司面试的时候,一定会问贵司需求制定是否有技术人员参与进去这个问题的原因。人天生倾向于用已有的知识去为问题建模,但极少数产品经理能够同时懂技术、产品和设计。产品经理这一岗位,在我看来更多的是作为发现问题以及推动问题解决的角色,而非提出完美解决方案的“神”。

需要记得的是,产品文档,永远只是将目标问题按照产品的理解包装后,端送到你眼前的“解决方案”。作为一个技术人员,你的价值不体现在完成文档上,而体现在解决问题上。

而当你明白你要解决的问题本质的时候,你所接受或拒绝 “需求变更”(如改个色值加个动画做个交互等)的理由,都将是建立在它能否有助于解决问题这一前提上——除非产品脑子有坑,他们都会乐于少走点弯路的。

时刻牢记:

  1. 在真正明白要解决的问题前,你的最终交付无论多么符合产品文档,都是有风险的。比“写的很烂”更让人伤心的是,“很好,没有bug,很完美——但是毫无意义”
  2. 没人能够在一开始想清楚所有的分支条件,就像研发也不可能一开始就预见到哪里有Bug一样。产品同学遗漏了一些细枝末节的话,不要太苛责。
  3. 就像产品不懂技术一样,你也未必真的懂产品。当产生争执的时候,有时候要选择相信同事的“专业性”。相信我,我以前不信,后来被打脸好多次了。
  4. 如果贵司产品普遍脑子有坑,也不要争执。打开##此处广告位招租##,看一下新的工作机会吧。

倒退几年,我绝不会想到自己有一天会写这么一篇关于如何说话的文出来。作为一个土生土长的东北汉子,太多年来已经习惯了所谓的“直白”,甚至一度以为这没有什么大不了。甚至非常鄙视所谓的“会说话”。

只不过现在迈过了30岁的门槛,回头看过去的自己时,我知道看到的不是所谓的“率性”,只是单纯的幼稚而已。需要声明的是,“会说话”绝不是见人说人话,见鬼说鬼话的油滑,而是指会沟通。实际上,是否掌握“沟通”这一能力,是判断成熟与否的重要标志——当然,你完全可以选择不成熟。

只是从我个人的经验上来看,如果你能保持心安理得的幼稚,通常是因为有人在看不见的地方默默付出,还请心怀感念。

坦白说我自己也没看过什么“话术”的书,全是凭着自己踩坑,或者看着别人踩坑后,点滴血泪总结的一些所谓的经验罢。实际上沟通是个非常庞大的话题,本文先着重讲几个点。

一、如何处理沟通矛盾

除非做个透明人,否则在工作时完全无法避免意见不合的讨论,也是最易造口业的地方。那么如何处理会议或者讨论时的意见不合,来完成一次高效的讨论而非撕逼,或一次高效的会议而非扯皮呢?

  1. 明白“讨论”的意义——是为一个问题,找一个最高效最优雅的解决方案(忘了的话,复习一下上篇文章)。而不是为了说服对方,不是为了所有人的观点都达成一致,更绝不是为了证明你是对的
  2. 要确认自己理解对方在表达什么。
  3. 要确认讨论中的其他人理解了自己要表达什么,不要自说自话,哪怕你是对的,讲不明白就没有任何意义。
  4. 千万记得,这不是尊严之争,这不是尊严之争,不要情绪化。如果双方任何一方变得情绪化,要及时叫停讨论。

最后,让真正拍板的人做决定(通常是你老大),如果你觉得最终决定很蠢,你只有两个选择——

top Created with Sketch.