极客时间已完结课程限时免费阅读

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

20 | 为什么世界和你的理解不一样?-极客时间

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

讲述:郑晔

时长12:53大小11.80M

你好,我是郑晔。
从今天起,我们要开启一个新的模块:沟通反馈。
如果看到沟通反馈几个字,你就以为我打算在这里教一些谈话技巧,那你还真的想错了。
在这个模块里,我打算与你讨论的主题是,生活在真实世界中。沟通反馈和生活在真实世界这两个话题是怎么联系到一起的呢?请听我慢慢道来。
《大富翁》里的沙隆巴斯有句口头禅:人生不如意的事,十有八九!但是不知道你有没有想过这样的一个问题,为什么人生如此不如意?如果这是一篇鸡汤文,我应该告诉你世事艰辛。但我要说的是,真实的原因往往是因为你想得太美好,用我们做软件的例子来看一下:
在我们的愿望中,做出来的产品应该一举成名,现实却是惨淡经营;
在我们的愿望中,产品经理给出的需求应该是清晰明了的,现实却是模模糊糊;
在我们的愿望中,写出来的代码,应该是快捷无错的,维护也很容易,现实却是 Bug 百出,越修改,修改的时间就越长;
在我们的愿望中,你给我布置任务,我应该迅速地理解到关键,现实却是做出来的与你的目标根本就是天差地别;
……
为什么会这样?欢迎来到真实世界,真实世界不是以美好愿望驱动的,它有着自己的运行规律。虽然我们都生活在同一个世界中,但每个人理解世界的方式确实是千差万别。
我们努力地学习各种知识,为的就是更好地理解这个世界的运作方式,而沟通反馈,就是我们与真实世界互动的最好方式。
你也许会好奇,为什么我们对世界的理解会出现偏差?接下来,让我们一起用一个信息论的视角看一下。

一个信息论视角的解释

1948 年,克劳德·香农(Claude Elwood Shannon)在《贝尔系统技术学报》(Bell System Technical Journal)上发表了一篇论文《通信的数学原理》(A Mathematical Theory of Communication),这是现代信息论的开端。我们程序员熟知的通信、数据压缩、密码学、自然语言处理等诸多领域都有信息论的身影。
我们这里要借鉴的是香农信息论中的一个通信模型,如下图所示:
这个图中包含了几个要素:
信源(Information Source),它负责产生信息(Message)。
发送器(Transmitter),它会对信息进行某些操作,也就是对信息编码,产生信号(Signal)。
信道(Channel),它是信号传送的媒介。
接收器(Receiver),它是对信号执行发送器的逆操作,解码信号,提取出信息。
信宿(Destination),它负责接收信息。
当然,图中还有一个因素叫做噪声(Noise),指的是削弱信号的东西。不过,它并不是我们这里讨论的重点,我们暂时忽略它。
我们用一个实际工作中的例子来理解一下这个过程。假设你的项目经理来给你布置一项工作,在这里,项目经理就是一个信源。他的想法就是他的消息,他要把这件事告诉你,先要在大脑中做一次编码,转换成语言表达出来。他说出来的这段话就是信号。
比如,这个信号是“完成一个需求”。这段话通过信道,也就是空气传播到你耳朵里,接收到这段话之后,你会按照自己对这段话的理解进行解码,作为信宿的你,形成了自己的想法,这就是你接到的消息,整个过程就完成了。
我们来看一下,理解偏差是怎么产生的。
项目经理给你传输的信号是“完成一个需求”,在项目经理脑子中,这个信号的原始信息可能是这样的:编写完成这个功能所需的代码,然后为这段代码写好自动化测试,再将它与现有系统集成好,通过测试人员的验证。
而在学习这个专栏之前,你从“完成一个需求”这个信号中解码出来的信息却是:把功能代码写完。这样,问题就出现了。即便这里忽略了噪声的干扰,当编码和解码不是一个版本的时候,无论如何,项目经理的信息都很难准确地传达到你这里。
这就是人们往往对世界产生误解的原因。
信息的传达要经过编码和解码两个过程,无论是编码出现问题,还是解码出现问题,都会造成信息的不准确。
一方面,有些人表达不清楚,一件简单的事,他说了半天,你依然是云里雾里。这就相当于,信源发出的信息经过编码得到的信号已经不准确了。
另一方面,就像听一些技术演讲,人家说得很清楚,但因为自己没有相关背景,依然无法得知人家表达的信息。这就相当于信号虽然准确,但我们没有对应的解码装置,信号无法转成有效信息。
再有就是像前面这个例子,收发双方编解码器不配套,同样的信号得到的信息截然不同,信息传达的目的也不能很好地完成。
有了理论做基础,我们就容易理解世界为什么总和我的理解不一样,这就是编解码的过程出了问题。因为每个人经历见识的差异,造成了各自编解码器的差异。世界是同一个世界,每个人看到的却是千姿百态。
如果想在这个真实的世界中生活得更幸福一些,我们能做点什么呢?那就是改善我们的编解码器。怎么改善自己的编解码器呢?这就是“沟通反馈”这个模块要讨论的内容。

