如何应对多任务

2016-09-07

有个新的研究说,那些愿意多任务的人,那些号称自己善于多任务的人,其实还往往是多任务能力更差的人。他们在面对多任务工作的时候,效率比一般人更差,甚至比不愿意搞多任务的人还差。

因为这些人之所以要搞多任务,并不是因为他们擅长多任务,而是因为他们大脑硬件有问题(《浅薄》)—— 他们没有办法集中注意力!

坐在那里读一个小时的书,他做不到。他们根本管不住自己,可能不被打扰就难受。为什么多任务工作效率低?因为在不同任务之间转换得花费时间。

上面的话摘自万维钢老师的文章。看了是不是阵阵发冷?其实早就已经有共识了,单任务串行比多任务并行效率要高。至于高多少,就看任务的复杂程度了,一般越复杂的任务差距越明显。

什么是多任务?举个最简单的例子,有 A 和 B 两个任务,把 A 任务拆成一小段一小段,把任务 B 也拆成小段,然后 A-B-A-B 这样穿插着做。如果还有任务 C、D、E……这个序列就可能变成 A-C-B-D-B-A-C-E-C 乱到没法看。

一些鼓吹多任务的人,认为多任务是提高效率的法宝,这有点扯,但我也不走向另一个极端 —— 多任务过敏,一被打断就变得焦躁。

一些抨击多任务的文章,作者态度都很坚决,那就是一定不要多任务!一定不要!但是现实生活中,不可能有那么理想的环境完全不被打扰。即使程序员这种工作,一天被打扰十几次是很正常的,产品经理、测试、其他开发同事、领导,这些人打扰你也都是为了工作,能不搭理?除了外界的打扰,自己分心走神也频繁发生。所以想完全不切换任务实在不太可能,不如接受它,然后看看如何把损耗降低到最低。

刚才说过,越复杂的任务,任务切换带来的损耗就越大。而那些不怎么用动脑的小任务,其实不怎么受影响。所以我们只讨论复杂的任务。

不妨借鉴一下计算机是怎么做的。计算机程序都有源代码,复杂的工作也应该有一个落实到文档上的书面计划。它是我们的地图和指南针。

计算机在执行一个程序的时候,需要把数据从硬盘载入到内存和 CPU,也就是从低速存储器转移到高速存储器当中。低速和高速存储有不同的特点:

  1. 高速存储器,例如内存、 CPU 缓存和寄存器,好处是非常快速。坏处是资源有限且数据容易丢失,一旦意外中断,数据就丢掉了。
  2. 低速存储器例如硬盘,速度慢,但不怕中断,保存了以后就不会丢。

程序在执行时,载入到高速存储器中的数据,叫做这个程序的上下文(context)。这非常好理解,我们在做具体任务时,也有上下文,就是我们脑子里正在想的事情。可一旦有打断,再回来的时候,我们经常回想不起来当初到哪儿了,或者去努力还原的时候出现了偏差。

解决这个问题,需要把上下文写下来,这样被打断再回来的时候可以快速准确地回想起当时的上下文。这样做的好处还不止于此,文字记录的同时,相当于把一个复杂的任务拆解成一个一个的小任务,有主干也有枝叶,一棵树下来描述了整个思考过程。当遇到问题的时候,想追溯错误源头,这些文字就成了重要的参考。

简单总结就是,好记性不如烂笔头。

当然我还是要承认,单任务比多任务效率高,专注地把一件事干完自然是最好的。只是在现实的复杂环境下,我们有了这套方法,就不再惧怕被打断了。毕竟害怕、焦虑、坏情绪,都是工作的大敌。

回主页 RSS 订阅
京ICP备14007233-1号