20 | 为什么世界和你的理解不一样？

沟通问题极其常见，比如布置任务、团队协作、理解需求等场景下。有人介绍过日本公司如何布置任务，以消除沟通中双方理解的差异。实际是否如此，没有求证过，但值得我们学习。方法是布置任务至少要沟通五次，和有些领导喜欢说的“我只讲一次”大相径庭。第一次说，任务是什么什么。下属说，知道了。第二次说，你复述一下。下属巴拉巴拉讲一遍，没错。还不行，第三次说，你觉得这事的目的是什么。下属讲清楚了刚要走又被拉住，第四次，你觉得做这些事会遇到什么问题，哪些你可以自己决定，哪些你需要先汇报再决定。等下属讲后，再问第五遍，你有没有更好的建议

不同角色间的沟通：克服上下文差异，分段解码，理解偏差早发现早反馈。相同角色间的沟通，信号相同，解码能力因人而异，要有一个主导的人，控制沟通广度与深度，抓主线适可而止，此时结合任务分解，反向沙盘推演。

我要是两年前读到这专栏，会少走很多弯路，会减少不必要的焦虑。希望老师更新完专栏，出纸质书。🌹

你对信息编码有问题，就别期待别人解码能对了。 关于信息地编码、解码，我的做法有 2 个： 1. 讲话前，想好说什么； 沟通前，我会先理清楚：我是怎么一个情况？想从他身上得到什么？ 然后，就组织语言，开启这段沟通。等沟通准备结束时，我再总结说一次。 另外，如果可能，我会让别人向我再复述一遍。 2. 听完后，复述一遍； 别人讲完后，我会用自己的语言，对他重新说一次，然后问：你是这个意思吗？ 如果有错误，就听对方继续说，听完再复述一遍。不断循环，直到对方说：是，就这个意思。

很多程序员讲东西的通病-讲东西直奔细节！和产品和测试交互的时候，你和他说List Set Map，那是在鸡同鸭讲，沟通成本更高了！

自己改善了编解码和算法，但是其他人没有改善，是不是也是达不到理想的效果，希望所有人都能认识到这一点，这才是根本啊

通信系统中的香农定理啊，泪奔，这个图大学考了好多次了，我自己都画了好多次了。我理解的把自己扩大的上下文分享到别人身上，尤其和人沟通的时候，因为自己知道并不一定别人知道，很多东西都是个人臆想的。信息不对称才会导致问题越多，只有同时站在一条线上，再来探讨深度与广度，才有不同的火花

已读不回，咋办？

很好的文章，受教了。除了增长见识，学习借鉴一些行业里面的最佳实践，像前面说到的提升自己在工作中的上下文，也是增强沟通反馈的一个方式，但是这些东西都需要长期的积累以及观察实践，不去反复执行加思考，终究不能内化为自己的东西；觉得这个专栏最有价值的就是老师给了一个很明确的方向和一些非常好的思维模式，让自己在工作中面对棘手的事情时，能够很清楚地知道怎样做才是合理的，而不是盲目地去用自己觉得舒服、习惯的方式方法解决问题。刚入职不到一年，可能还是需要不断的经验积累才能深刻体会专栏中的很多的实践总结，但是相信对这些东西有个了解总会让自己少走不少弯路

最近碰到一个产品经理，喜欢口头说需求，吧啦吧啦讲一大堆复杂逻揖，等需求做好，又吧啦吧啦说改逻辑，和这样产品经理共事真累，沟通最好基于文档沟通，不能只是口头形式。