改善编解码

站在改善编解码效果的角度,我们要考虑哪些问题呢?
首先,我们要考虑一下编码器的效果。换句话说,当我们想把信息传达给别人的时候,我们得把信息编码成一个有效的信号,至少要保证在我们这里信息不丢失。
我举个例子,有一次,我在客户现场做咨询,客户的一个程序员给我介绍他们的系统,他讲了二十分钟,我还是听得一头雾水。于是,我打断他,花了五分钟用我的语言给他讲了一遍,然后问他:“你想说的是不是这个意思?”他猛劲点头:“就是这样的。”
为什么会这样呢?究其原因就是,他上来就在给我讲实现细节,完全没有任何铺垫。
要知道,我是来了解情况的,所以,我的背景知识肯定是不足的,凭空理解这些细节是非常困难的一件事。从沟通的角度上看,这么做浪费了大量的时间,因为在过程中,我要不断地让他给我补充这些缺失的背景。这几乎是很多程序员讲东西的通病:讲东西直奔细节。
我在面试中也经常遇到过类似的情况,一些候选人上来就给我讲技术细节,我对他做过的系统一无所知,所以,我只好打断他,让他先把背景给我介绍一下。
同样,很多人抱怨别人不能理解自己,其实,首先应该想的问题是,自己到底有没有把话说清楚。这就是编码器出现问题的情况。
其次,我们还要考虑一下解码器的效果,也就是说,当一个信号呈现在我们面前时,作为接收者,我们是否能够有效地解码信息。
著名作家王小波曾经讲过一个花剌子模信使的故事,说的是中亚古国花剌子模有一个奇怪的风俗,凡是给君王带来好消息的信使,就会得到提升,给君王带来坏消息的人则会被送去喂老虎。如此一来,谁还敢把坏消息带给君王呢?但问题是,君王不听坏消息,坏消息就不存在了吗?
这就相当于解码器出了问题,过滤掉了很多真实的信息。但真实世界就是真实世界,它不会按照人们的美好愿望运行。
再举一个我们身边的例子,能做程序员的人,大多是很聪明的人, 当几个人一起讨论问题时,别人往往刚开了个头,他就认为自己已经理解了别人的想法,然后开始表达自己的观点。信息都不全,何谈解码。所以,开发团队的讨论中常常出现一个人高谈阔论,却离题万里的情况。
我们要想让自己更好地工作生活,就必须接纳真实世界的反馈,而接纳真实世界的反馈,一是需要我们打开自己的接收器,把信号接纳进来,让反馈进来,这是解码的前提;二是扩展见识,提升自己解码器的效果,更好地理解别人要表达的内容到底是什么。
说了编码器和解码器可能出现的问题,我们再来看另外一个可能造成影响的问题:编解码器算法,也就是怎么协调沟通双方更有效地进行沟通。
既然前面已经说了算法不够好会影响到信息的传递,那接下来的问题就是怎样找到一个好的算法。其实,我们从始至终在讲的各种最佳实践就是一个个好的算法,帮助我们改善沟通的效果。
还是回到前面提到“完成一个需求”的例子,我们在“以终为始”模块已经讲过了,通过制定“完成的定义”就可以帮助改善这个过程。这就相当于,沟通的双方都有了一个编解码手册。
当“完成一个需求”这样的信号发出时,作为接收方,你的解码动作就变成了,先要查一下手册里,关于“完成一个需求”的标准动作都有哪些。于是,你就不会对事情做那么简单的估计了。
在“沟通反馈”这个模块下,我还会给你介绍各种“算法”,也就是最佳实践,帮你在工作中提高“信息”传递的效率。
回到我们这部分主题上,沟通反馈就是改善编码、解码以及算法的方式。无论是“发送”得更清楚,还是“接收”得更明白,抑或是通过各种协调算法,都是为了让通信的双方做好准备。

总结时刻

