临近上午九点半，微信、QQ消息狂风滥炸，未处理邮件开始增多，繁忙的一天已经开始。
我尽量把微信、QQ设置在每半小时查看一次处理一次。邮件取消自动收取，分三次手工集中处理，上午9点30处理一次，中午13点30分一次，下午16点30分一次。
在职场办公工具中，QQ的江湖地位在逐渐降低，用微信谈事的占比越来越高。我真正用微信是2016年，以前对它一直是排斥的，感觉自己的时间全被微信QQ打碎和占用了。
说那么多，为什么后面就用了？因为领导在用……
MAC OS上安装的微信客户端，无法取消屏幕右上角的微信消息展示，而我又有红点强迫症，看到那个不断增加的数字，就非常想点开，极大影响了我的工作效率。
mac系统无法设置对微信消息通知的隐藏，最后用了一个第三方工具，把微信图标隐藏了。
以上其实都不算什么，最让人心力交瘁的其实是沟通效率太差。
这类典型场景大致分三种：
1、开头不谈事，先打招呼型的
“hi”、“在？”、“在吗？”、“有人吗？”
2、说事情婆婆妈妈型的
“王总，我有个事，不知能不能说？”、“王总，我想了很久，决定和你汇报下”
3、说事没重点的
喏，今天就碰到了。
“王总，我们系统出问题了。”
我立刻反问，“出了什么问题？”
“也没什么，就是系统页面打不开，我把它重启了。”
“原因查到没？”
“还没有。也不知怎么回事，以前都是好好的。”
……
类似这种一问一答的沟通，效率极差。有必要解决这个问题。
我深思良久，提笔整理了一份个人沟通提升方案。对弟兄们宣贯、落实。
心法：体谅对方，尊重自己。
分析：5W2H原则
（1）WHAT——是什么？目的是什么？做什么工作？
（2）WHY——为什么要做？可不可以不做？有没有替代方案？
（3）WHO——谁？由谁来做？
（4）WHEN——何时？什么时间做？什么时机最适宜？
（5）WHERE——何处？在哪里做？
（6）HOW ——怎么做？如何提高效率？如何实施？方法是什么？
（7）HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
解决：SMART原则
（1）必须是具体的（Specific）
（2）必须是可以衡量的（Measurable）
（3）必须是可以达到的（Attainable）
（4）要与其他目标具有一定的相关性(Relevant)
（5）必须具有明确的截止期限（Time-bound）
（6）表述方式：由谁负责，有谁参与，通过哪三条路径，在多久时间内，完成什么工作，解决什么问题。
收尾：沟通一句话原则
让微信沟通也像邮件那样，把需要决策、协调、执行的事情，一次性写完，这样，领导知道如何决策、同事明白如何配合、员工知道如何执行。从而减少各种沟通的环节。
就像我们写邮件时，难道还会先发个“在吗？”
为简化练习复杂性，就以本次系统故障汇报为例。经过指导，最新修改稿如下：
王总，客户感知系统出现故障，已修复。Tomcat设置内存过小，当系统并发量大时，造成内存溢出，引发页面故障。
2020.5.13 8点30分，客户报障系统无法打开；
2020.5.13 8点45分，我们立刻将相应日志保存，对系统进行重启；
2020.5.13 8点50分，系统恢复正常
2020.5.13 9点30分，我们检查日志并定位到问题，计划今晚22点我负责将tomcat运行内存调整到8G。
“客户知道此事吗？汇报没有？”我提出遗漏之处。
针对工作汇报。如果领导有疑问。说明汇报内容我们还没有考虑周全，这应是下一步改进的方向。
最终的效果应是你发的一个情况汇报，领导直接答复：OK、好的、Good、Very Good。
过了十分钟，我收到了这条微信消息：
王总，客户感知系统出现故障，已修复。Tomcat设置内存过小，当系统并发量大时，造成内存溢出，引发页面故障。
2020.5.13 8点30分，客户报障系统无法打开；
2020.5.13 8点45分，我们立刻将相应日志保存，对系统进行重启；
2020.5.13 8点50分，系统恢复正常
2020.5.13 9点30分，我们检查日志并定位到问题，计划今晚22点我负责将tomcat运行内存调整到8G。
原因已向客户当面汇报。由于处理及时，本次影响面较小，客户答复不必升级上报。客户已同意晚上的调整实施计划。
* 作者简介：王不留，早晨四点开启奔跑人生的一枚非典型程序员。
关注微信公众号「程序员生存指南」，收看更多精彩内容
