本文发表于《大众科学》的前博客网络，仅反映作者的观点，不一定反映《大众科学》的观点
关于支持科学新闻业
如果您喜欢这篇文章，请考虑通过以下方式支持我们屡获殊荣的新闻业 订阅。通过购买订阅，您将帮助确保有关塑造我们当今世界的发现和想法的具有影响力的故事的未来。
沟通很少是直截了当的。它可以像童年时的电话游戏一样，最初的信息在每次新的讲述中都会被扭曲和篡改。选择论点可能像剪断电线解除炸弹一样令人担忧。或者，它可以像完美的湖面上风和帆的结合一样轻松自如。当然，沟通也可能是自私的，就像一系列嵌套的类比都塞进开篇段落以阐明一个观点一样。
无论您喜欢哪种类比（或隐喻），很明显，有效的沟通往往感觉比它需要的更难。毕竟，人们一直在交谈！他们阅读、写作和倾听！但不知何故，我们最善意的消息仍然最终被错过或误解。在将技术和非技术群体聚集在一起解决共同问题的环境中，这种情况尤其真实。有时，我们尝试用来克服这种混乱的工具最终会产生意想不到的后果。在这里，我们通过三个轶事来探讨这种局面：做得过好的类比，做得不够好的简化，以及我们希望恰到好处的延伸隐喻。很久以前……
做得过好的类比： 在一次原本平淡无奇的会议中，一群同事花时间庆祝一项期待已久的幕后功能的推出。会议室里甚至响起了一阵欢呼声和零星的掌声。我们来自营销部门的同事——通常在议程的开发更新部分感到乏味——振作起来。她问这是否是我们可以利用的东西。宣布？搞点宣传？她得到的只是沉默和一些惊恐的目光。桌子旁的人试图解释说，这项改变没什么值得炫耀的。她要么不相信，要么非常渴望从我们这个通常不引人注目的部门推广一些东西，以至于她起身把首席执行官请了进来。“不，”我脱口而出。“这就像在说，‘你最喜欢的麦片——现在不含梅毒了！’我们不想引起人们的注意，即这个新流程现在才开始实施。” 轮到我迎接沉默的恐惧了。然而，重点已经说明了。她说：“我明白了，”然后坐了回去。我是否表达了我的观点？是的。我是否也成为了“那个说了关于梅毒的事情的女人”？也是，是的。这不是最好的。做得不够好的简化： 另一个部门间的僵局围绕着“复杂”这个词形成。用户要求将一种新型数据集成到现有模型中。技术团队不想深入了解代码基础设施的细节——这种添加将如何触及许多地方，被分解成许多部分，并在整个模型中单独维护。他们也不愿意直接说出模型的设计——用户要求的——正是阻止包含那些用户现在要求的数据类型的原因。建模团队认为，这次对话会让人不舒服，而且可能超出用户的理解范围。最好是简化。因此，他们说添加该功能会“太复杂”。这并没有解决问题。用户带着他们认为的澄清回来了。不，不，他们解释说，我们不需要以复杂的方式包含它。我们只需要对任何潜在影响有一个基本的了解。所以，只需添加一个“简单版本”，好吗？无需采用高层次的复杂方法。这种情况持续了数周。最终，建模团队不得不向用户解释，包含任何该类型的数据——即使是简单到毫无意义的版本——也将是计算量如此之大，以至于会使操作陷入停顿。他们没有被要求以这种方式构建系统，因此它也没有以这种方式构建。句号。时间过去了，话也说过了，但也不是最好的。我们希望恰到好处的延伸隐喻： 最后一组也遭受了基于词汇的崩溃，词语的选择从分歧演变成相互精神操控的工具。在这种情况下，这个词是“系统”。所讨论的系统旨在监控审查过程期间的材料和沟通。虽然大部分是自动化的，但系统的某些部分需要手动输入——而这些点的错误正在拖累系统的其余部分。用户大喊系统坏了。技术团队说系统完全按照设计运行，数据输入错误是罪魁祸首。对于用户来说，“系统”指的是从上到下的一切，包括所有人类和非人类组件。开发人员坚持认为，系统只包括自动化组件，人为错误不是他们要预防或解决的。理性的对话变得不可能。一方使用越来越侮辱性的语言来描述系统设计得多么糟糕，以至于允许出现如此严重的错误，而另一方则站在“代码完全按预期工作”的隐喻盾牌后面。干预和隐喻最终不得不来自更高层。与管理层的会议没有讨论系统本身，而是讨论了一辆汽车。他们想象一辆设计用来将人们从 A 点运送到 B 点的汽车，但在途中不断抛锚。机械师发现问题是有人在汽油发动机中加入了柴油。在流氓柴油让他们在高速公路上抛锚数十次之后，用户对再次踏入汽车产生了严重的焦虑。随着指责变成了隐喻的概念，取得了一些进展。机械师坚持认为汽车工作正常是对的。但乘客坚持认为期望他们继续使用这辆汽车，而且还存在不明原因的柴油引起的故障，也是疯狂的，乘客也是对的。问题不是责怪任何人，而是我们可以做些什么来创建一个隐喻的喷嘴，防止柴油再次被加入发动机中。谁可以构建和监管这样的东西，打个比方？气氛仍然紧张，但至少指责的声音不再那么强烈。虽然每个人都同意解决方案应该是什么样子，但只有时间才能证明结果如何。我们希望一切顺利。