0%

好书推荐 ——《噪声:人类判断的缺陷》

引言

最近看了心理学家丹尼尔·卡尼曼的新作《噪声:人类判断的缺陷》,收获不少,结合自己的工作实践,分享一下体会。卡尼曼的成名作是《思考,快与慢》[1],我相信很多人都看过。那本著作的着眼点在于人们认知的偏差,而本书则另辟蹊径,关注人类判断中的噪声。书中有丰富的案例来解释噪声的危害,以及消除噪声的方法,不过都是来自离我们较远的行业,没有深刻体会。在本文中,我会抛开法官断案、保险精算以及医疗诊断,主要关心发生在我们日常工作中的噪声。

noise-book

噪声:人类判断的缺陷

偏差与噪声

我们可以这样简单理解偏差和噪声的区别。偏差描述的是多个判断偏离目标的程度,可以理解为一种准确性;而噪声描述的是多个判断相互接近的程度,可以理解为一种稳定性。举个书中的例子,偏差大噪声小,好比你打了10枪,都是3,4环的样子;而偏差小噪声大,则是你的10枪都在5环以上,但5到10每个环数都有。

本书作者认为,

误差 = 偏差 + 噪声
系统噪声 = 水平噪声 + 模式噪声 + 情境噪声[2]

在一个系统中,我们很容就观察到偏差的部分。当团队作出了错误的决策,后果可能很快就会展现;某个专家对未来作出了的预测,也会很快得到验证。但是噪声容易被我们忽视,却常常存在于各类系统中。下面我们逐个来看在日常工作中有哪些噪声。

水平噪声

水平噪声通常是针对系统的,而非个体,你可以理解为系统中不同个体对同一任务的不同判断

我们公司最近在做全球员工调查问卷(GES),需要每个员工都对一套问题回答5个级别的答案(如“非常同意”、“不同意”等)。可想而知,这类调查的水平噪声会很大,因为每名员工对问题的理解多少存在差异。况且,问题的设定也不一定能够让员工透彻理解。

这其实非常考验问题的设计。公司在收集问卷答案时的预设是:员工对问题的理解达成共识,并真诚作答,这显然不太现实。另外这些差异也不能视为偏差,因为调查没有对错可言。

还有一个例子是面试。尽管我们有每个职位的描述,也有考核的标准,但面试官在实际面试时通常各有各的一套标准,那么对候选人的评估也就存在水平噪声。从后面的讨论即将看到,面试中还有其他噪声。

模式噪声

模式噪声将目标放到个体上,可以理解为一个人面对一类问题的多次判断,产生有倾向性的结果,即形成模式

我们经常会做代码审查(Code Review),每个审查者倾向于提出不同建议:有的人在意代码风格,有的人在乎单元测试,还有的人经常要求重构,以满足某些非功能属性(扩展、重用等)。当然,这些方面的问题都很重要,但是审查者往往会关心特定的部分,加上以此Pull Request的审查者数量可能不够多,我们的合入的代码就有潜在的问题。这就是代码中的噪声

每年的升职加薪都是我们翘首以盼的😝,但是决定权通常掌握在自己的直属领导手里。虽然升职加薪也有相对明确的标准,但每个领导对自己手下员工的评估也会有差异,这与领导自身的风格、性格相关,那么领导在确定升职加薪人选,也会形成某种难以捉摸的模式,不知道你能不能领悟到^_^。

客观来讲,这并不利于公司的整体利益,但是还有一个因素在某种程度上磨平这种噪声,那就是资历。在很多组织中,资历可以让升职加薪的机会平均化。

情境噪声

情境噪声是一种特殊的模式噪声,它体现了人们在做判断时的偶然因素。对于同一个任务,一个人多次的判断结果也会有差异。

有的企业里面会有专利申请和评审,开发者可以提出专利方案,经过专家委员会审核通过后,可以向专利局申请,并能得到相应报酬。这个专家评审的过程就既有模式噪声,又可能有情境噪声

每个专家的技术背景不同,所能看到的方案背后的价值就有倾向性。而每次评审时,又可能受其他因素影响,如公司的战略布局、专利方面的成本预算和评审的工作量和截止日期等,甚至是专家当时的心情都可能主导结果。这都是情境噪声的来源。

另一个例子是技术分享或演讲。不知道你有没有过这样的经历,在演讲前把讲稿认真准备了多遍,而在实际演讲的过程中依然可能自由发挥,脱离原来的脚本和思路。这其实就是你在讲的过程中有偶然的噪声源,听众的反应、头脑闪现的想法、遇到的突发状况等,都可能左右你的演讲。

