冷静下来，仔细思考了一下。虽然薪资低，倒挂严重，但是日子还算清闲舒服，每天研究工作吃啥水果，偶尔下楼溜溜弯，呼吸新鲜空气(免责声明:如果因为看到我清闲，进来发现忙吐血，不能怪我，我不负责)。
工作有一段时间了。因为组织架构调整，一方面要接手坑很多，涉及交割方也很多的项目，一方面也是开始做很多需要推动的事情。再加上因为当客服，作为一些组件的负责人需要接需求。
大量的事情需要沟通，谈判，协调。每天最多的事情就是开会，拉群沟通。这些事情有着以下特点:
1.涉及的利益方多，难以协调平衡。
2.细节多而杂，而且会有许多比较trick的细节，让人怀疑人生。
3.跨背景交流，理解难度大。
非常考验我的耐心，沟通，对线水平。事实证明，我差的一逼。
做这些事情，主要需要和两类人交流。一类是，不同业务的同学。一类是，团队里的同事老板。
先说和大量业务同学交流这点。我写了一版事情的原委，然后发通告给相关的人。结果所有的人都看不明白……不清楚做什么。
后来改了一版，告诉同学们，需要做什么。结果许多人，做错了。继续来问，怎么回事。orz……
再改一版，我按照同学反馈的问题再补充进文档。文档越写越多。业务:字太多了不想看……直接三连问，啥情况？咋回事？咋整啊？
其实工作场合的业务诉求，就两个。我要干这个事情，我只有手，怎么实现?我要这个问题的答案，我不想找也不想看很多东西，直接给我这个答案就行。
好的文档，应该也是可测试的，照着做不会出问题的。如果出问题，那就是文档的bug，不仅仅是项目代码的bug。
第二个，文档字数要少，讲的事情少，减少别人的认知负担。屏蔽许多别人不需关注的背后的原理。可以用超链接的形式，满足一下少部分好奇的业务。
其实第二类和第一个类似，只不过没有那么多迭代的机会。
事情细节非常的多，把复杂的事情讲的简单，举重若轻，是需要时间成本去梳理才能够实现的。但是按工作的繁忙程度来看，花费时间去做平时的汇报，是否值得，这个是见仁见智的。
如果事情复杂到一定程度了，叽哩哇啦一堆细节，其实别人也是听懵的状态。还是梳理成文档，按文档去描述。这就回到第一个问题上了……
总结一下:交流高效，一定是事前要费时间把东西梳理清楚，屏蔽细节，然后拿最简单直接的东西给对方。
更多技巧可参考《金字塔原理》。
全部评论
(2) 回帖