跳转至

如何避免无效的沟通(一)

2023-03-09

本文主要探讨在工作中与他人进行沟通、沟通、协作时的一些建议。

1. 前言

日常生活中,我们会和他人进行交流。有些可能出于习惯和礼貌,或者单纯的闲聊。而我们在与他人发起工作上的沟通时,总是会有一个明确的原因。比如寻求帮助,搜集意见或建议等。

因此,不同于日常生活中的交流,工作中的沟通更需要讲究方式和方法,追求沟通背后目标的达成。

2. 沟通的类别及目标

工作中的沟通总是有明确的原因,那么也就有明确的预期目标,大致可以分为以下几种:

原因 目标


传达意思 让对方理解所传达的内容 委派工作任务 让对方理解工作任务内容,并能够正常开展工作 工作汇报 让对方了解自己手头任务的现状,以及未来预期 寻求帮助 让对方了解自己所遇到问题的详细情况,并使对方掌握足以解决问题的信息

不同的沟通原因及目标,在实际操作过程中多少存在差异。

2.1 传达意思

「传达意思」常见于推出制度规范,提出要求等场合。

在传达意思时,除了一些显而易见,无需解释的情况(如:最后离开公司的人负责关灯),额外附上具体说明原因,事例等,可以更好得让对方对事情的理解,从而保证意思的传达可以真正落实。

反例(理解过度)

组长 组员 写代码的时候记得写注释! 好的! (花了 1 星期给每一行都写上了注释) 不要每行代码都写注释啊
写那么多没用的还浪费时间!
(不是你让我写的么??)

正例

组长 组员 写代码记得加上注释 比如那些复杂的算法,特殊例外处理,临时修改的地方
时间久了会忘记了当初为什么这么写
好的!

2.2 委派任务

「委派任务」在工作中很常见,但由于一定是领导向下属委派任务,往往也容易出现问题而不自知。

有的领导可能因为比较忙,习惯性地以对待老手的方式向新人或者新接手业务的下属委派任务,预设对方已经知道了所有事情。但这样很难称得上是有效的沟通,工作很可能根本没有办法得到切实推进,最终结果可能只是让领导更忙而已。

因此,委派任务时,除非对方是老手,否则在委派任务时,相关的必要信息应当一并提供。如有必要,也要确认好大致工作内容,避免对方陷入迷茫和盲目,甚至完全偏离任务目标。

最终保证对方「已经了解足以完成任务的所有信息」,即使存在不了解的部分,也要保证对方知道可以从哪儿去了解(如:可参考的文档,可咨询的同事等)。

反例(信息提供不全)

领导 新人 你把最近 3 个月的新客户信息整理一下 好的 (我好像啥都不知道啊?) 请问客户信息是在哪儿看的? 就那个 CRM 系统,地址是http://xxx.company.com 好的 (我好像没账号) 登录好像要账号,我应该找谁? 你找张三给你开一个账号吧 好的 (进去了,好复杂的系统,这不会用啊,也不敢乱点) 这个客户信息是不是这里? 你问题怎么这么多!不会自己研究么? 好吧 ... (压力山大,不知道后面要问谁)

正例

领导 新人 你把最近 3 个月的新客户信息整理一下 你先去找张三给你开 CRM 系统的账号,
然后找李四问一下具体操作,他之前做过这一块
好的

2.3 工作汇报

有工作安排就有工作汇报。工作汇报包括简单的口头汇报,到完整的周报,无论哪种汇报,都应该写明哪个项目的哪个任务,现状如何,未来预期如何。

其次,在工作中途遇到困难,导致工作延期、或者无法推进的,应当主动立刻汇报,而不是等别人来问了才回答。

最后,工作中的每个人应当时刻注意自己所在岗位所具有的「权限」。比如,研发可以决定一个功能怎么做出来,也可以提议增减功能,但没有权限直接添加或者删除一个功能。遇到超权限的事情,一定要主动向上汇报,切不可擅自行动。

反例(信息提供不全)

组员 组长 功能 XXX 做得差不多了 什么的功能 XXX?? 就 A 项目的那个 XXX 功能 哦,那差不多是什么意思?可以开始测试了么? 还差一点 ???差哪点? 就是最后发送邮件的部分还没好 哦,那什么时候能好?截止日期就明天了啊 应该可以 (为什么不能一次把话说完)

正例

组员 组长 A 项目的 XXX 功能,可以开始测试了
但是最后的邮件发送部分要等到明天

反例(不到最后绝不汇报)

组员 组长 (闷声开发了一星期) A 项目的 XXX 功能明天就截止了,做得怎么样了? 来不及了 怎么来不及了?这功能不是都做了一个星期了么? 这里有块处理,要等第三方对接,就这花了我五天时间 你早点不说??

正例

组员 组长 (把需求后大致看了一遍) 这次 A 项目的 XXX 功能,有块处理不是很好弄,要等第三方对接
一星期可能做不下来
好,那我调整一下

