You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

13 KiB

20 | 沟通技巧:如何跟自己的同事请教问题?

你好,我是臧萌。今天我来和你聊聊沟通技巧这件事。

我们在日常的工作中,和同事的互相交流必不可少。一方面,我们要大胆主动地和同事多多沟通交流。另一方面我们也要意识到,沟通也是有技巧的,如果沟通不得要领,会降低沟通的效率、浪费大家的时间、甚至可能会引起别人的反感。所以在这一节里,我想跟你分享一下我关于交流沟通的一些小技巧。

我把沟通分成三类,分别是输出式沟通、请教式沟通、和向上沟通。这三个方向,面向的受众和沟通目的各有不同,具体的技巧各有不同。

输出式沟通

首先我们来谈谈输出式沟通。所谓的输出式沟通,就是把自己知识输出给别的同事。这里说的不是分享会这种集中式的输出,而是通过简单随意的沟通来进行的输出。这种沟通方式,非常考验技巧和方式。毕竟弄不好就会让人觉得你是在臭显摆。不信我们来转换到被输出的一方,看下面这样一个场景。

好心也可能办坏事

你工作中遇到一个问题,正在埋头研究着怎么解决,看得正起劲儿,想深入研究一下。忽然一个同事跑过来说,这个啊,你这么弄这么弄之后,再这么弄就好了。你不得不恋恋不舍地把注意力转移到这个同事身上,还不得不装作非常感激地回应这同事的“指导”。然后你说:“哦,知道了,我一会儿试试看。”然后想赶紧抽身,继续自己研究。看你没动作,同事还以为你不会,直接说我帮你弄吧,接过你的键盘鼠标刷刷刷帮你改好了。

这时候,你的学习的劲头也没了大半,想着那就不妨跟这位同事多请教请教好了。当你真的就这个问题深入问下去的时候,发现同事也只会点皮毛,深入的内容并不是很懂。

你想想,在这种情况下,你作为被输入知识的一方,是不是感觉有点不爽?你不仅仅是想解决一个问题,而是想借机学得更深入一点。自己学得好好的,结果被人“一顿操作猛如狗”,学习的劲头被搅和没了。站在那个热心助人的同事的角度看,好像也有点冤。自己花了时间帮你搞定了问题,最后还没落到好。

想输出内容,也是要讲究方式方法的。

看准时机,点到为止

其实我曾经有一段时间,就是上面例子里说到的那个“有个同事”。自己一瓶子不满半瓶子咣当,就喜欢到处掺合着给人指点问题。这种行为,别人可能嘴上不说,但是心里还是不欢迎的。每个人都有自己的学习习惯和解决问题的方式,除非一个人的事情已经阻碍到你做事情的进度了。默认情况下,各人做各人的事情就好,一个人是不需要别人来主动指点的。更不要说例子中这种轻率地过去指点江山,甚至抢过鼠标键盘就开始操作的行为。

当然,并不是说热心不对。只不过当我们主动提供帮助时,要讲究时机和力度。下面我们再来看这么一个例子。

你抓耳挠腮地在看一个问题口中情不自禁地念叨着“这破service的破接口咋就调用不成功”之类的话。在你打算休息一下喝口水换个心情的时候遇到了组里的同事。同事说那个service是挺烂的我当时搞了半天也没成最后一看是少传了TOKEN参数你回去可以试试看。

这样一来,你是不是感觉上要舒服得多?首先,同事并没有打断你工作的过程,而是在你已经暂停工作的时候,通过闲聊的方式分享了自己的经验。其次,同事把解决问题的主动权交给了你,你可以选择自己去试试看,也可以在自己搞不定的时候,选择去向这个同事请教。因为同事既然主动跟你说了这个话,自然表示他是愿意就这个事情提供帮助的。

正所谓,观棋不语真君子。别人正在思考的时候,别东一榔头西一棒子地打断别人。别人空闲下来的时候,可以找机会说出自己的见解,表示自己愿意提供帮助。

就我自己来说,我现在已经很少主动去掺合别人解决问题了。主动掺合也是多听多想,除非是我非常确定自己在这块儿吃得很透彻,否则我很少会去主动说什么。子曾经曰过:人之患,在好为人师。古人的话是有大道理的。

