|
|
# 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做缓存，还是另外寻找其它解决方案。当然，如果你已经有别的缓存解决方案的数据，也要一并提供给经理。
|
|
|
|
|
|
总结一下，和经理沟通，不是让经理帮你干活。要带着足够的信息来，不要只带着问题来。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
好了，讲到这里，这节课也就接近尾声了。这一节中，我们聊了聊沟通的技巧。虽然我们是按照三种不同的角度来说的，但是你发现没有，其实底层的逻辑就是一个词：尊重。
|
|
|
|
|
|
输出式沟通时，对别人要有尊重，不“好为人师”。做到真的是在帮助别人，而不是显摆自己。
|
|
|
|
|
|
请教式沟通时，要自己做出足够多的努力，而不是把手一甩，就直接让别人帮自己干活。同时，也要尊重别人为了帮你而付出的时间，不要拿别人的时间精力不当回事儿。最好是能提出有建设性的问题，这样双方都可以有进步。长期来看，这种请教式的沟通才是一个良性问问题的方式。
|
|
|
|
|
|
和上级沟通时，要准备好足够的数据，说的事情要有理有据，对自己的话负责，不要说一些模棱两可和想当然的东西。这是对上级的尊重。
|
|
|
|
|
|
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
沟通是必要的，沟通的技巧也是要掌握的。你在工作中，都遇到过哪些让你感觉很膈应的沟通？又遇到过那些让你如沐春风的沟通？
|
|
|
|
|
|
今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。
|
|
|
|