二十三、任务换人有害无益

在管理一个程序团队时，第一件要学的事就是任务配置(task allocation)要正 确。「任务配置」只是把事倩分丈家微的夸大说法。用希伯来文的普通话来 说就是「倒档案」（因为你会把档案倒在某人身上）。有些事情做得对会得到不可 思议的生产力利益，决定哪些档案要倒在谁身上就是其中之一。反过来没做好 的话可能就会陷入麻烦的状况，没有人能做好何任何事情而且大家都抱怨「在这 里什么事都做不起来。」 由于这是个针对程序员的网站，我要拿个程序设计问题让你的脑袋动一动暖暖身。

假设你要做A和B两件运算要做。每一件都需10秒的CPU时间。现在你有一颗CPU， 为了简化问题，所以工作序列中没有其他东西。

在我们的CPU中可以选择是否用多任务处理。所以你可以先做好一件再做另一件。

循序处理

也可以使用多任务方式。如果用多任务的话可以假设这颗特别的CPU每个工作每 次可以执行一秒，而且工作切换完全不花时间。

多任务处理

你会选哪一种方式呢？大部份人的直觉反应都认为多任务比较好。不管哪一种状 况，都得等20秒才能两件运算都完成。不过可以想想单就各洋运算来说要多久才 有结果。

在两种状况下，运算B(标成蓝色)都要20秒才得到结果。不过运算A的结果在多任 务时需要19秒。可是循序时就只要10秒就好了。

换句话来说在这个安排好的例子中，循序处理的每洋运算游f均对/琢比多任务处 理少(15秒对19.5秒）。（事实上这例子也并不是真的那么假–它是源于Jared在工作中必须解决的一个真实问题）

我刚刚说过「工作切换完全不花时间」。其实在真的CPU中工作切换是需要一点 点时间的，基本上要足够储存CPU缓存器的状态并加载其他工作的CPU缓存器。实 际上这短到几乎可以忽略。不过为了让生活更多乐趣，让我们假设工作切换需要 半秒。现在情况变得更糟了：

现在呢，虽然我知道这有点蠢，不过就算为了让我高兴一下，想想如果工作切换需要一分钟那如何？

工作切换用的时间愈长，多任务处理的代价愈大。

这件事本身不怎么新奇，不是吗？不久大概就会有些白痴气愤地写信指控我「反 对」多任务处理了。他们会质问我：「你真的想要回到那种得先结束WordPerfect 才能执行Lotus 1-2-3的DOS时代吗？」

不过那并不是我的意思。我只是想要你同意，在这类例子中：

a)循序处理会让结果次上比较快得到，而且 b)工作切换需要愈久，多任务处理所付的代价就愈大。

够了，别管CPU 了，来管管人吧，这有趣多了。这里的重点在于管理「程序员」 时，工作切换会需要很长很长的时间。因为程序设计这种工作必须同时在脑袋 里记很多东西。另外记住的东西愈多，写程序时生产力愈高。用全速写程序的程 序员脑里随时都会记住无数的事情：变量名称，数据结构，重要的API，写过常要 用到的辅助函数名称，甚至存放原始码的次目录名称，一切东西都要记住。如果 你把程序员送到克利特岛去度假三星期，他所存东西通通都会忘掉。人脑似乎会 把东西移出短期RAM，改存到永远都读不回来的备份磁带上。

要多久呢？嗯，我的软件公司最近放下手头上在做的事(开发一套代号CityDesk 的软件产品），花了三星期去帮助某个客户处理一个紧急状况。当我们回到办公 室时，感觉好像要另夕A三星期才能回复全速制作CityDesk。

就个人层次来说，你曾经注意过某件事吗？叫某人做一个工作可以做得很好，可 是如果给他两个工作，他会把其中一个做好却忽略另一个，不然就是两件工作都 做得很慢，慢到你觉得#龙蜜都比他勤劳。这是因为程序设计的工作就是需要很长 的切换时间。就我自己来说，当我需要同时完成两个程序设计项目时，切换时间 大概要六个小时。以一天八小时来看，等于说多任务处理把我的生产力降到每天 只剩二小时。真令人沮丧啊。

同样的道理，如果你给某人两件工作，应该要感谢他们只做一件工作而放弃 另一件，因为这样能做好更多的事，而且平均上也能更快完成工作。事实上这一 切的重点就是绝对不要让人同时做一件以上的事。请确定你有明白它的意思。好 的经理人会认为自己的责任是濟餘摩涛，好让大家都能专注在一#事倩并把它真 的完成。遇到紧急状况时，请先想想能不能自己处理掉，真的不行再丢给深陷在 专案中的程序员吧。