再回到之前面试的例子。尽管招聘的目的很明确,面试的经过仍然可以被很多因素左右,从而没有达到最初选人的目的。面试官擅长的领域、应聘者带来的第一印象,甚至面试官当日的心情,都可能影响结果。试想面试者擅长的领域正好与你的长处契合,那你可能忍不住多问几句,从而偏离整体面试目标。

其他噪声陷阱

在日常工作中,还有更多存在噪声的场景。比如在会议上讨论产品的技术方案,本来大家应该各抒己见,集思广益,但是先发言的人的观点和立场,很可能对后续发言者的思路造成影响。如果这个先发言者是比较资深的工程师或者是领导,那么这种效应会更明显。本来他谦虚地想抛砖引玉,可是砖抛出去了,引来的未必是玉,可能是各种像砖的石头。

如果让每个员工独立地作出方案并拿出来比较,效果会更好,因为这样少了先发言者这个情境噪声源。群体的噪声值得警惕,虽然群体的目标经常是达成一致,但一致不等于牺牲个体观点的多样性。

如何减少噪声

说了这么多你一定很好奇,到底应该如何减少噪声呢?我们来看书中提到的几个方法。

方法一:利用规则和流程

既然人为的判断同时可能出现偏差和噪声,那么我们可以利用合理的规则和流程,将判断的过程客观化,摆脱人的影响。有时即便很简单的规则,从平均来看,也比依赖几个人作出的判断要好。

虽然说“规则是死的,人是活的”,但是活的东西有时候却并不可靠。我们常常会对死板的流程嗤之以鼻,但流程之所以存在,不是为了应对常态的,而是为了在各种各样的意外中保持整体的稳定

规则有时表现为算法。算法除了表现稳定外,还能帮助我们发现难以识别的模式。比如很多公司都有产品数据分析的部门,通过产品中植入的数据点,收集来自客户的产品使用信息,从而指导商业决策。

方法二:平均独立判断

这个方法有两个要点,一是独立,二是平均。独立可以排除前面提到的群体决策时的干扰(情境噪声),而对多次独立判断取均值可以排除来自个体的噪声。

这里介绍一个德尔菲法[3]。它是在1946年由美国兰德公司创始实行,其本质上是一种反馈匿名函询法,其大致流程是在对所要预测的问题征得专家的意见之后,进行整理、归纳、统计,再匿名反馈给各专家,再次征求意见,再集中,再反馈,直至得到一致的意见。

德尔菲法的关键就是匿名多次反馈,它集合了独立和平均的优势,让群体的决策更接近目标。

delphi

德尔菲法

方法三:避免情绪化

情绪的影响不必多说。重要的不是尽量控制情绪,而是在有了情绪的时候要有觉知,且在这个时候不去做决策和判断。我个人认为情绪是情境噪声的最大来源,很多外在的影响都会落实到内部的情绪,然而当局者迷,可能还不自知。

方法四:采用精确量表

前面的问卷调查的例子说明,问题的设计要有明确的、量化的标准,并形成表格清单,供答题者遵循。比如这样一个问题:你会将自己的公司推荐给朋友和其他业内人士。

答案不能只是“非常同意”、“一般”、“不同意”之类,而是要写明在什么样的情况下(公司能提供什么、将会发生什么),我会选择同意,而什么情况不同意。这样的设置虽然能减少噪声,但会增加判断的成本,答题者要思虑的更多,而出题者则要更周全的考虑。

在敏捷开发模型中,我们需要对每个计划开发的feature作工作量估算,并设置一个story point。这个估算通常会比较盲目,如果你问每个开发者,他是按照什么标准来估算的,估计他也说不清楚。这也可以用精确量表的方式解决,不过这个量表的制作还是需要更多讨论,并考虑团队实际情况的。

方法五:承认无知

这是我自己总结的方法。承认个体和团队的无知并不容易。有些无知是客观的,各种意外情况、用户的边缘case就是无法预料和穷尽,那么在这些方面就不能较劲。而有些无知是主观的,即我们并没有意识到或者不想承认自己在某一方面的无知。

无知

承认无知

试想如果每个人都全知全能,也就不会有偏差和分歧了,因此无知必然是噪声的一大来源。信息、流程、技术栈、业界趋势、企业文化等各类因素,都能成为个体和团队的短板,并且短板和长处总是动态变化的,那么认知水平也不会一成不变。时刻保持警惕,识别优势,承认无知,不断复盘,才能保持新鲜,保持专注,不离初心

总结

总的来说,这本书带来的启发还是很多的,本文只涉及了部分精华内容,全书值得一读。我的阅读体验是,有些内容会稍显晦涩,我觉得把握精神是关键,梳理段落和章节之间的重点和逻辑,也就不那么难读了。

参考资料

[1] 《思考,快与慢》
[2] 这是简化的版本,便于理解,原公式详见《噪声》第四章
[3] 德尔菲法