必读！如何有效的进行沟通
会说话的波吉
揭露行业真相
2022年的春节即将到来，大家也都在做一年内的总结。波吉也不想一直吐槽行业内的弊病，是时候传播一些正能量。
其实很多时候工作没有做好恰恰源于信息沟通上的问题，于是本篇文章只是想跟大家聊聊沟通的问题。本文十分实用，希望大家广泛传播。
一句话：
FXXX那些不懂得交流沟通的家伙。
首先
工作中的沟通总是有明确的原因，那么也就有明确的预期目标。
大致可以分为以下几种：
原因 | 目标 |
传达意思 | 让对方理解所传达的内容 |
委派工作任务 | 让对方理解工作任务内容，并能够正常开展工作 |
工作汇报 | 让对方了解自己手头任务的现状，以及未来预期 |
寻求帮助 | 让对方了解自己所遇到问题的详细情况，并使对方掌握足以解决问题的信息 |
不同的沟通原因及目标，在实际操作过程中多少存在差异。
传达意思
「传达意思」常见于推出制度规范，提出要求等场合。
在传达意思时，除了一些显而易见，无需解释的情况（如：最后离开公司的人负责关灯），额外附上具体说明原因，事例等，可以更好地让对方对事情的理解，从而保证意思的传达可以真正落实。
反例（理解过度）：
组长
写代码的时候记得写注释！
好的！
（花了1星期给每一行都写上了注释）
组员
组长
不要每行代码都写注释啊
写那么多没用的还浪费时间！
不是你让我写的么？？
组员
正例：
组长
写代码的时候记得加上注释！
组长
比如那些复杂的算法，特殊例外处理，临时修改的地方；
时间久了会忘记了当初为什么这么写
好的！
组员
委派任务
「委派任务」在工作中很常见，但由于一定是领导向下属委派任务，往往也容易出现问题而不自知。
有的领导可能因为比较忙，习惯性地以对待老手的方式向新人或者新接手业务的下属委派任务，预设对方已经知道了所有事情。但这样很难称得上是有效的沟通，工作很可能根本没有办法得到切实推进，最终结果可能只是让领导更忙而已。
因此，委派任务时，除非对方是老手，否则在委派任务时，相关的必要信息应当一并提供。如有必要，也要确认好大致工作内容，避免对方陷入迷茫和盲目，甚至完全偏离任务目标。
最终保证对方「已经了解足以完成任务的所有信息」，即使存在不了解的部分，也要保证对方知道可以从哪儿去了解（如：可参考的文档，可咨询的同事等）。
反例（信息提供不全）：
领导
你把最近3个月的新客户信息整理一下
好的！
新人
（我好像啥都不知道啊？）
请问客户信息是在哪儿看的？
新人
领导
就那个CRM系统，地址是http://xxx.company.com
好的！
新人
（我好像没账号）
登录好像要账号，我应该找谁？
新人
领导
你找张三给你开一个账号吧
好的
新人
（进去了，好复杂的系统，这不会用啊，也不敢乱点）
这个客户信息是不是这里？
新人
领导
你问题怎么这么多！不会自己研究么？
好吧...
（压力山大，不知道后面要问谁）
新人
正例：
领导
你把最近3个月的新客户信息整理一下
领导
你先去找张三给你开CRM系统的账号；
然后找李四问一下具体操作，他之前做过这一块
好的！
新人
工作汇报
有工作安排就有工作汇报。工作汇报包括简单的口头汇报，到完整的周报，无论哪种汇报，都应该写明哪个项目的哪个任务，现状如何，未来预期如何。
其次，在工作中途遇到困难，导致工作延期、或者无法推进的，应当主动立刻汇报，而不是等别人来问了才回答。
最后，工作中的每个人应当时刻注意自己所在岗位所具有的「权限」。比如，研发可以决定一个功能怎么做出来，也可以提议增减功能，但没有权限直接添加或者删除一个功能。遇到超权限的事情，一定要主动向上汇报，切不可擅自行动。
反例（信息提供不全）：
组员
功能XXX做得差不多了
什么的功能XXX？？
组长
组员
就A项目的那个XXX功能
哦，那差不多是什么意思？
可以开始测试了么？
组长
组员
还差一点
？？？差哪点
组长
组员
就是最后发送邮件的部分还没好
哦，那什么时候能好？
截止日期就明天了啊
组长
组员
应该可以
（为什么不能一次把话说完）
组长
正例：
组员
A项目的XXX功能，可以开始测试了
但是最后的邮件发送部分要等到明天
好的
组长
反例（不到最后绝不汇报）：
组员
（闷声开发了一星期）
A项目的XXX功能明天就截止了
做得怎么样了？
组长
组员
来不及了
怎么来不及了？
这功能不是都做了一个星期了么？
组长
组员
这里有块处理，要等第三方对接，就这花了我五天时间
你早点不说？
组长
正例：
组员
（接到任务后大致看了一遍需求）
这次A项目的XXX功能，有块处理不是很好弄，要等第三方对接；
一星期可能做不下来
好，那我调整一下
组长
寻求帮助
「寻求帮助」应该是工作中最常见，最普遍的沟通了。可以说，任何两个同事之间都有可能进行有关寻求帮助的沟通。
在这种沟通中，最最重要的就是永远都不要预设对方已经了解事情的全貌。应当始终先讲清楚事情的由来，提供必要信息（如：完整的截图、URL地址、各种ID等），且URL、ID等应当提供文字版方便对方复制，而不要给文字截图。
反例（过于狭窄的提问）：
同事A
我们的产品可以采集XXX系统的数据么？
不能
（确实没有对应的采集器）
同事B
同事A
（看来这个客户做不了）
正例：
同事A
我这边有个客户，很多年前上的一套XXX系统，发现时不时会自动退出。
有没有什么办法可以监控？
可以使用YYY功能
同事B
反例（过于含糊的提问）：
同事A
怎么发邮件？
我不知道怎么回答你
（你是谁？你在做什么？要想要什么效果？）
同事B
正例：
同事A
我手头有个注册成功后给用户发送欢迎邮件的功能；
这个邮件有没有统一发送接口？还是直接自己做？
不用自己做，调用XXX的API发送就行；
文档在这里：http://xxx.company.com
同事B
反例（犹抱琵琶半遮面式提问）：
同事A
页面报错了！
报什么错？
同事B
同事A
[图片：一小块报错文字截图]
这是哪儿的截图
同事B
同事A
事件列表这里
你的工作空间ID是什么？
同事B
同事A
[图片：工作空间ID的截图]
不是，你截图我没法复制文字啊
同事B
同事A
wksp_xxxxxx
（好累...）
同事B
正例：
同事A
我在事件列表页面，点击详情时页面报错了。
报错信息是 xxxxxxxxxxxxx
工作空间ID是 wksp_xxxxxxxx
同事A
[图片：整个窗口的截图]
好的，我看一下
同事B
应当避免的沟通案例
错误的沟通方式不仅得不到有效的信息，往往还很容易引起对方的反感。在工作中应当极力避免这类错误的沟通方式。
急功近利，缺乏尊重
同事A
我们的产品可以采集XXX系统的数据么？
你是什么客户？什么场景？
同事B
同事A
你只要告诉我，行还是不行？
？？？
（我可以直接回答「不行」，但我也感觉不能这么简单回答）
同事B
员工A
XXX功能什么时候上？
这个功能已经排在计划中了，上线后会通知的
员工B
员工A
你就告诉我什么时候上，我客户在等着呢
？？？
（你的心情可以理解，但应该不是这个道理）
员工B
断章取义，拒绝思考
同事A
可以实现XXX功能么？
目前是没有的，因为这个不是一个普遍的功能；
但是可以通过YYY的方式达到这个效果，需要进行ZZZ的操作
同事B
同事A
那就是没有这个功能，是吧
？？？
（这么说的确没错，但总觉得哪里不对）
同事B
三字一句，堪比诗人
同事A
在吗？
同事A
我有个问题
同事A
想问你一下
同事A
产品的问题
同事A
你知道的吧？
同事A
不知道能不能采集XXX系统的数据
？？？
同事B
（噼里啪啦一大串，结果就是一句话，心累...）
同事B
评：短时间内大批消息提示会给人造成很大的心理压力，打断手头的工作，零碎的短句也不方便将聊天内容加入「稍后处理」或者「代办」、「任务」等，应当尽量一次性把事情说完
文字到底，绝不电话
同事A
在吗？有个事情很着急啊！
同事A
在吗？
同事A
快点，客户在等着呢！
？？？
（真着急为啥不直接打电话...）
同事B
评：文字聊天始终存在沟通效率的局限性，对于真正紧急的事情，应当打电话确认（注意是电话，不是网络电话）
大事小事，都打电话
同事A
[电话]
同事A
[电话]
同事A
[电话]
同事A
[电话]
？？？
（我也有自己的活要干，别什么事情都打电话来打断我啊！）
同事B
评：打电话一般作为紧急沟通方式，沟通效率高但也干扰了对方的工作，注意不要滥用
忽视文档，不愿搜索
同事A
AAA系统怎么安装？
文档里有
同事B
同事A
XXX功能返回的数据结构是什么啊？XXX功能返回的数据结构是什么啊？
文档里有
同事B
同事A
YYY是什么意思啊
百度一下
同事B
评：文档要读完整，有问题应当先搜索，直接找人问看似很积极，实际只是在浪费他人时间而已
后记
好的沟通不仅可以提高工作效率，减少失误，同时也能让双方都心情舒畅，总结起来其实就一句话：「为对方着想」。
最后祝愿大家能够沟通顺畅，工作顺利！