好了,那如果你确实搞不定,需要主动寻求别人的帮助,那么应该怎么操作呢?我们来接着看。

请教式沟通

向同事请教各种问题,可以说是非常常见的一种沟通了。你会问问题吗?

摆正态度:没人有责任帮你

首先,大家是同事关系,不是师徒关系或者师生关系。所以从责任上来讲,我们周围的同事,是没有责任帮助我们,回答我们的问题的。

当然,日常同事们会互帮互助。但是上面的道理是不变的。我们不能把别人的帮忙想成理所当然。不能认为这个事情我不会,那么你会你就应该教我,教到我会为止。这里是公司,不是学校。虽然大家一般都会友善地回答同事提出的问题,但是如果问的问题不对,不但很难得到想要的答案,还可能会慢慢地成为同事们拒绝帮助的对象。

那接下来我们就来看看问问题的正确姿势。

问问题的正确姿势

既然同事之间都是纯友情帮忙,那么我们就尽量少去麻烦别的同事。在向同事寻求帮助之前,先做好准备工作。比如说,先去看一下组内相关的文档,先去看一下源代码,尝试自己找到问题的答案。如果是一些开源软件的用法,那么就自己去开源网站上看相关的文档,自己学起来。如果在这个过程中,遇到了非常具体的问题,那么就可以考虑拿这些具体的问题去问相关的同事了。

最不受欢迎的问题就是XXX怎么搞。记住工作是自己的问题也是自己的一个XXX怎么搞的问题基本就是把自己的工作扔给别人去做了。问别人问题要尽量具体而不是非常笼统地问一个问题。

当然,很多时候,如果懂的同事帮忙指点一下,可能几分钟就能搞定了。自己看,可能要几个小时甚至一天。但是这个过程是很难避免的。以一个当前的工作为契机,自己慢慢熟悉起工作中涉及的各个模块,最后收获的是以后可以自己解决问题的能力。如果靠同事指点,解决问题是快,但是收获也小的多。

所以说,问问题的本质,不是让别人帮你解决问题,而是要学会自己解决问题。如果问题解决了,自己还是一脸茫然,下次遇到类似或者相关的问题,还是不会,那么你就不是在问问题,你是在让别人帮你来做你自己的工作。

在完成工作的这条路上路要自己走在路口不知道怎么走的时候可以问别人。但是一般情况下不能让别人领着你一路走到终点。举个简单的例子你分到的工作任务是用HBase做一个缓存那么下面三个问题就非常不适合问同事

  1. HBase是什么
  2. HBase怎么用
  3. HBase的客户端有那么多API我应该用哪个。

因为这三个问题,你靠搜索公开资料就可以自己搞定,完全不需要问别人。但是下面这三个问题,就可以问问周围的同事:

  1. 我们公司的HBase集群配置在哪里可以找到
  2. 我研究了一下HBase感觉HBase做缓存可能会有些问题比如内存命中失败的时候加载数据可能会很慢
  3. HBase的可用性能满足我们对缓存的要求吗

在这三个问题里,第一个问题属于常识性的问题。这个问有经验的同事没问题,他们可能会直接给你一个文档链接,然后剩下的事情你自己就可以搞定了。

而下面的两个问题,都是比较有建设性的问题。其实这已经部分脱离了单纯的请教式沟通,而是更多地向探索式的双向沟通发展。从我个人的角度来看,我是比较欢迎这种问题的。因为和大家一起讨论这种问题,大家都能够得到能力和认知的提升。

写在后面的三个小技巧

首先要重点说一下的是,千万不要相同的问题问了一遍又一遍。这不叫问问题,这叫把别人当工具人使唤。如果问别人问题,别人也愿意回答,那就一次性问清楚问明白,然后自己好好总结,牢牢记住。一遍遍地问相同或相似的问题,是对别人的不尊重。

然后是积极总结归纳。如果你向别人请教问题,收获了很多,那么不妨总结出一个文档发出来。这样一方面,归纳的过程能加深巩固你自己收获的知识,另一方面你整理出的文档可以帮助更多的人解决问题。这样做也能表达对帮你一把的同事的尊重。

