写点什么

多任务让你走得更慢

  • 2010-08-31
  • 本文字数:3853 字

    阅读完需:约 13 分钟

现代商务依靠多任务来完成工作。评价员工也基于的他们多任务能力。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] 。对此的解答与专注力和范围有关。如果上下文的切换很大,多任务会对个人和他们的合作者造成代价。如果切换比较小,可以顺应思路,那就会工作得比较好。在敏捷团队中,我们可以通过彼此学习来得到足够的新奇性,也会从完成项目和成功中得到其他好感觉的神经传递素。

总结

项目间的上下文切换需要时间,这对组织来说是成本。涉及项目越多,或者项目越复杂,那成本也会越高。如果在一个时刻专注在一件事,坚持一段时间,工作效率就会提高。通过组建团队来顺序处理项目,我们可以减少上下文切换成本,也可以从团队协作中获得更多收益。


[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] 查看 “ Hang up and Drive ”(《Brain Rules》一书中的一段视频),视频中简单描述了当你同时开车和讲电话时发生了什么

[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

[11] Multitasking: The Brain Seeks Novelty

查看原文: http://www.infoq.com/articles/multitasking-problems


感谢郑柯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2010-08-31 00:006185
用户头像

发布了 24 篇内容, 共 58152 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

网易数帆Curve加入PolarDB开源数据库社区

阿里云数据库开源

数据库 阿里云 开源数据库 polarDB

Hoo虎符研究院 ∣ 投资前沿——STARKNET 生态一览 (2022.3.18)

区块链前沿News

虎符研究院

好评不断的文化纪录片《中国》,背后的“剪刀手”竟是它?

百度大脑

程序员的工作就只有写代码么?

程序员鱼皮

经验

Linux之alias命令

入门小站

Linux

架构实战营模块九-毕业设计-电商秒杀系统

Jude

架构实战营

达观数据CTO 纪达麒:基于阿里云计算底座,打造智能办公机器人

阿里云弹性计算

机器人 神龙架构 智能办公

全球央行积极推进CBDC 俄罗斯制裁或成催化剂?

CECBC

golang里的一些奇奇怪怪的东西

不登山的小鲁

golang Go 语言

JVM自定义类加载器在代码扩展性的实践

Java工程师

JVM 代码 类加载器 实践 #java

失败案例之安全抓包测试

网络安全学海

网络安全 信息安全 渗透测试 安全漏洞 网络抓包

重新刷新你对Redis集群的理解

Java工程师

数据库 复制 数据共享 集群 redis'

区块链正在塑造医疗保健生态系统!

CECBC

在线JSON转HTML工具

入门小站

工具

Rust的迭代器

Shine

rust 迭代器

如何用建木CI实现前端代码自动格式化

Jianmu

前端 代码管理 格式化 prettier 建木CI

Apache DolphinScheduler&ShenYu(Incubating)联合 Meetup,暖春 3 月与你相约!

白鲸开源

大数据 开源 工作流调度 Apache DolphinScheduler

SpringBoot接入轻量级分布式日志框架(GrayLog)

Java工程师

程序员 分布式 Web spring-boot

深度关注 | 元宇宙如何改写人类社会生活

CECBC

Redis集群架构剖析(2):槽位

非晓为骁

redis集群 slots 分布式,

Flash退出历史舞台后,Web端3D会迎来怎样的发展?

Orillusion

WebGL 3D渲染 3D模型 Flash webgpu

Redis Pipeline原来是这么用的

Java工程师

数据库 程序员 代码 pipeline redis'

Java 中的静态字段和静态方法

踏雪痕

Java 3月程序媛福利 3月月更

国际自主智能机器人大赛强势来袭,NAACL同声传译任务等你来战

百度大脑

2022最新IntellJ IDEA的mall开发部署文档

北极的大企鹅

开源 部署与维护 开发者, MAll

Flutter 开发一个常用的登录界面

岛上码农

ios 移动端开发 3月月更 flutter开发 安卓开发

调查:区块链游戏玩家将玩NFT游戏视为一份潜在的全职工作

CECBC

第三空间娱乐体验重构:AITO 问界 M5雕刻的七宝楼台

脑极体

毕业总结

Geek_93ffb0

「架构实战营」

北京大学董豪老师解密人工智能开发工具的过去与未来

OpenI启智社区

人工智能 开发工具 启智社区 北京大学

在线CSS3压缩美化格式化

入门小站

工具

多任务让你走得更慢_研发效能_Roger Brown_InfoQ精选文章