最近，在和同事们讨论产品经理职责的时候，聊到了关于产品的定义，如果不能准确定义“产品”的时候，可以考虑其必要条件，即可没有用户的产品肯定是没有意义的。产品有了用户， 必然存在用户与产品的交互——UI。令我有些意外的是，得到的反馈是产品都要有web 页面。显然，这里存在着认知偏差。那么，软件开发中的认知偏差有哪些？又如何面对和解决呢？

认知偏差是影响产研人员的固有行为，可以会把软件产品的开发置于不正确的过程中，因此，有必要进行一些深入的学习和理解。认知偏差影响了产研团队的哪些行为呢？讨论和学习的前提仍然是概念澄清，需要从认知偏差的定义开始。

1. 什么是认知偏差？

以下是百度百科中给出的解释：

认知偏差是人们在知觉自身、他人或外部环境时，常因自身或情境的原因使得知觉结果出现失真的现象。
—— https://baike.baidu.com/item/%E8%AE%A4%E7%9F%A5%E5%81%8F%E5%B7%AE

认知偏差最早于1974年由研究人员 Tversky 和 Kahneman 提出，经过数十年的研究，在经济学，心理学，社会学和管理学研究中确定的认知偏差大概有200多种。经济学家认为，大脑通常采用简单程序应对复杂环境，因此出现偏差在所难免。而社会心理学家则认为，认知偏差跟自我中心的思维倾向有关，是为了维持积极的自我形象，保持自尊或者维持良好的自我感觉。不过，进化心理学家哈瑟尔顿（M. G. Haselton）和列托（D. Nettle）认为有的解释难以令人满意，给出的都是表面答案。他们提出了错误管理理论，认为通常的决策不是犯不犯错误的问题，而是犯哪种错误的问题。因此，如何解释认知偏差是一个非常棘手的难题。

三种常见的认知偏差是：

1、确认偏差：人只愿意看到自己想看到的 2、达克效应：水平低下的人认为自己是最好的。3、认知失调：人趋向于寻找、坚持支持自己合理化解释的认知。

就团队协作而言，认知偏差一般是指人们根据一定表现的现象而对他人作出判断，从而出现判断失误或判断本身与判断对象的真实情况不相符合。认知偏差可导致感知失真、判断不精准、解释不合逻辑、或各种统称「不理性」的结果。

2.软件开发中的认知偏差

软件开发中，认知偏差可能是对最佳推理的系统性偏差，它影响我们如何发现、评价和记忆信息。以下，为了简练，直接用“认知偏差”指代软件开发中的认知偏差。

软件开发的产研同学对这种行为无法免疫，并且可能由于多个原因而表现出为认知偏差。例如，易用默认的认知偏差可能促使产研人员根据自己容易记住的知识来选择解决方案，简单的说， 就是先干容易做的，作自己容易产出的交付，但是对业务的核心诉求可能帮助不大。另一些认知偏差可能来自过往的经验，例如，坚持个人解决问题的风格，缺少了包容以及解决方案的多样性。

并非所有的认知偏差都必然导致负面结果，有时候参与者采取的行动少于预期，也可以带来积极的影响，例如，所谓的“傻人有傻福”。然而，在一个不受控制的环境中，认知偏差也可能造成重大的负面后果。在软件开发中，一般可把反向的操作作为负面后果，具体发反向操作包括那些以后需要撤销、重做或丢弃的任务和流程。

尽管可以确定认知偏差对软件开发的一些方面存在有害的影响，例如bug密度、软件需求的说明、设计原创性、功能设计等，但是，仍然无法中知道这些认知偏差怎么样地影响了产研人员的行为和决策。或许，可以通过归纳认知偏差的种类，然后尝试如何减少这种非最优行为。

3. 认知偏差的分类

根据 Souti Chattopadhyay等人的研究，对其中的10类认知偏差进行梳理。

3.1 先入为主

先入为主的认知偏差表现为产研人员倾向于基于先入为主的手头任务来选择行动，会导致产研人员对采取行动所需的解决方案空间探索程度打折扣，造成完备性的缺失。

3.2一亩三分

这一认知偏差表现为产研同学过分重视他们自己创建或已经拥有的软件任务，从而降低了客观评估其他选项的可能性。对自己局部交付的偏好使产研人员无法完全探索解决方案的空间，同样是完备性的缺失，甚至无法完成产品的完整端到端体验。

3.3 固步自封

将解决问题的努力锚定在最初的假设上，而没有根据增加的信息或相互矛盾的证据对锚进行充分的修改，这会导致对任务场景的感知减少，对业务核心诉求的变化缺失了关注。

3.4 易用默认

当产研人员仅仅基于他们的默认状态选择容易获得的选项时，或者倾向于选择当前条件而不考虑扩展性或适应性的时候，就会出现这种认知偏差。这会导致整个任务的场景丢失，局部最优的和很可能不是全局最优的解。

3.5 盲目乐观

盲目乐观体现出一系列的认知偏差，会导致错误的假设，以及所选解决方案的效率或者正确性。当人们过度相信自己的能力，或者高估了有利结果的可能性时，就会出现这种情况。

3.6 过度简化

这一认知偏差体现为认为每个问题都存在一个的简单原因的，以及采取看似更快或更简单的解决途径。这减少了产研人员在推理思考和理解信息方面的投入。

3.7 潜意识行为

它表现为将评价和感知转移给外部资源(如 IDE 或在线资源) ，而不考虑这些信息的实际价值。

3.8 无知无畏

无知无畏指的是假设一切都是正常的、有效的、合理的，即便是在面对矛盾证据的时候。正因如此，产研人员可能会不注意周围环境，乃至潜在的团队合作可能性。