2.4 寻求帮助

「寻求帮助」应该是工作中最常见,最普遍的沟通了。可以说,任何两个同事之间都有可能进行有关寻求帮助的沟通。

在这种沟通中,最最重要的就是永远都不要预设对方已经了解事情的全貌。应当始终先讲清楚事情的由来,提供必要信息(如:完整的截图、URL 地址、各种 ID 等),且 URL、ID 等应当提供文字版方便对方复制,而不要给文字截图。

反例(过于狭窄的提问)

同事 A 同事 B DataKit 可以采集 XXX 系统的数据么? 不能 (确实没有对应的采集器) (看来这个客户做不了)

正例

同事 A 同事 B 我这边有个客户,很多年前上的一套 XXX 系统,发现时不时会自动退出。
有没有什么办法可以监控?
可以使用 YYY 功能

反例(过于含糊的提问)

同事 A 同事 B 怎么发邮件? 我不知道怎么回答你 (你是谁?你在做什么?要想要什么效果?)

正例

同事 A 同事 B 我手头有个注册成功后给用户发送欢迎邮件的功能
这个邮件有没有统一发送接口?还是直接自己做?
不用自己做,调用 XXX 的 API 发送就行
文档在这里http://xxx.company.com

反例(犹抱琵琶半遮面式提问)

同事 A 同事 B 页面报错了! 报什么错? [图片:一小块报错文字截图] 这是哪儿的截图? 事件列表这里 你的工作空间 ID 是什么? [图片:工作空间 ID 的截图] 不是,你截图我没法复制文字啊 wksp_xxxxxx (好累 ...)

正例

同事 A 同事 B 我在事件列表页面,点击详情时页面报错了。
报错信息是 xxxxxxxxxxxxx
工作空间 ID 是 wksp_xxxxxxxx
[图片:整个窗口的截图] 好的,我看一下

3. 应当避免的沟通案例

错误的沟通方式不仅得不到有效的信息,往往还很容易引起对方的反感。在工作中应当极力避免这类错误的沟通方式。

3.1 急功近利,缺乏尊重

同事 A 同事 B DataKit 可以采集 XXX 系统的数据么? 你是什么客户?什么场景? 你只要告诉我,行还是不行? ??? (我可以直接回答「不行」,但我也感觉不能这么简单回答)

同事 A 同事 B 观测云的 XXX 功能什么时候上? 这个功能已经排在计划中了,上线后会通知的 你就告诉我什么时候上,我客户在等着呢 ??? (你的心情可以理解,但应该不是这个道理)

3.2 断章取义,拒绝思考

同事 A 同事 B 观测云可以实现 XXX 功能么? 目前是没有的,因为这个不是一个普遍的功能
但是可以通过 YYY 的方式达到这个效果,需要进行 ZZZ 的操作
那就是没有这个功能,是吧 ??? (这么说的确没错,但总觉得哪里不对)

3.3 三字一句,堪比诗人

同事 A 同事 B 在吗? 我有个问题 想问你一下 DataKit 的问题 你知道的吧? 不知道能不能采集 XXX 系统的数据 ??? (噼里啪啦一大串,结果就是一句话,心累 ...)

评:短时间内大批消息提示会给人造成很大的心理压力,打断手头的工作,零碎的短句也不方便将聊天内容加入「稍后处理」或者「代办」、「任务」等,应当尽量一次性把事情说完

3.4 钉钉在手,万事皆 Ding

同事 A 同事 B [Ding] 在吗? ??? (你都 Ding 了倒是说清楚啥事呀!)

评:钉钉的 Ding 其实是个没用的功能。紧急事情应该直接打电话,不紧急的留言,Ding 充其量就只适合在发公告时用一下,聊天用 Ding 并无必要

3.5 文字到底,绝不电话

同事 A 同事 B 在吗?有个事情很着急啊! 在吗? 快点,客户在等着呢! ??? (真着急为啥不直接打电话?)

评:文字聊天始终存在沟通效率的局限性,对于真正紧急的事情,应当打电话确认(注意是电话,不是网络电话)

3.6 大事小事,都打电话

同事 A 同事 B [电话] [电话] [电话] [电话] ??? (我也有自己的活要干,别什么事情都打电话来打断我啊!)

评:打电话一般作为紧急沟通方式,沟通效率高但也干扰了对方的工作,注意不要滥用

3.7 忽视文档,不愿搜索

同事 A 同事 B DataKit 怎么安装? 文档里有 XXX 功能返回的数据结构是什么啊? 文档里有 YYY 是什么意思啊 百度一下

评:文档要读完整,有问题应当先搜索,直接找人问看似很积极,实际只是在浪费他人时间而已

后记

好的沟通不仅可以提高工作效率,减少失误,同时也能让双方都心情舒畅,总结起来其实就一句话:「为对方着想」。

最后祝愿大家能够沟通顺畅,工作顺利!