英文原文：Multitasking Gets You There Later
作者：Roger Brown 译者：鲍央舟 发布于2010年8月31日
现代商务依靠多任务来完成工作。评价员工也基于的他们多任务能力。IT业人员会被例行指派到多个项目中去。我们是经常在这样做吗？多任务起作用吗？多任务的真正影响是什么？有别的选择吗？
这里老词重提一下“单任务”，它代表了我们在多任务之前所习惯的软件工作方式。在这里的“多任务”，指的是“工作在很多项目上”。现代商务把它称作“多任务”，认为它是一种更有效提高工作输出的策略。其实，不止工作，我们在日常生活中也会小规模地多任务。这两者在做法和后果上都有相似性。
一个不同的角度
当我们向新人介绍敏捷（或Scrum）时，最大的绊脚石是让他们理解团队成员在全职专注于团队工作时，工作效率要高得多得多。这并不是新闻。多年来，我们通常召集“飞虎队”和“特警队”，在危机的时候解决特殊问题。然而，我们的组织更喜欢把“技能筒仓”中的人同时指派到多个项目中去。现在，这是同时处理大量事情的真实解决方法。人们认为这是最有效的“稀缺资源”使用方式。也就是人数不够，但都有专长。
敏捷模式与之完全不同。我们组建团队，在同一时间专注在一小组事情上。我们并不是先创建工作然后转移人手到不同的工作中，而是先创建团队然后转移工作到不同的团队中。我们是拉动而不是推动。
改变是困难的。用另一种不同的方式做事需要一个清晰的目的、对获益的远见以及勇气。所以抵抗是自然的，人们在周围事物开始改变时感到不安全。如果我们可以转换到精益思想，就可以借用“尊重他人”和“持续改善系统”来定义目的，期待收益，并走出改进的第一步。很多人听说过“精益”，也想过如何改进我们正在做的事情。其实，精益也告诉我们，如果停止做一些低价值的事情，可以消除更多浪费。
多任务的成本
工作在多个项目的人，在每次切换任务时都需要额外成本。主要的成本是切换上下文所需要的时间。我们知道像接电话这样的小中断也需要15分钟的时间来恢复。任务越复杂，切换所需要的时间越多。
如果你工作在超过两个项目上时，成本会更高。可能你上次工作在某个项目已经是很久以前的事了，那就需要费更大的劲来回忆起离开的那一点。而如果你频繁切换，那转换环境的时间就会占掉你大部分的工作时间。
有研究显示人们对切换小任务很在行。在短时间范围内的切换，似乎和我们的两个大脑半球有关。在一定程度上，我们可以并行处理两个独立任务。对大的切换，我们应该考虑切换成本。Jerry Weinberg展示了逐步上升的上下文切换成本。这个模型假设每次切换会有10%的损失，事实上成本常常比这个更高。
图 1
当一个人属于一个团队时，无论是松散连接的传统项目团队，或者是有重点的敏捷团队，都会有复杂的切换成本。当一个团队成员离开去做和团队工作无关的工作时，团队都会遭受那名成员缺席的困扰。当那名成员回归时，团队需要花时间来帮助他赶上他缺席时的开发任务。
敏捷也多任务？
你可能会说：“但是……等一等……”敏捷团队是跨职能的，团队成员每天都忙于各种活动中。这包括详细描述需求、分析、设计、测试、编码。那不是多任务吗？要回答这个问题，必须考虑上下文的范围。在问题和技术间的大范围跳跃需要更多的切换时间。大脑在一点一点切换活动时不会有问题。作为一个有聚焦重点的团队，所有的每日活动都以一小部分功能和技术为目标，在一个时间只工作在少数的故事上。即使活动的范围多样，上下文的变化也是有限的。另外，敏捷有一些实践来保持聚焦：协作、任务板、自动化测试、回顾。上下文的大跳步才会产生问题：比如转至其他项目、其他合作人、其他干系人。
多任务神经学
人类大脑对内部多任务很在行。其实它每天都在这样做。甚至晚上也一样。很多大脑部件一直在交互或单独工作。不然，我们就不能应对复杂的环境。大部分多任务是下意识的：过滤掉感觉输入、综合相关信息、把短期数据转化为长期记忆、保持心肺运转等等。
而且我们也在对外多任务：开车时听着交通报告想着行车路线，做晚饭时讲电话，为花园除草时计划假期。 一些类似叠衣服、走路等任务是机械性的，不需要切换成本。其他任务像敲击键盘浏览文档、重命名一个方法，经过一段时间也会变成机械性的。但是软件开发工作不是那么简单的。虽然很多自动性多任务运作良好，它也会有限制。
现代的多项目任务分配造成的上下文切换，产生了潜在的重复精神劳动。人脑有两种记忆：短期（工作记忆）和长期。虽然，有机制使信息在两者之中转换，但是不能保证所有东西都被转移了，也不能保证进去的信息和以后出来的信息是一样的。我们每次重播记忆的时候，都在不断编辑它们。而新信息必须在短期记忆中存储一段时间才能被转移到长期记忆。比如说，考试前的填鸭式复习可能会给你更好的成绩，但是两周以后你几乎不会记得那些材料。与此相似，你可能不会记得上下文切换前你做的最后一件事情。而这应该会是你回到项目后最想要知道的。
研究显示很多多任务的方式是低效的，甚至有害的。考虑以下信息：
敏捷团队的单任务
在敏捷环境下，如何减少个人的多任务量呢？我们之前提到了一些方法。更多肢体运动的环境可以使大脑中更多的部分参与其中，致使更快速更完整的信息综合。更专注的工作使上下文范围狭窄。人际交互，以及ScrumMaster推动的一些交互可以帮助保持这种专注。
一些现代的技术实践能帮助增强专注力：
组织中的单任务
反对多任务的意见已经存在很久了，然而现代企业文化已经习惯于这种形式的“负载平衡”，以获得对人力“资源”的最有效使用。我们从一些松散的技能团体中召集一个团队，每个人在一个时间在几件事情上兼职。你能构建一个高效的兼职人员团队吗？或者，是不是我们已经认为让每个人都很忙才是更重要的？
学习中最难的部分之一是忘却当前的行为。这一点对组织和个人都成立。跳出我们现在所做的行为，思考哪些行为可以让我们工作得更好，这一步精神飞跃，是很难做出的。这里有一个简单的论点也许可以帮助引导改变，不止使人的改变更容易，而且也有重要的经济意义。
图2中显示了4个人工作在3个短期项目中的简单场景。更多的人或者更大的项目，也是同样的动态。在第一个场景中，人们在4个项目上多任务。
图 2: 多任务的个人
图3中显示了第二个场景，一个团队中同样的人顺序完成所有的项目。这个场景保守地假设了成立团队没有生产率的提高，减少上下文切换的数量也没有生产率的提高。注意到所有3个项目都在同一时间完成，但是这个场景中2个项目更早地完成。想象一下由此产生的经济利益。
图 3: 成立一个团队顺序做项目
考虑上下文切换的减少，以及由于团队协作而获得10%的生产率提高，我们可以期待所有3个项目都能提前完成，如图4所示。
图 4: 由于单任务和团队协作而缩短的时间表
Johanna Rothman在“管理你的项目组成”中具体介绍了这个话题。
多样性是生活的调味品
所以，很清楚，多任务是有害的，我们永远不应该这样做，是吗？那我们如何调和“多样性是生活的调味品”这一思想？脑部研究显示，新奇性是有吸引力的。它会产生多巴胺，这是一种神经传递素，会使我们想要更多。对此的解答与专注力和范围有关。如果上下文的切换很大，多任务会对个人和他们的合作者造成代价。如果切换比较小，可以顺应思路，那就会工作得比较好。在敏捷团队中，我们可以通过彼此学习来得到足够的新奇性，也会从完成项目和成功中得到其他好感觉的神经传递素。
总结
Modern business relies on multitasking to get work done. Employees are evaluated on their ability to multitask. IT professionals are routinely assigned to multiple projects. Did we always do this? Does multitasking work? What are the real impacts of multitasking? Is there an alternative?
When we present the Agile (or Scrum) story to new audiences, one of the largest stumbling blocks is the idea that teams work much, much better when their members are dedicated to the team full time. This is not news. For years we have assembled "tiger teams" and "swat teams" to handle special problems, often in times of crisis. Yet our organizations have come to prefer a model of individuals in skill silos assigned to multiple projects at the same time. This is now the de-facto solution to having a large number of things to do at once. It is considered to be the most efficiently use of "scarce resources", i.e. not enough people and all of them specialized.
The Agile model turns this on its head. We form teams of people focused on a small set of things at a time. Instead of creating work and moving people through it, we create teams of people and move the work through them. And we pull instead of push.
Change is difficult. Doing things a different way takes a clear purpose, a vision of benefits and courage. So resistance is natural; people feel unsafe when things begin to change around them. If we can make a shift into Lean thinking, we can leverage two central tenants of "respect for people" and "continuously improve the system" to define a purpose, anticipate the benefits and take the first steps toward improvement. Many people hear "Lean" and think about how to be better at doing the things we are already doing. Lean also says that we can often eliminate even more waste if we stop doing some things, low-value activities, all together.
A person who works on more than one project incurs a cost at each shift from one project to the other. The primary cost is the time required to change context. We know that simple interruptions like a phone call can cost as much as 15 minutes of recovery time[1]. The more complex the task, the more time it takes to make the shift[2].
If you are working on more than two projects the cost can be even greater. It may have been a long time since you worked on that project, taking more effort to remember where you left off. Alternately, if you shift frequently, your context-switching time is a larger proportion of your work time.
There are studies that show people are pretty good at shifting between two contexts for small tasks[3]. In a short time scale this appears to have to do with our two brain hemispheres. To a certain extent, we can parallel process two independent tasks. For larger switches, we should expect some switching cost. Jerry Weinberg[4] showed the escalating context switching costs accrued if each task has a 10% penalty, in reality the costs are frequently higher.
Figure 1
When a person is part of a team, either a traditional loosely connected project team or a focused Agile team, there is a compounded cost of switching. When a team member leaves to do work not related to the team’s work, the team suffers from the absence of the member. When the absent member returns, the team spends time to help the returning member catch up with developments during their absence.
But wait, you may say. An Agile team is cross-functional and is busy doing all sorts of activities every day. These include elaboration of requirements, analysis, design, testing and coding. Isn’t that multi-tasking? The answer has to do with the scope of context. Broad jumps in subject matter and technology require more switching time. Brains are just fine with shifting activities a little. As a focused team, all of the daily activities are targeted at a narrow band of functionality and technology. Only a few stories are being worked on at a time. The context is narrow even though the range of activities is varied. Additionally, Agile has a number of devices for keeping focus – collaboration, task boards, automated testing, retrospection. It is the wide jumps in context that make trouble – other projects, other collaborators, other stakeholders.
The human brain is good at internal multi-tasking. It is doing it all day long. It even does it at night. There are many parts of the brain that are working together and alone all the time. We could not function in our complex environments otherwise. Most of the multitasking is subconscious – filtering of sensory input, integration of related information, moving data from short term to long term memory, keeping the heart and lungs going.
And we multitask externally – driving the car while we navigate and listen to the traffic reports, talking on the phone while we make dinner, planning vacation while we are weeding the garden. Some tasks like folding laundry, walking etc. are mechanical and don’t incur a task switching cost. Others like the keystrokes to navigate through a document or rename a method can be made mechanical over time. But the work of software development isn’t that simple. Much of this automatic multitasking works well. It does have its limits, though. [5]
The context switching of modern multi-project assignments creates a potential for mental re-work. Human brains have two separate kinds of memory – short term (working memory) and long term. There are mechanisms for moving information between the two. There is no guaranty that everything gets moved or that the information going in is the same that later comes back out. We are constantly editing our memories, every time we replay them. New information must reside in short term memory for a length of time before it is moved into long term memory. For example, cramming for an exam may get you a better grade but you may remember little of the material two weeks later. Simply that you may not retain the last things you worked on before the context switch. And those are likely the things you most want to know when you come back to the project.
Research suggests many ways in which multitasking is inefficient or even harmful. Consider:
How do we reduce the amount of multi-tasking for individuals in an Agile context? We mentioned some approaches to this earlier. A more physical environment engages more parts of the brain, leading to faster and more complete synthesis of information. A more focused effort keeps the context scope narrow. Human interactions and a ScrumMaster to facilitate some of the interactions will help to keep that focus.
Some modern technical practices help improve focus for example:
Arguments against multitasking have been known for a long time, yet our modern corporate culture is habituated to this form of "load balancing" for maximally efficient use of human "resources". We assemble teams of people in loose groupings of skill-providers working part time on several things at a time. Can you build a high performance team of part-time members? Or have we come to think that it is more important that everyone appear to be busy all the time?
One of the hardest parts of learning is to unlearn current behaviors. This is true for organizations as much as for individuals, it is just hard to make the mental leap from what we do now to what might work better. Here is a simple visual argument that might help guide a change that is not only easier on people, it makes good financial sense.
A simple scenario shown in Figure 2 has of 4 people working on 3 short projects. The dynamics are the same for more people and larger projects. In the first scenario, the people are multitasking on 4 projects
Figure 2: Multitasking Individuals
Figure 3 shows a second scenario in which the same people form a single team and complete the projects sequentially. This scenario makes the very conservative assumption that there are no productivity gains from teaming or from the reduced number of context switches. Notice that all projects are completed by the same date in both scenarios but that 2 of the 3 projects finish sooner in this scenario. Imagine the resulting financial benefits.
Figure 3: Form a Team to Do Projects Sequentially
With the reduction of context switching and a modest 10% gain in productivity due to teaming synergies, we would expect to see all 3 projects finish even sooner as illustrated in Figure 4.
Figure 4: Shorter Timeline Thanks to Unitasking and Team Synergies
Johanna Rothman covers this topic in more detail in: "Manage Your Project Portfolio"
So, multitasking is clearly bad and we should never do it, right? Then how do we reconcile that with the idea that "variety is the spice of life"? Brain researches have shown that novelty is attractive – it generates dopamine, a neurotransmitter that makes us ask for more[11]. The answer has to do with focus and scope. If the context switch is large, multitasking takes a toll on the individual and their collaborators. If the switch is small, it suits the way we think and it can work just fine. We get sufficient novelty in an Agile team context by learning from each other and producing other feel-good neurotransmitters from completion and success.
Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently. By forming teams to tackle projects sequentially, we can reduce the context-switching cost and gain even more benefit through team synergies.
[1] Slow Down, Brave Multitasker, and Don’t Read This in Traffic
[2] Multitasking Can Make You Lose ... Um ... Focus
[3] Motivated Multitasking: How the Brain Keeps Tabs on Two Tasks at Once (Scientific American).
[4] Weinberg, G.M. Quality Software Management: Vol. 1 System Thinking. New York. Dorset House, 1992.
[5] See "Hang up and Drive" (a video from the book "Brain Rules") for a quick description of what happens when you drive and talk on a cell phone at the time:
[6] The Neuroscience of Leadership
[7] Studies show multitasking makes you stupid
[8] The Madness of Multitasking (Psychology Today)
[9] Slow Down, Brave Multitasker, and Don’t Read This in Traffic
[10] "Your Brain At Work", David Rock
联系客服
