认知维度

探寻专家行为的依据

一家大公司曾请我的团队使用我们一直在开发的“影子对手训练”法开展为期一年的认知技能训练演示项目。而我们该为这个演示项目设计哪些内容呢？这家公司的业务涉及各类军事活动。然而，该公司不想对此项目保密，这排除了我们的首选方案。

该公司认为，我们应当把培训的重点放在系统集成工程专业上。这建议的确有道理，只是我对系统集成一无所知，我团队的成员对这个领域也不了解。多年来，我和我的团队已经习惯于踏入一个个全新的专业领域。可是，我们还是觉得系统集成有些棘手，因为这一领域看起来技术化程度很高，了解它需要相当的工程学方面的经验，它涉及的操作复杂程度远远超过我们之前做过的任何项目。我们尽管有些拿不准，但还是决定试一试。

我们进行了为期一周的深度认知访谈，发现这家公司已有一套专业的系统集成培训方案，且此方案还附有一本厚厚的手册，详细说明了系统集成培训的阶段和步骤。我们翻了翻手册，内容很全面，涵盖了系统集成培训过程的每个部分。我们如果在开始这个项目前就觉得没有把握的话，此时就更没信心了。

面对如此详尽的培训方案，我们还能补充些什么呢？

接下来，我们一遍遍地翻看手册，终于发现手册中缺的是什么：

哪些决定是难以做出的？

是什么让局面变得复杂？

会出现哪些问题？

系统工程师会在哪些方面感到困惑？

刚入职的系统工程师会犯哪类错？

如何从错误中恢复？

刚入职的系统工程师的思维模式如何随着经验的积累而改变？

系统工程项目中做哪些取舍最为艰难？

有经验的工程师在管理风险方面学到了什么策略？

经验丰富的系统工程师发现和理解的哪些东西是他们经验不足的同事所忽略的？

前述问题手册中均未涉及。这些问题正是非常重要的认知挑战的例子，却往往为常人所忽略。

在进行了八次深入的认知访谈后，我们于周末确定了一组包括十五项认知训练要求的方案，包括一些关键思维模式的转变。这十五项认知训练要求包括对难以避免的问题的判断、在目标之间做出权衡、管理风险，以及采纳其他团队成员的意见。在接受认知训练后，系统工程师的思维模式转变的表现之一是，随着项目的推进，他们可以对最初的目标进行调整。太多的工程师认为他们必须锁定最初的目标，即使这些目标变得不切实际，即使令人激动的机会已然出现。此外，我们还大致描绘了几个认知训练的场景。

在我们开始访谈前，该公司负责人，即我们的赞助商已明确表示，他希望在项目结束时对我们的培训计划进行严格评估。周五下午，在为期一周的访谈结束之际，我们向他和他的团队展示了我们已经确定的几项认知培训任务，并询问他选择哪一项进行培训和评估。我们解释说，我们需要针对其中一两项任务进行培训，以便得到合理的评估结果。这位赞助商打断了我们，说道：“我希望培训方案能涵盖所有的任务。你们单子上列的，我们都要。”我们对此表示拒绝，因为这种不系统的方法只能使我们无法完成他想要的细致的评估。赞助商便说让我们将评估放在一边，尽可能地设计出最全面的培训方案。

我们最终与该公司合作，共同制订了六套培训方案，并对其中的三套进行了测试。结果表明，我们设计的认知培训方案有可能取代他们目前使用的一些由培训师指导的昂贵的培训项目。

此后，关于我们团队在这个项目上的完成度，我既惊讶于我自己的态度变化，也对赞助商的态度变化感到震惊。赞助商有理由为关于如何进行系统集成操作的手册感到自豪，因为它涵盖了所有的流程及步骤。可每个人都清楚手册中缺的是什么——认知维度。前文所列的问题说明了手册在认知层面的不足，但你不要以为只列出这些问题就够了。

深入了解认知维度需要经验的积累和思维模式的转变，从相信复杂任务可以按步骤完成，转变为可洞察细微之处，即你能够洞察到环境影响你执行步骤的方式、你如何执行这些步骤，以及如何在必要时调整这些步骤产生的影响。认知维度是一种以好奇心为中心的思维模式，它会产生一个接一个的问题，渴望获取更多支撑专业知识的隐性知识。

认知维度使人类得以用不同于机器的方式进行思考。有时我们比不过机器，有时我们又比机器强，但无论是为了设计出更好的机器还是支持系统，或者是制定培训项目，认知维度都有助于我们了解人类究竟是如何思考的。

——2019年4月6日