3.9 表面选择

这体现为一系列基于表面标准的行为和信息被过度地重视。因此，产研人员没有经过充分推理和思考就决定了一个解决方案。

3.10 记忆偏差

记忆偏差可能是各领域都存在的一种认知偏差，体现为研发人员更喜欢使用所遇到的主要信息或最近的信息，或对记忆中最容易获得的信息结果作出反应。

总的来说， 这10种认知偏差主要导致了四种后果：探索不足，减少感知，语境缺失以及错误的关注。减少探索往往导致参与者创造次优解决方案。感知的减少会使人们下意识地按照默认的理解行事，会导致错误的推理。语境缺失，会造成人们试图解决一个问题并偏离核心诉求，一叶障目，不见泰山。错误的关注会影响到产研人员认为相关的信息，从而在解读上发生偏差，甚至使他们花时间处理与核心诉求无关的问题。例如，当强调产品经理职责范围的时候，核心的诉求是如何提高产品经理的能力和胜任力，但可能会被解读成组织机构的调整。

4. 如何面对认知偏差

认知偏差在软件开发中经常出现，例如，以技术债务来换取中短期交付的成果，三个月后，发现项目失败了！回顾过去的时候，发现有人改写了一些东西，因为那样做更容易，结果把一切都搞砸了。

记忆偏差、过度简化和先入为主可能是在人们经常感受到的认知偏差，而感受不深的认知偏差发生的频率也并不很低。尽管目前的软件开发流程和工具并不是为了避免认知偏差而设计的，但开发人员可能仍在使用它们来避免认知偏差。消除认知偏差可能是不现实的，但还是有一些方法可以减少认知偏差，或者减少认知偏差造成的负面后果。

4.1 系统方法

为避免成为认知偏差或其他错误的受害者，产研人员应该系统地探讨问题空间，并探索可用的解决办法和工具。这种不同任务参数的系统综述有助于避免偏见，例如先入为主、记忆偏差和固步自封 ，因为开发人员会更好地意识到潜在的坑，也可以提前考虑替代解决方案。

除了可供选择的解决方案之外，系统探索还可以帮助人们牢记“大局”，以大局为重。换句话说，它迫使产研人员更明确地欣赏和承认更大的目标，希望最大限度地减少他们在非核心诉求上分心的可能性。对开发人员而言，这可以通过促进使用现有的相关代码来防止所有权(CB2)等偏见，这有助于保持较大的代码库向后兼容。

4.2 文档阅读

在开始一项任务之前查阅文档也可以避免某些认知偏差，比如先入为主、记忆偏差和一亩三分 ，因为开发人员可以意识到解决问题的多种方法以及每个解决方案的缺陷。例如，开发团队的文档空间是记录库和包使用的指导方针，这些文件一般会指出如何使用某些代码以及避免陷阱。

关于如何处理错误及其严重程度的标准化描述文档也可以帮助开发人员更快地找到错误，从而克服诸如无知无畏和盲目乐观等认知偏差。

4.3 多维的视角

欣赏不同的视角，加上相关的反馈，可以帮助避免某些认知偏差，如先入为主 ，固步自封 和表面选择。接触不同的方法可以帮助产研人员打破认知“引导循环”，迫使他们重新考虑、评估并证明任何后续行动的合理性。例如，结对编程可能帮助避免表面选择的认知偏差。

4.4 流程优化

良好的软件工程方法，如频繁迭代和测试，敏捷软件开发等，可以在一定程度上帮助避免很多类别的偏见。对于开发人员而言，可以通过编码标准和使用标准库来避免一亩三分和易用默认等认知偏差。这也有助于开发人员找到合适的代码来实现重用。

4.5 有意义的回顾与分享

从现有的开发模式中抽出时间进行回顾与分享，可以帮助产研人员意识到有益的实践方法(比如清晰的代码) ，这可以避免一些认知偏差，比如先入为主和记忆偏差。

最后，有效的问题解决策略也可以帮助减少一些诸如固步自封 ，过度简化和潜意识行为等认知偏差。例如，收敛性思维可以确定一个问题的具体解决方案，帮助产研人员迅速地找到特定的解决方案，而发散性思维则探索问题的多种解决方案，帮助产研人员从一组备选方案中确定最佳解决方案。这样可以防止产研人员将注意力集中在单一解决方案上，从而减少了固步自封的认知偏差。

5 小结

认知偏差经常干扰软件的开发，损害产研人员在任务执行和投入时间方面的问题解决能力。应该让产研人员意识到，认知偏差对软件开发构成了重大威胁，而且可能比他们意识到的更加普遍，但有缺乏防止或帮助产研人员减少认知偏差的工具。本文整理出10种在软件开发中出现过的认知偏差，指出了每种认知偏差的可能表现形式和负面后果，并提出了5种方法来减少甚至避免这些认知偏差，希望对大家有所帮助。

【关联阅读】

• AI系统中的偏差与偏见

• 老曹眼中的敏捷开发

• 产品的指标初探

• “低代码”十问

• 老码农看到的技术债务

• 复杂性，科学，方法论？

• 计算机体系结构的一知半解

• 导致系统性能失败的10个原因

• API设计中性能提升的10个建议

• 远程软件工程师的10个最佳实践

• 看一点逻辑学，试图理解一点真相

• 关于软件开发，都应该知道的10个常识

• 纸上得来终觉浅——成长的10条...

• 阅读札记——创新与思维范式

• 嵌入式开源软件的10大弊端

• 软件架构的10个常见模式

• 性能，10点系统性思考

• IoT产品10个最佳实践