多任务让你走得更慢(很好，转自infoq）

关注

转载最新推荐文章于 2026-11-10 19:24:58 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

Ubuntu零基础入门到精通【4.7讲】：常用快捷键与效率操作！ 🏆 本文收录于《滚雪球学 Ubuntu》专栏。本专栏面向有一定计算机基础，但尚未系统学习 Linux / Ubuntu 的读者，采用“滚雪球式学习法”：先装好、再会用、再理解、再优化、再实战，带你从第一次进入 Ubuntu 桌面 / 终端开始，逐步掌握 Ubuntu 的日常使用、命令操作、软件安装、系统配置、开发环境搭建与服务器部署能力。阅读详情

http://www.infoq.com/cn/articles/multitasking-problems

现代商务依靠多任务来完成工作。评价员工也基于的他们多任务能力。IT业人员会被例行指派到多个项目中去。我们是经常在这样做吗？多任务起作用吗？多任务的真正影响是什么？有别的选择吗？

这里老词重提一下“单任务”，它代表了我们在多任务之前所习惯的软件工作方式。在这里的“多任务”，指的是“工作在很多项目上”。现代商务把它称作“多任务”，认为它是一种更有效提高工作输出的策略。其实，不止工作，我们在日常生活中也会小规模地多任务。这两者在做法和后果上都有相似性。

一个不同的角度

当我们向新人介绍敏捷（或Scrum）时，最大的绊脚石是让他们理解团队成员在全职专注于团队工作时，工作效率要高得多得多。这并不是新闻。多年来，我们通常召集“飞虎队”和“特警队”，在危机的时候解决特殊问题。然而，我们的组织更喜欢把“技能筒仓”中的人同时指派到多个项目中去。现在，这是同时处理大量事情的真实解决方法。人们认为这是最有效的“稀缺资源”使用方式。也就是人数不够，但都有专长。

敏捷模式与之完全不同。我们组建团队，在同一时间专注在一小组事情上。我们并不是先创建工作然后转移人手到不同的工作中，而是先创建团队然后转移工作到不同的团队中。我们是拉动而不是推动。

改变是困难的。用另一种不同的方式做事需要一个清晰的目的、对获益的远见以及勇气。所以抵抗是自然的，人们在周围事物开始改变时感到不安全。如果我们可以转换到精益思想，就可以借用“尊重他人”和“持续改善系统”来定义目的，期待收益，并走出改进的第一步。很多人听说过“精益”，也想过如何改进我们正在做的事情。其实，精益也告诉我们，如果停止做一些低价值的事情，可以消除更多浪费。

多任务的成本

工作在多个项目的人，在每次切换任务时都需要额外成本。主要的成本是切换上下文所需要的时间。我们知道像接电话这样的小中断也需要15分钟的时间来恢复。任务越复杂，切换所需要的时间越多。

如果你工作在超过两个项目上时，成本会更高。可能你上次工作在某个项目已经是很久以前的事了，那就需要费更大的劲来回忆起离开的那一点。而如果你频繁切换，那转换环境的时间就会占掉你大部分的工作时间。

有研究显示人们对切换小任务很在行。在短时间范围内的切换，似乎和我们的两个大脑半球有关。在一定程度上，我们可以并行处理两个独立任务。对大的切换，我们应该考虑切换成本。Jerry Weinberg展示了逐步上升的上下文切换成本。这个模型假设每次切换会有10%的损失，事实上成本常常比这个更高。

图 1

当一个人属于一个团队时，无论是松散连接的传统项目团队，或者是有重点的敏捷团队，都会有复杂的切换成本。当一个团队成员离开去做和团队工作无关的工作时，团队都会遭受那名成员缺席的困扰。当那名成员回归时，团队需要花时间来帮助他赶上他缺席时的开发任务。

敏捷也多任务？

你可能会说：“但是……等一等……”敏捷团队是跨职能的，团队成员每天都忙于各种活动中。这包括详细描述需求、分析、设计、测试、编码。那不是多任务吗？要回答这个问题，必须考虑上下文的范围。在问题和技术间的大范围跳跃需要更多的切换时间。大脑在一点一点切换活动时不会有问题。作为一个有聚焦重点的团队，所有的每日活动都以一小部分功能和技术为目标，在一个时间只工作在少数的故事上。即使活动的范围多样，上下文的变化也是有限的。另外，敏捷有一些实践来保持聚焦：协作、任务板、自动化测试、回顾。上下文的大跳步才会产生问题：比如转至其他项目、其他合作人、其他干系人。

多任务神经学

人类大脑对内部多任务很在行。其实它每天都在这样做。甚至晚上也一样。很多大脑部件一直在交互或单独工作。不然，我们就不能应对复杂的环境。大部分多任务是下意识的：过滤掉感觉输入、综合相关信息、把短期数据转化为长期记忆、保持心肺运转等等。

而且我们也在对外多任务：开车时听着交通报告想着行车路线，做晚饭时讲电话，为花园除草时计划假期。一些类似叠衣服、走路等任务是机械性的，不需要切换成本。其他任务像敲击键盘浏览文档、重命名一个方法，经过一段时间也会变成机械性的。但是软件开发工作不是那么简单的。虽然很多自动性多任务运作良好，它也会有限制。[5]

现代的多项目任务分配造成的上下文切换，产生了潜在的重复精神劳动。人脑有两种记忆：短期（工作记忆）和长期。虽然，有机制使信息在两者之中转换，但是不能保证所有东西都被转移了，也不能保证进去的信息和以后出来的信息是一样的。我们每次重播记忆的时候，都在不断编辑它们。而新信息必须在短期记忆中存储一段时间才能被转移到长期记忆。比如说，考试前的填鸭式复习可能会给你更好的成绩，但是两周以后你几乎不会记得那些材料。于此相似，你可能不会记得上下文切换前你做的最后一件事情。而这应该会是你回到项目后最想要知道的。

研究显示很多多任务的方式是低效的，甚至有害的。考虑以下信息：

有证据显示多任务事实上会使短期记忆退化。这不只是因为多任务的主题，而可能是大脑区域受到影响。多任务会造成压力，压力会调用大脑中关于个人安全的原始区域，进而从高级思维区域中获取能量[6]。压力也会损坏新记忆所需要的细胞[7]。
我们多任务的时候更倾向于犯错，所以我们的工作质量会下降[8]。这当然会增加项目的成本，因为这些错误需要被纠正。
大脑的一些部件是顺序处理器，每次只能接受一个输入[9]。
前额叶皮层是大脑进行复杂认知和做决定时使用最频繁的部分，也是大脑中最消耗能量的部分[10]。多任务产生的附加压力会导致认知能力的快速损耗和更频繁的修复需求。

敏捷团队的单任务

在敏捷环境下，如何减少个人的多任务量呢？我们之前提到了一些方法。更多肢体运动的环境可以使大脑中更多的部分参与其中，致使更快速更完整的信息综合。更专注的工作使上下文范围狭窄。人际交互，以及ScrumMaster推动的一些交互可以帮助保持这种专注。

一些现代的技术实践能帮助增强专注力：

测试驱动开发帮助短时内专注在小范围的技术工作中
持续集成在构建和测试失败后立即给予关注，以此来增加专注力
结对编程帮助两个人专注在一小部分的代码上

组织中的单任务

反对多任务的意见已经存在很久了，然而现代企业文化已经习惯于这种形式的“负载平衡”，以获得对人力“资源”的最有效使用。我们从一些松散的技能团体中召集一个团队，每个人在一个时间在几件事情上兼职。你能构建一个高效的兼职人员团队吗？或者，是不是我们已经认为让每个人都很忙才是更重要的？

学习中最难的部分之一是忘却当前的行为。这一点对组织和个人都成立。跳出我们现在所做的行为，思考哪些行为可以让我们工作得更好，这一步精神飞跃，是很难做出的。这里有一个简单的论点也许可以帮助引导改变，不止使人的改变更容易，而且也有重要的经济意义。

图2中显示了4个人工作在3个短期项目中的简单场景。更多的人或者更大的项目，也是同样的动态。在第一个场景中，人们在4个项目上多任务。

图 2: 多任务的个人

图3中显示了第二个场景，一个团队中同样的人顺序完成所有的项目。这个场景保守地假设了成立团队没有生产率的提高，减少上下文切换的数量也没有生产率的提高。注意到所有3个项目都在同一时间完成，但是这个场景中2个项目更早地完成。想象一下由此产生的经济利益。

图 3: 成立一个团队顺序做项目

考虑上下文切换的减少，以及由于团队协作而获得10%的生产率提高，我们可以期待所有3个项目都能提前完成，如图4所示。

图 4: 由于单任务和团队协作而缩短的时间表

Johanna Rothman在“管理你的项目组成”中具体介绍了这个话题。

多样性是生活的调味品

所以，很清楚，多任务是有害的，我们永远不应该这样做，是吗？那我们如何调和“多样性是生活的调味品”这一思想？脑部研究显示，新奇性是有吸引力的。它会产生多巴胺，这是一种神经传递素，会使我们想要更多[11]。对此的解答与专注力和范围有关。如果上下文的切换很大，多任务会对个人和他们的合作者造成代价。如果切换比较小，可以顺应思路，那就会工作得比较好。在敏捷团队中，我们可以通过彼此学习来得到足够的新奇性，也会从完成项目和成功中得到其他好感觉的神经传递素。