20 沟通技巧：如何跟自己的同事请教问题？
你好，我是臧萌。今天我来和你聊聊沟通技巧这件事。
我们在日常的工作中，和同事的互相交流必不可少。一方面，我们要大胆主动地和同事多多沟通交流。另一方面我们也要意识到，沟通也是有技巧的，如果沟通不得要领，会降低沟通的效率、浪费大家的时间、甚至可能会引起别人的反感。所以在这一节里，我想跟你分享一下我关于交流沟通的一些小技巧。
我把沟通分成三类，分别是输出式沟通、请教式沟通、和向上沟通。这三个方向，面向的受众和沟通目的各有不同，具体的技巧各有不同。
输出式沟通
首先我们来谈谈输出式沟通。所谓的输出式沟通，就是把自己知识输出给别的同事。这里说的不是分享会这种集中式的输出，而是通过简单随意的沟通来进行的输出。这种沟通方式，非常考验技巧和方式。毕竟弄不好就会让人觉得你是在臭显摆。不信我们来转换到被输出的一方，看下面这样一个场景。
好心也可能办坏事
你工作中遇到一个问题，正在埋头研究着怎么解决，看得正起劲儿，想深入研究一下。忽然一个同事跑过来说，这个啊，你这么弄这么弄之后，再这么弄就好了。你不得不恋恋不舍地把注意力转移到这个同事身上，还不得不装作非常感激地回应这同事的“指导”。然后你说：“哦，知道了，我一会儿试试看。”然后想赶紧抽身，继续自己研究。看你没动作，同事还以为你不会，直接说我帮你弄吧，接过你的键盘鼠标刷刷刷帮你改好了。
这时候，你的学习的劲头也没了大半，想着那就不妨跟这位同事多请教请教好了。当你真的就这个问题深入问下去的时候，发现同事也只会点皮毛，深入的内容并不是很懂。
你想想，在这种情况下，你作为被输入知识的一方，是不是感觉有点不爽？你不仅仅是想解决一个问题，而是想借机学得更深入一点。自己学得好好的，结果被人“一顿操作猛如狗”，学习的劲头被搅和没了。站在那个热心助人的同事的角度看，好像也有点冤。自己花了时间帮你搞定了问题，最后还没落到好。
想输出内容，也是要讲究方式方法的。
看准时机，点到为止
其实我曾经有一段时间，就是上面例子里说到的那个“有个同事”。自己一瓶子不满半瓶子咣当，就喜欢到处掺合着给人指点问题。这种行为，别人可能嘴上不说，但是心里还是不欢迎的。每个人都有自己的学习习惯和解决问题的方式，除非一个人的事情已经阻碍到你做事情的进度了。默认情况下，各人做各人的事情就好，一个人是不需要别人来主动指点的。更不要说例子中这种轻率地过去指点江山，甚至抢过鼠标键盘就开始操作的行为。
当然，并不是说热心不对。只不过当我们主动提供帮助时，要讲究时机和力度。下面我们再来看这么一个例子。
你抓耳挠腮地在看一个问题，口中情不自禁地念叨着“这破service的破接口，咋就调用不成功”之类的话。在你打算休息一下，喝口水换个心情的时候，遇到了组里的同事。同事说，那个service是挺烂的，我当时搞了半天也没成，最后一看是少传了TOKEN参数，你回去可以试试看。
这样一来，你是不是感觉上要舒服得多？首先，同事并没有打断你工作的过程，而是在你已经暂停工作的时候，通过闲聊的方式分享了自己的经验。其次，同事把解决问题的主动权交给了你，你可以选择自己去试试看，也可以在自己搞不定的时候，选择去向这个同事请教。因为同事既然主动跟你说了这个话，自然表示他是愿意就这个事情提供帮助的。
正所谓，观棋不语真君子。别人正在思考的时候，别东一榔头西一棒子地打断别人。别人空闲下来的时候，可以找机会说出自己的见解，表示自己愿意提供帮助。
就我自己来说，我现在已经很少主动去掺合别人解决问题了。主动掺合也是多听多想，除非是我非常确定自己在这块儿吃得很透彻，否则我很少会去主动说什么。子曾经曰过：人之患，在好为人师。古人的话是有大道理的。
好了，那如果你确实搞不定，需要主动寻求别人的帮助，那么应该怎么操作呢？我们来接着看。
请教式沟通
向同事请教各种问题，可以说是非常常见的一种沟通了。你会问问题吗？
摆正态度：没人有责任帮你
首先，大家是同事关系，不是师徒关系或者师生关系。所以从责任上来讲，我们周围的同事，是没有责任帮助我们，回答我们的问题的。
当然，日常同事们会互帮互助。但是上面的道理是不变的。我们不能把别人的帮忙想成理所当然。不能认为这个事情我不会，那么你会你就应该教我，教到我会为止。这里是公司，不是学校。虽然大家一般都会友善地回答同事提出的问题，但是如果问的问题不对，不但很难得到想要的答案，还可能会慢慢地成为同事们拒绝帮助的对象。
那接下来我们就来看看问问题的正确姿势。
问问题的正确姿势
既然同事之间都是纯友情帮忙，那么我们就尽量少去麻烦别的同事。在向同事寻求帮助之前，先做好准备工作。比如说，先去看一下组内相关的文档，先去看一下源代码，尝试自己找到问题的答案。如果是一些开源软件的用法，那么就自己去开源网站上看相关的文档，自己学起来。如果在这个过程中，遇到了非常具体的问题，那么就可以考虑拿这些具体的问题去问相关的同事了。
最不受欢迎的问题就是：XXX怎么搞。记住，工作是自己的，问题也是自己的，一个XXX怎么搞的问题，基本就是把自己的工作扔给别人去做了。问别人问题，要尽量具体，而不是非常笼统地问一个问题。
当然，很多时候，如果懂的同事帮忙指点一下，可能几分钟就能搞定了。自己看，可能要几个小时甚至一天。但是这个过程是很难避免的。以一个当前的工作为契机，自己慢慢熟悉起工作中涉及的各个模块，最后收获的是以后可以自己解决问题的能力。如果靠同事指点，解决问题是快，但是收获也小的多。
所以说，问问题的本质，不是让别人帮你解决问题，而是要学会自己解决问题。如果问题解决了，自己还是一脸茫然，下次遇到类似或者相关的问题，还是不会，那么你就不是在问问题，你是在让别人帮你来做你自己的工作。
在完成工作的这条路上，路要自己走，在路口不知道怎么走的时候，可以问别人。但是一般情况下，不能让别人领着你一路走到终点。举个简单的例子，你分到的工作任务是用HBase做一个缓存，那么下面三个问题，就非常不适合问同事：
- HBase是什么；
- HBase怎么用；
- HBase的客户端有那么多API，我应该用哪个。
因为这三个问题，你靠搜索公开资料就可以自己搞定，完全不需要问别人。但是下面这三个问题，就可以问问周围的同事：
- 我们公司的HBase集群配置在哪里可以找到；
- 我研究了一下HBase，感觉HBase做缓存可能会有些问题，比如内存命中失败的时候，加载数据可能会很慢；
- HBase的可用性能满足我们对缓存的要求吗？
在这三个问题里，第一个问题属于常识性的问题。这个问有经验的同事没问题，他们可能会直接给你一个文档链接，然后剩下的事情你自己就可以搞定了。
而下面的两个问题，都是比较有建设性的问题。其实这已经部分脱离了单纯的请教式沟通，而是更多地向探索式的双向沟通发展。从我个人的角度来看，我是比较欢迎这种问题的。因为和大家一起讨论这种问题，大家都能够得到能力和认知的提升。
写在后面的三个小技巧
首先要重点说一下的是，千万不要相同的问题问了一遍又一遍。这不叫问问题，这叫把别人当工具人使唤。如果问别人问题，别人也愿意回答，那就一次性问清楚问明白，然后自己好好总结，牢牢记住。一遍遍地问相同或相似的问题，是对别人的不尊重。
然后是积极总结归纳。如果你向别人请教问题，收获了很多，那么不妨总结出一个文档发出来。这样一方面，归纳的过程能加深巩固你自己收获的知识，另一方面你整理出的文档可以帮助更多的人解决问题。这样做也能表达对帮你一把的同事的尊重。
最后一点就是，如果你确实是个超级大萌新，什么都不懂，每天不得不到处请教同事各种问题，那么不妨和经理反映一下自己的实际情况，让经理指派人来帮你完成工作热身。毕竟大家都很忙，对于每天都要完成自己的工作的同事们，很难说能够挤出足够的时间来帮助你。
向上沟通
向上沟通，就是指和经理沟通。向上沟通有三个主要目的，分别是汇报工作、申请资源、请求帮忙做决策。总的来说，这三种目的的沟通，都需要提前准备好足够的信息，而且跟经理沟通，要仔细负责，不能信口胡来。下面我来展开说一下。
汇报工作时，先交代两个重点：成果和问题。工作成果是指那些已经落实了的成果，没落实的、没实际验证的不要想当然地乱说。问题是指现在遇到的感觉需要经理帮忙协调的，以及需要经理调动资源解决的事情。至于自己就能解决的问题，不需要说太多。
比如说之前提到的用HBase做缓存的工作。如果要就这个工作向经理汇报，那么下面几个内容是要给出来的：测试环境是否可用、生产环境是否可用、外部依赖是否解决。我们自己是否提供了jar client、还是通过 service API访问、或者说都支持。要是支持的话，性能指标数据又分别是什么。至于细节的技术问题，没必要说，经理不是帮你解决技术问题的。
然后是申请资源。这时候，要整理清楚前因后果，你要想明白申请了资源能做到哪些事情、申请不到又会影响哪些事情、为什么资源不是要得更多或者更少。简言之，就是要证明这个资源用得值。
还是拿HBase做缓存的例子。在测试环境下，你可以整理出数据量、缓存命中率、HBase内存、性能指标的统计数据。然后根据这些数据，以及整体对性能指标的要求，提出生产环境需要的机器资源和配置。
最后是请求帮忙做决策。自己不能做决定的事情，就需要经理帮忙了。这种情况很多，比如遇到了新的情况，或者遇到需要对外部作出承诺的事情等等，所有自己吃不准的，不知道如何处理的，都可以找经理帮忙做决策。
当然，我们找经理做决策，不是去把包袱扔给经理，而是和经理一块协调解决问题。所以在找经理之前，我们也要整理好足够多的信息才行。
比如用HBase做缓存的例子，就像我们前面提到过的，如果在实测的时候，发现HBase不是很适合做缓存，比如因为缓存不命中，会导致P99在1秒以上，比如HBase在生产上有2%的时间会有3%的数据不可用。收集好这些数据，可以让经理做决策，我们是否继续用HBase做缓存，还是另外寻找其它解决方案。当然，如果你已经有别的缓存解决方案的数据，也要一并提供给经理。
总结一下，和经理沟通，不是让经理帮你干活。要带着足够的信息来，不要只带着问题来。
总结
好了，讲到这里，这节课也就接近尾声了。这一节中，我们聊了聊沟通的技巧。虽然我们是按照三种不同的角度来说的，但是你发现没有，其实底层的逻辑就是一个词：尊重。
输出式沟通时，对别人要有尊重，不“好为人师”。做到真的是在帮助别人，而不是显摆自己。
请教式沟通时，要自己做出足够多的努力，而不是把手一甩，就直接让别人帮自己干活。同时，也要尊重别人为了帮你而付出的时间，不要拿别人的时间精力不当回事儿。最好是能提出有建设性的问题，这样双方都可以有进步。长期来看，这种请教式的沟通才是一个良性问问题的方式。
和上级沟通时，要准备好足够的数据，说的事情要有理有据，对自己的话负责，不要说一些模棱两可和想当然的东西。这是对上级的尊重。
思考题
沟通是必要的，沟通的技巧也是要掌握的。你在工作中，都遇到过哪些让你感觉很膈应的沟通？又遇到过那些让你如沐春风的沟通？
今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。
- 南湾小猪 👍（14） 💬（3）
有一个身边的例子，想请教臧萌老师： 同事A和同事B合作一个重要的项目。他俩一起干活，但A比B多做了很多。后来B却去经理那儿打小报告，说A在项目中太强势，干活时候封锁信息，A自己埋头干，导致B在这个项目中难以作出贡献。所以经理就在一对一会议时候和A提出，希望A注意合作。 A有些冤枉，向我诉说了这件事情。不知道B和经理的原话是怎么说的，即使是经理和A谈的时候，A也有些冤枉了。 我作为一个旁观者来看，A属于技术强、动作快、很少废话的那种，B属于很会说话、宣传能力强、但技术较弱甚至有点划水的那种。 对于B这种会打小报告的人，作为同事，我们应该如何去处理和沟通？
2020-07-01 - 熬夜等洗澡 👍（5） 💬（3）
臧老师好，我昨天看到一个视频，大概意思就是：有两个员工，小张和小李，两个人水平差不多，都是比较普通的。但是小张喜欢跟领导邀功，而且还会夸张自己的功劳，比如说他加班了，会去跟领导说“哎呀，昨天加了一天的班，加的我腰酸背疼的。”只要他干了活，会想法设法让领导知道，小李则会有点显得比较清高，做了啥也不说，觉得邀功显得不太好，自己好好干，领导肯定会看到。然而升职的时候，领导选择了小张，而不是小李，小李觉得自己很委屈。 他们不一定是程序员，我想请教下老师，对于我们程序员，是不是也要像小张这样，用一些职场政治的手段，但是程序员的工作环境相对比较单纯一些，毕竟大家都是工科男，用了会不会弄巧成拙呢？（追加一点，我指的是大多数程序员，大牛除外）
2020-07-01 - jhren 👍（5） 💬（3）
臧老师好，请教两个问题 1. 有同事问问题，就是把分他的任务直接问过来，该如何沟通让他问对问题？ 2. 遇到过几个刚毕业的同事，就是期望同事能像老师那样提供耐心并且无微不至的帮助，该如何让他们认清职场的原则呢？
2020-07-01 - 6点无痛早起学习的和尚 👍（3） 💬（1）
关于请教式沟通：分享一下自己的 checklist 【分享】高效寻求帮助的六大步骤（checklist） 1. 首先应该先跟对方讲清楚事情的背景是什么（要清楚+简洁），以及你为什么要做这件事情。（如果有人一来就跟你说：能帮我做下这个吗，其实是有点懵的）。 2. 阐述事情的重要性或者是不是有时间点要求，特殊性什么的。（方便对方做判断） 3. 需要解释下：也考虑过，或者尝试过一些其他的方法，但是都不okay，所以想请对方帮忙看下。 4. 如果对方真的很忙，或者很为难，还是要给他一个出口/选择的：ta有没有其他推荐的人可以帮你，或者其他的办法。（主要是解决这个问题，也不是一定要麻烦/为难他） 5. 过程中，不能别人帮你，你就什么都不做了。还是要follow up或者看看自己能做些什么。 6. 最后别人帮你处理好了，要表示下感谢。有时候会看到有些同学，帮他们处理完了，然后他们就不见了（也挺烦人的）。 以下事项，能避免就避免 态度切忌傲慢，不要把对方帮你忙认为是理所当然。
2021-08-17 - 有学识的兔子 👍（2） 💬（1）
个性有时候真的需要合适的环境才能发挥作用。以前的国企工作的时候，明显感觉到做事不是那么重要，反而错综复杂的上下级关系。这种氛围下，对于干活多话不多且个性不够张扬没有啥背景的人，还是很吃亏的。这种环境下，出活多少不是最重要的要素。
2020-07-02 - J.Smile 👍（1） 💬（2）
有时候汇报工作会提出一些问题，目的是让经理知道工作中的风险和难点。但似乎经理并不关心，反而怀疑你的能力，可是他自己也没有提出什么好的办法。作为下属，有时候自己会尝试问一些有点挑战，或者说难度的问题以期待可以从上级那学到点什么。请问臧萌老师，站在经理的角度是不是觉得我太事儿呢，或者说我在刻意挑战他的能力？
2020-08-08 - Sdylan 👍（1） 💬（2）
现在做完需求，抽空写文档，别人来问，仍他一个文档，先看一下。有问题再问我，文档共享的时候抄上组长和经理。
2020-07-20 - pyhhou 👍（1） 💬（3）
受益匪浅 对于向上沟通那里，就我自己来说，可能是目前的公司的机制问题，我的经理既负责技术，又负责管理。因为公司内部文档不清晰，但团队中只有经理对公司的一些系统有更深，更全面的了解，而且任务也是经理下达的。所以很多时候，技术方面的种种问题也都问经理，问其他同事，就算是其他同事给了一些意见，等到落实的时候，也还是必须去和经理确认。所以不管是技术上，还是工作分配上，有问题基本上都会去请教经理。除非是某个领域刚好有其他同事负责，才会去问其他同事 知道这样其实不是一个高效的管理制度，但是只能是做好自己的事情，尽量把问题都记下来，等到每周的 1-1 会议时再向经理请教
2020-07-02 - Geek_3b1096 👍（1） 💬（1）
非常有帮助
2020-07-01 - 源以南 👍（0） 💬（1）
添加一个对下沟通，多给下属思考的机会，不要只告诉他们该怎么做，让他们多思考。尽量通过自己的思考完成事情，过程中给予协助，这样未来你可以有更多时间做自己的事情。
2020-11-09