多线程工作

多线程工作

如何学会多线程工作？

这是一个很有意思的问题，我准备先介绍一下心理学上对这个问题的看法，然后从自己的思考和经验出发谈一谈应对之道。

的确，从认知心理学的观点来看，严格来讲人的「多线程工作」是不可能的。因为在任一个瞬间，人只能有一个「注意焦点」，这个注意焦点牵引了人的认知加工资源。但有时你会误以为同时关注了两个东西，其实是发生了注意转移的结果，即焦点从一个对象转移到另一个对象上，实际上还是一个串行而非并行的过程。当然有一种例外是，有些很熟练的技能，可以「自动化」地、不加注意地进行，那么就可以和其他事情同时做。比如你骑自行车，你的女朋友坐在后面笑，这时你的注意焦点保持在你女友身上，你和她聊天的同时，你的腿也在一刻不停地蹬，你不需要停下来是因为骑车不需要你的注意和认知资源。但如果此时突然前面蹿出一只喵星人，你可能立马就会把注意焦点给转移了。

当然我们平常所说的多线程工作，并非是这种「秒级」、「毫秒级」的「多线程」，而是指在一个「时期」内，会同时担负几种不同的工作，完成不同的任务，这就是另一种意义上的，不同任务之间需要切换的「多线程」。「任务切换（task switching）」也可以算认知心理学中的一个经典课题了。心理学家早就发现，当你从任务 A 切换到任务 B 后，执行任务 B 的绩效要明显比非任务切换条件下执行 B 的绩效差，这个差异称为「切换代价（switching cost）」。切换代价的形成原因主要有两种，一是任务 A 留下的认知惯性，也就是我之前已经习惯了任务 A 的认知情境、反应方式，这个惯性会对完成任务 B 造成干扰，二是做 B 的时候需要对 B 进行认知重构，重新回忆起 B 的相关背景和信息，这个重构也需要时间，而且可能不完整。

可现实就是这样，虽然不论从心理学还是从我们的生活经验来看，这种需要任务切换的「多线程」的感觉很糟，效率很低，但我们往往没有选择：一个任务做到一半被打断，然后去做另一个任务，然后又被打断，又去做另一个……这里有个至关重要的事实是：如果你是在非常投入和忘我的思考时被打断，那么你的「损失」和懊恼就会非常大，相反，如果你只是在做抄写一篇文档这种不动脑子的活，那么即便是频繁的中断也不会对你造成太大的影响。所以，如果你能选择好合适的中断点，中断就并不可怕，切换的损失也可以降到最低，如果说多任务工作有什么技巧的话，那么这个技巧就是「对中断点进行控制和管理的技巧」。

这个技巧的前提是，我们需要对要完成的任务进行有效地剖析，区分出「容忍中断」的部分和「无法容忍中断」的部分，然后用可保证的相对完整的时间去施行那些「无法容忍中断」的部分。为此我提出了一般任务分解的「三明治模型」：

这是一个金枪鱼三明治，它有一个核心，就是金枪鱼肉泥，完成这个部分的努力我称为「核心思考区间」。事实上大多数任务都有一个至关重要、通常也是最棘手的部分，这个部分需要我们集中精力、非常专注地进行思考，然后将其破解，一旦这个部分被我们「吃下」，那么这个任务就已经完成了大半，余下的就是一些支持性的、补完性的工作（即「支持性思考区间」）和一些「体力劳动」（即「操作性动作区间」）了。

我自己工作中有一个习惯，就是拿到一个任务后，势必要先去找那个任务的核心思考区间，找到那块硬骨头，去啃下来，而不是先去做那些周边的打扫性的工作。举个简单的例子，如果你现在接到一个做 PPT 的任务，你第一步准备做什么？是先挑一个漂亮的主题模板吗？不是。是马上去百度谷歌查资料吗？也不是。正确的答案是：设计 PPT 的架构。即你要分析你的受众，他们的知识水平、理解水平以及兴趣点、关注点，在此基础上设计你的内容以及展现内容的顺序，先讲什么、占比多少，再讲什么，占比多少，以及讲的时候采取什么风格、策略，然后，PPT 的架构就出来了。这个实施过程就是该任务的「核心思考区间」，你不需要任何辅助，你只需思考，非常专注的思考，你要的工具，仅仅是一张纸和一支笔（你需要把你的灵感快速地记下来）。等你完成了这个过程，你可以选择继续填充具体的内容（「支持性思考区间」），也可以 break 一下，也可以去做别的工作，都无所谓。之后，等你在为这件 PPT 选择模板、寻找配图或者调整字体的时候（「操作性动作区间」），你并不大会介意被打断，因为你知道，这个任务在某种意义上，你已经完成了。

不瞒你说，为了写这篇文章，我用了半个小时的时间、一张 A4 纸和一支笔，用我纯粹的、专注的思考，来设计它的「架构」。设计完成后，我吃了一顿晚饭，看了一集美剧，这个写作的中断并没有让我担心，因为我知道，即便我还没有在电脑上敲入一个字，这个答案，其实已经写完了。

我手头有一本《编程大师访谈录》，收录了 19 位编程大师的成长和工作的心得。我意外地发现，他们在编程时采用的策略如出一辙。例如曾领导微软公司 Word 和 Excel 开发的查尔斯·西蒙尼（Charles Simonyi）说：

「编程的第一步是想象。就是要在脑海中对来龙去脉有极为清晰的把握。在这个初始阶段，我会使用纸和铅笔。我只是信手涂鸦，并不写代码。我也许会画些方框或箭头，但基本上只是涂鸦，因为真正的想法在我脑海里。我喜欢想象那些有待维护的结构，那些结构代表着我想编码的真实世界。一旦这个结构考虑得相当严谨和明确，我便开始写代码。我会坐到终端前，或者换在以前的话，我会拿张白纸，开始写代码。这相当容易。我只要把头脑中的想法变成成代码写下来，我知道结构应该是什么样的。」

西蒙尼强调，想象的这步是「最重要的一步」，而后面的实际编写代码的工作反倒「相当容易」。同时为了保持专心致志，他一般会晚上编程，因为白天的多任务情况下，总是会被打断。

另一位顶尖的程序员巴特勒·兰普森（Butler Lampson）说，他通常「会在纸上记下笔记，然后开始编程」，或是「尽量用相当精确而抽象的语言写出构思的关键部分」。加里·基尔代尔（Gary Kildall）说：「我会先画数据结构，然后花很长时间思考数据结构；在开始编程前，我会一直思考整个程序的流程」。

这些高手的诀窍，与我的个人经验类似，都指向了多线程工作的秘诀，也就是说，你需要尽量挤出一段时间，能够进行专注不受干扰的、甚至达至「心流」状态的思考，以把最关键的「硬核」搞定。

这个方法背后暗含着这样一个逻辑：当我们不得不对一个任务进行分段处理时，我们并不应机械地按照时间段来切分（「今天上午 9 点至 10 点做 A，明天下午 1 点至 3 点继续做 A」），而是应该按照这个任务的内在逻辑来切分，于是当我们准备中断某个任务时，我们能尽量保证这个任务的某个逻辑单元已经完成了。即便我们在实施「支持性思考区间」和「操作性动作区间」时，也应遵循这样的原则。

这就是我一直对「时间管理」及其方法不大感冒的原因，我认为它并没有击中问题的本质。事实上，我们要管理的并非是物理学意义上的时间，我们要管理的，是心理学意义上的运用心智的意愿和能力。