最后一点就是,如果你确实是个超级大萌新,什么都不懂,每天不得不到处请教同事各种问题,那么不妨和经理反映一下自己的实际情况,让经理指派人来帮你完成工作热身。毕竟大家都很忙,对于每天都要完成自己的工作的同事们,很难说能够挤出足够的时间来帮助你。

向上沟通

向上沟通,就是指和经理沟通。向上沟通有三个主要目的,分别是汇报工作、申请资源、请求帮忙做决策。总的来说,这三种目的的沟通,都需要提前准备好足够的信息,而且跟经理沟通,要仔细负责,不能信口胡来。下面我来展开说一下。

汇报工作时,先交代两个重点:成果和问题。工作成果是指那些已经落实了的成果,没落实的、没实际验证的不要想当然地乱说。问题是指现在遇到的感觉需要经理帮忙协调的,以及需要经理调动资源解决的事情。至于自己就能解决的问题,不需要说太多。

比如说之前提到的用HBase做缓存的工作。如果要就这个工作向经理汇报那么下面几个内容是要给出来的测试环境是否可用、生产环境是否可用、外部依赖是否解决。我们自己是否提供了jar client、还是通过 service API访问、或者说都支持。要是支持的话性能指标数据又分别是什么。至于细节的技术问题没必要说经理不是帮你解决技术问题的。

然后是申请资源。这时候,要整理清楚前因后果,你要想明白申请了资源能做到哪些事情、申请不到又会影响哪些事情、为什么资源不是要得更多或者更少。简言之,就是要证明这个资源用得值。

还是拿HBase做缓存的例子。在测试环境下你可以整理出数据量、缓存命中率、HBase内存、性能指标的统计数据。然后根据这些数据以及整体对性能指标的要求提出生产环境需要的机器资源和配置。

最后是请求帮忙做决策。自己不能做决定的事情,就需要经理帮忙了。这种情况很多,比如遇到了新的情况,或者遇到需要对外部作出承诺的事情等等,所有自己吃不准的,不知道如何处理的,都可以找经理帮忙做决策。

当然,我们找经理做决策,不是去把包袱扔给经理,而是和经理一块协调解决问题。所以在找经理之前,我们也要整理好足够多的信息才行。

比如用HBase做缓存的例子就像我们前面提到过的如果在实测的时候发现HBase不是很适合做缓存比如因为缓存不命中会导致P99在1秒以上比如HBase在生产上有2%的时间会有3%的数据不可用。收集好这些数据可以让经理做决策我们是否继续用HBase做缓存还是另外寻找其它解决方案。当然如果你已经有别的缓存解决方案的数据也要一并提供给经理。

总结一下,和经理沟通,不是让经理帮你干活。要带着足够的信息来,不要只带着问题来。

总结

好了,讲到这里,这节课也就接近尾声了。这一节中,我们聊了聊沟通的技巧。虽然我们是按照三种不同的角度来说的,但是你发现没有,其实底层的逻辑就是一个词:尊重。

输出式沟通时,对别人要有尊重,不“好为人师”。做到真的是在帮助别人,而不是显摆自己。

请教式沟通时,要自己做出足够多的努力,而不是把手一甩,就直接让别人帮自己干活。同时,也要尊重别人为了帮你而付出的时间,不要拿别人的时间精力不当回事儿。最好是能提出有建设性的问题,这样双方都可以有进步。长期来看,这种请教式的沟通才是一个良性问问题的方式。

和上级沟通时,要准备好足够的数据,说的事情要有理有据,对自己的话负责,不要说一些模棱两可和想当然的东西。这是对上级的尊重。

思考题

沟通是必要的,沟通的技巧也是要掌握的。你在工作中,都遇到过哪些让你感觉很膈应的沟通?又遇到过那些让你如沐春风的沟通?

今天的课程就结束了,希望可以帮助到你,也希望你在下方的留言区和我参与讨论,同时欢迎你把这节课分享给你的朋友或者同事,一起交流一下。