理性和感性 - 如何对待错误

上次的博客，我写了一些关于软件开发中的理性和感性决定的故事。不论是感性还是理性，我们的目的就是要把软件交给用户去用，在软件行业中有这样一句俗话：

当你把产品交给用户的时候，你的学习才刚刚开始。

当然每个团队成员都希望用户非常喜欢这个产品，我们能从胜利走向胜利。但事实上，人会犯错误，大家会想自己上学学习的过程，就是不断被发现错误，然后你承认错误，分析错误，再去改进的过程。这个过程中，有什么理性和感性的因素呢？有很多。这个博客就主要分析，当我们的项目碰到挑战/困难/失败时，我们展现出来的感性和理性决策过程，以及它们背后的各种因素。

在软件开发中，我们会碰到下面的这些挑战和困难：

功能不能及时上线
程序崩溃
上线的新功能影响了老功能
上线的新功能并没能达到预期目标（满意度，用户量，收入等）
整个产品总的表现离预期越来越远
等等

我们分几种情况来看感性和理性：

出于直觉，感性的反应

首先，是一个感性的问题：如果我们的软件出现了上述的问题，当事人的第一感是什么？
绝大部分人当然是情绪上的沮丧，这些当事人的主管第一感如何呢？我在一些地方看到，有些主管也非常情绪化。这也是正常的，因为我们为产品投入了很多情感，希望能尽快看到收获。很多人心里有一个线性的模式：

1）对用户需求进行了研究 --> 2）找到技术实现 --> 3）实际发布 --> 4）用户满意 --> 5）用户经常来，用户付钱更多，大功告成。

其实，在上述的第一步中，我们认为我们了解了用户的需求，但是现实未必是这样，只有在第 3 步之后，我们才能挣到一个学习的机会。如果不理解这个我们自己的局限，很多人就会垂头丧气，提早放弃 – 用户太蠢了，不会用我们的软件，或者，我们太蠢了，搞不定这么简单的事情。于是就扔下这个功能不管了，急忙去做另外的用户需求的假设，其实，另外的假设也许会重蹈覆辙。

我们给想学习的用户做了一个 立Flag 的功能：https://bbs.csdn.net/forums/edu?typeId=1621331
但是初始的效果并不理想，我们怎么办呢？就不做么？

我把这个情况叫做 只能支持一次发布的热情 ，如果第一次没有成果，这个方向就被过早地放弃。这是很可惜的。从深层的角度来说，人们太想用某种简单的理论来解释现实，从一种居高临下的角度来分析问题，觉得一出手就必然成功。这是一种叙述谬误（narrative fallacy），人脑的直觉思维非常想把现实世界中发生的事情马上赋予因果关系，一旦解释不了，人的情绪不能接受，就会转向别的事情，而不会安静下来深入分析：导致用户不满意的原因有很多，我们都理解了么？我的理解是，从心理学家卡尼曼的《思考快与慢》的体系来说，就是用系统一（直觉），和系统二思考的不同。

在这里插入图片描述
和上面的单线条 1） --> 5）的因果关系相比，这个 “鱼骨图” 更能让我们在分析问题的时候，冷静下来，收集各种因素，做详细的因果分析。

很多人会急忙修复问题的表象，而不是深入分析找到各种因素，他们会用一些暂时的借口：** 我会补上文档的，我们忙完这一阵子会深入分析的 ** 来搪塞，后来就不了了之了。

自尊

当我们在深入分析错误，列出各种主要和次要因素，并试图厘清他们关系是因果关系，相关关系，或者是没有关系的时候，很多人会口头同意这样做，但是，从情绪上，很多当事人会觉得没面子，伤自尊了。

为了维护自己的自尊，很多人不自觉地会陷入一个 ** 自欺 ** 的认知失调，他会让自己相信失败根本不存在，既然不存在失败，那么，我们就用不着回溯，分析，让我们直面尴尬的现实，免于痛苦地纠结于自己的每个决定，怀疑自己的每个判断，在夜里辗转反侧。这样心里就平安了许多。