人生不如意之事,十有八九,之所以很多人有如此多的不如意,很大原因在于我们对真实世界有着很多不切实际的幻想,美好的愿望并不能驱动这个世界,在软件开发中也是如此。虽然人和人生活在一个世界中,但对世界的理解却是千差万别的。
我们借用了信息论的一个通信模型解释为什么每个人看到的世界会有如此大的差异,其核心就在于,人和人拥有不同的编解码器。想要在这个真实世界中生活得更幸福一些,需要我们不断地改善自己的编解码器。
改善编解码,需要从几个角度着手,分别是:编码器,让信息能输出更准确;解码器,减少信号过滤,改善解码能力;还有编解码算法,也就是各种来自行业的“最佳实践”,协调沟通的双方。
如果今天的内容你只能记住一件事,那请记住:通过沟通反馈,不断升级自己的编解码能力。
最后,我想请你回想一下,你在工作中遇到过哪些因为沟通反馈不畅造成的问题呢?欢迎在留言区写下你的想法。
感谢阅读,如果你觉得这篇文章对你有帮助的话,也欢迎把它分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得20
生成海报并分享

赞 28

提建议

上一篇
划重点 | 关于“任务分解”,你要重点掌握哪些事?
下一篇
21 | 你的代码为谁而写?
unpreview
 写留言

精选留言(20)

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

    作者回复: 很好的分享!

    共 6 条评论
    105
  • 行与修
    2019-02-20
    不同角色间的沟通:克服上下文差异,分段解码,理解偏差早发现早反馈。相同角色间的沟通,信号相同,解码能力因人而异,要有一个主导的人,控制沟通广度与深度,抓主线适可而止,此时结合任务分解,反向沙盘推演。

    作者回复: 融会贯通了!

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

    作者回复: 很好的分享

    共 2 条评论
    15
  • 刘得淼
    2019-02-19
    我要是两年前读到这专栏,会少走很多弯路,会减少不必要的焦虑。希望老师更新完专栏,出纸质书。🌹

    作者回复: 多谢支持!纸质书的事,有出版社在联系,先坚持把专栏更新完,再想后续的事吧!

    15
  • 第一装甲集群司令克莱...
    2020-11-28
    很多程序员讲东西的通病-讲东西直奔细节!和产品和测试交互的时候,你和他说List Set Map,那是在鸡同鸭讲,沟通成本更高了!

    作者回复: 在《代码之丑》里,我把技术术语的命名当作一种坏味道。

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

    作者回复: 理论可以联系实际了。

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

    作者回复: 先改变自己,再考虑影响别人。

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

    作者回复: 你说的很对,其实,我给出的很多东西都是一些衡量标准,用它可以判定自己事情做得是否够好。再给出一些最佳实践实际上就是参考路径,你可以根据自己的实际情况进行取舍。

    2
  • Sudouble
    2019-02-21
    语言在传递过程中存在损耗,很独到的一个视角,学习了。

    作者回复: 多了解一些东西,就会发现很多难以解决的问题在别的领域已经有了很好的答案。

    1
  • 余为国
    2022-05-22
    已读不回,咋办?

    作者回复: 直接找人去

    1
  • ifelse
    2022-04-18
    沟通:信源,编码,解码,新宿
  • sky
    2021-08-20
    最近碰到一个产品经理,喜欢口头说需求,吧啦吧啦讲一大堆复杂逻揖,等需求做好,又吧啦吧啦说改逻辑,和这样产品经理共事真累,沟通最好基于文档沟通,不能只是口头形式。

    作者回复: 口头的需求,那叫拍脑袋。

  • 索旭东
    2020-03-26
    沟通反馈
  • 春之绿野
    2019-08-24
    关于沟通,真想吐槽三天三夜

    作者回复: 一言难尽啊!

  • 春之绿野
    2019-08-24
    前些天组长跟我说隔壁组的测试跑过了,我们这边拿过来可以直接用,跑一下就好了,结果是根本就没有好,还有很多问题,他们一改再改。不知道是谁的编解码出了问题,传递出的信息和实际差异这么大。还有一次是手工测试人员的测试步骤和发送数据里的内容有不一致,我跟对方确认,没有得到解释还被骂问的问题太低级……我太难了!
  • 陈斯佳
    2019-08-07
    正在学习吴军老师在得到上的《信息论40讲》,到时候听完再来回顾一下这一章知识

    作者回复: 常回来看看

  • 陈斯佳
    2019-05-24
    沟通反馈
  • 小辉辉
    2019-05-18
    通过沟通,能更好的站在别人的角度想问题,造成的误解就会少很多
  • CalanceHao
    2019-04-26
    🤭中枪中成了刺猬……

    作者回复: 然后,就变身了!

  • jacky
    2019-02-20
    编解码模型很像三次握手,精辟,受教