免费下载案例集|20+数字化领先企业人才培养实践经验 了解详情
写点什么

多任务让你走得更慢

  • 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:005621
用户头像

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

关注

评论

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

外包学生管理系统架构文档

白杨

云渲染时可以关机吗_云渲染电脑可以关闭吗?

Renderbus瑞云渲染农场

云渲染

Syscoin宣布与Web3孵化器WEconomy建立长期合作伙伴关系

100DAO 加速计划

DAO #Syscoin #区块链 #Web3

站在2023起跑线,政企数字化如何深入“核心地带”?

脑极体

数字先锋| 药品信息何处有?尽在标识编码处

天翼云开发者社区

重磅 | 九科信息成功入选中国交通建设集团财务云(RPA)项目

九科Ninetech

软件测试面试真题 | web自动化关闭浏览器,quit()和close()的区别

测试人

软件测试 面试题 自动化测试 测试开发 web测试

案例 | 九科信息久其报表RPA项目助力某大型央企财务部门提质增效

九科Ninetech

功能上新|使用 Excel 低门槛进行指标分析!

Kyligence

数据分析 指标管理

华为云发布CodeArts Req需求管理工具,让需求管理化繁为简

IT科技苏辞

【从零开始学爬虫】采集全国高校导师数据

前嗅大数据

数据采集 爬虫教程 爬虫入门

MySQL分库分表,可能真的要退出历史舞台了!

Java永远的神

MySQL 程序员 后端 架构师 分布分表

架构实战营第 10 期 - 模块三作业:外包学生管理系统详细架构设计文档

kaizen

「架构实战营」

新茶饮 200+ 门店优化库存成本,需要几个数据分析师?

Kyligence

数据分析 指标中台

TSDB在油气田勘探开发领域的应用

CnosDB

IoT 时序数据库 开源社区 CnosDB infra

作为一个研发凭什么花大量时间修安全漏洞?

墨菲安全

安全 开发

32篇年度最佳AI论文;Python编译器Codon开源;ChatGPT的前世今生

OneFlow

人工智能 深度学习 大模型

SpringMVC还是Spring WebFlux?谁是下一代的Java程序员技术栈?

程序员小毕

Java spring 程序员 后端 springmvc

5分钟搞懂Jenkins分布式架构

俞凡

架构 DevOps cicd 最佳实践

PM&PMO汇报工作的5大技巧,学会了让老板眼前一亮!

PMO实践

PMO 年终报告 年终总结 项目经理

阿里云对话 Tapdata:以秒级响应速度,为企业提供实时数据服务

tapdata

ETL 实时数据 DaaS 现代数据栈

华为时习知,让企业培训更简单!

IT科技苏辞

软件测试面试真题 | 需求评审中从几个方面发现问题

测试人

软件测试 面试题 自动化测试 测试开发 需求评审

安全可信| 安全与高效兼得?天翼云EasyCoding敏捷开发平台来了!

天翼云开发者社区

直播倒计时1天!“基于AIOps的全面可观测性网络研讨会”与你不见不散

博睿数据

根因分析 直播 智能运维 博睿数据

数字先锋| 活起来、动起来、用起来!“海南模式”让数据要素发挥更大价值

天翼云开发者社区

案例 | 九科信息为某大型科研单位设计财务系统科目预警RPA

九科Ninetech

小数据治理靠“人工”,大数据治理靠“智能”

用友BIP

融云任杰:激活组织生命力 让听见炮火的人做决策 | TGO专访

融云 RongCloud

专访 程序员‘

天翼云斩获2022全球分布式云大会两项大奖

天翼云开发者社区

2022年中国第三方输入法发展分析

易观分析

报告 输入法 语音输入

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