但是，认知失调的问题在于：我们对错误的态度会削弱我们审视证据的能力。不管是大的决定还是小的判断都与认知失调有关。事实上，任何威胁到我们自尊的事情都可能引发认知失调。

心理学中提到，社会等级对于个体自信的压抑，导致一般人与权威人士对话的时候，会采取委婉的措辞，避免伤害权威人士的自尊。这在平时的交往中没有什么大的后果，但是在处理错误，潜在后果很严重的情况下，是很有危险的。几次飞机失事的案例分析说明，在飞机遇到紧急情况时，职位较低的副驾驶和工程师提出的警告和提醒口气非常委婉，没有引起机长的足够重视，最后机毁人亡。

既然威胁自尊这么可怕，那么，怎么避免呢？乔布斯的经验是：

与优秀自信的人合作，不用太在乎他们的自尊。
要用无可置疑的方式告诉他们，你的工作不合格。这很不容易，所以我总是采取最直截了当的方式。有些同事觉得这种方式很好，但有些人接受不了。
如果你给和我共事过的人做访谈，那些真正杰出的人，会觉得这个方法对他们有益，不过有些人很痛恨这种方法，有些人无法长时间忍受这样的工作。但没人否认，那是他们人生中最难忘、也最珍贵的经历。
（来源：乔布斯的采访。链接：https://www.sohu.com/a/238176357_778267）

IT 行业的绝大部分公司并没有苹果公司的那么多优秀自信的人才的时候，当然，有乔布斯脾气的领导倒是非常多，不少领导的脾气大大超过乔布斯。一般的公司怎么做呢？也有办法的：把工作中威胁自尊 的因素尽可能地去掉。

1）在团队合作模式中，去掉和解决问题无关的年龄/职位/专业等引起尊卑的问题
我们谈到了，软件开发团队模型，有的是 “产品经理主导型” - 产品经理是研发人员的主管，这就有尊卑，厉害关系了，下位的人，怎么有 100% 的自信去和上级自由讨论呢？所以，微软等公司采用的是“合作型” - 产品经理和研发人员，测试人员是平等的关系，没有领导关系。在处理难题的时候，平等的工作方式是很有帮助的。而且，因为是平等关系，这就倒逼产品经理在提出产品提案的时候，要有理有据，能说服自己的合作伙伴，而不是 “因为我是领导，我说一句话的需求，你们就得去办”。

2）一个事先讨论并同意的核对清单（ check-list）
在平等的情况下，资历较浅的成员在紧急状况发生时也更容易开口向上级进行提示，因为这是按照核对清单来做事，并没有 “我来指导你”， “我来挑战你” 的感性的言外之意。例如，根据我们清单，这个功能上线，必须要完成完成压力测试，并且让 UX 设计团队同意最终的用户体验设计。这不是有意为难领导，而是我们事先规定好的。

3）在收集数据的时候：让第三方来收集数据，很多公司有 BI 团队，这些团队可以从一个中立的角度来保证数据的准确性，数据定义和口径在各个业务之间的一致性。这个 BI 团队应该得到公司最高领导的支持，核心任务是收集全面准确的数据，而不是为了证明某个业务做的特别好。

当我们为一个项目绑上了自己自尊的时候，我们就会筑起自我防卫的高墙，开始粉饰自己的认知。很多情况下，问题不在于证据的说服力（理性），而在于承认错误要克服的心理障碍（感性）。人们认为，自己的形象，权威，事业是和这些 “对事实的归因” 紧密相连的，他们不愿意让自己的工作受到质疑。在不健康的团队文化和配置下，很多人会认为自己这么努力投入项目，没有功劳也有苦劳，一旦数据被大家分析，就会有 “老子辛辛苦苦打拼，居然有人来整我的黑材料” 这样的情绪化反应。这是团队领导要非常注意的。