在最近的一次活动中，有一位经理把我拉到一边，对我说：“Johanna，对于敏捷这东西，我总有些不太明白。显而易见，并不是所有人都被100%利用了。”
“他们没有被100%利用又怎么样呢？你觉得这有问题？”
“见鬼，是的。我付他们工资！因此，我想知道我会从他们身上获得满满的价值！”
“如果我告诉你，你获得的价值可能比你支付的要多，也许有1.5～2倍，你觉得怎么样？那样你就开心了吧？”
那位经理平静下来，然后转向我，继续问：“你怎么知道的？”
我微笑着说：“以后再告诉你。”
有太多太多的经理相信“100%利用”的神话。那是一种信仰——每个技术人员在每一天里的分分秒秒都必须被充分利用。这个神话的问题在于，人们没有时间去创新，没有灵感，也没时间去探索。
更糟糕的是，还会出现僵局。在一个人被100%利用的情况下，你在A项目上需要他的时候，他可能正在做着B项目。你们无法聚集起来开一个会。你不能打一通电话。你甚至没有合理的时间去回复邮件。为什么呢？因为你对各种其他打扰已经应接不暇了。
我们为什么会这样？
回到早期的计算，机器比程序员要昂贵几个数量级。在20世纪70年代，在我开始以程序员身份打工那会儿，那时的公司可能会给经验极其丰富的程序员支付5万美元的年薪。而对于那些刚刚从学校走出来的新手，公司支付的年薪可能不到1.5万美元。我们当时觉得已经赚得非常多了！相比之下，公司可能每年花很多万美元的钱去租赁机器，或者花数百万美元买下机器。你可以看到，薪资水平与机器成本之间相去甚远！
在电脑有那么贵的时候，我们利用了机器时间的每一秒钟。为了上机，我们需要登记。我们在桌上检验自己的工作。我们进行设计评审和代码评审。我们珍惜上机时间的每一分钟---没错，我们的工作常常受限于CPU的一分钟时间。如果你想用更多的时间，那就预约下班时间吧，比如半夜2点～4点。
需要注意的是，那时候珍稀的不只是上机时间，还有内存。在那古老的岁月里，我们的内存只有256字节，代码是用汇编语言写的。我们的代码要分页。如果你有一段程序超过一页，你得在一页的末尾转移到另一页有空的地方，以便于换入。（这常常需要手工完成。噢……我一点也不怀念那个旧年代！）
到20世纪70年代后期以及80年代，微型电脑的出现拉近了程序员薪水与电脑价格之间的差距。不过，也只有当微型电脑的价格真正下来了、并且个人电脑开始主导市场的时候，程序员的身价才变得比电脑贵多了去了。到那时候，很多人都觉得，让程序员独占电脑的工作方式成本更低，这比设计评审、代码评审或与其他人讨论架构更有效。
到了20世纪90年代，尽管电脑、硬盘和内存的价格持续下跌，程序员和测试人员的身价也变得越来越贵，我们中的一些人清楚地认识到，软件开发更多是一种合作，而不只是程序员单独面对电脑那么简单。这也便是为什么Watts Humphrey和软件工程研究所在90年代备受瞩目的原因。不是因为人们喜欢繁琐的流程，而是因为（特别是在一个串行周期里）你必须采取一些措施，以使得系统开发收获更大的成功。很多管理者陷入了“100%利用”的思维泥潭。需要注意的是，“100%利用”的概念在当时被提出了没多久，并且很受重视！
译者注：Watts Humphrey（1927—2010）在软件工程领域享有盛誉，被美国国防软件工程杂志《CrossTalk》评为影响软件发展的十位大师之一。他在IBM工作了27年，负责管理IBM全球产品研发。离任后，受美国国防部委托，加入卡内基·梅隆大学软件工程研究所（SEI），领导SEI过程研究计划，并提出了能力成熟模型（CMM）思想。在CMM浪潮席卷软件工业界之时，他又力推个人软件过程（PersonalSoftware Process，PSP）和团队软件过程（TeamSoftware Process，TSP），成为软件开发人员和开发团队的自修宝典。他的著作颇丰，《软件工程规范》、《个体软件过程》、《软件制胜之道》等都已成为经典。
当一台单进程的电脑被完全利用的时候，请记住这意味着：它一次只能做一件事；它不能服务于任何中断；它不能响应任何键盘输入；它不能更新状态；它只能一直处理下去，直到完成。
如果程序表现良好，并且不受限于I/O、内存或CPU，运行在一台单用户、单进程的机器上，比如只有加减乘除功能的个人计算器，那也许还没事。但只要你加入另外一个用户或者另一个进程，你就麻烦了。（或者，如果程序表现不正常、没能很好地完成，你也会陷入麻烦之中。）
现代的电脑就是那样。现代电脑都是多进程的机器。
对于多进程的机器，如果一台电脑被完全利用，你会看到系统抖动，可能还会僵死。想一想高峰时期的公路，没有一辆车动得了；这时候，公路是被100%利用了啊。但是，我们不想公路被100%利用。我们也不想让眼前的电脑满负荷运行。如果你的电脑被用到了50%～75%，你会感觉它变慢了。而高于85%时，电脑会有难以预期的表现。它们的生产力是不可预期的，你无法判断会发生什么状况。
遗憾的是，人类也面临同样的问题。
为什么100%利用不适用于人
现在，想一想我们自己。当我们在100%利用的状态中时，我们根本没有闲暇时间。我们在各种任务或干扰之间疲于奔命，没时间思考。这时候，至少有两方面的问题：难以避免的多任务，以及没有思考。
实际上，我们根本不是多任务并行——只不过是快速切换而已。我们不像电脑；电脑在切换时，它们把内存里的东西完美地拷贝到磁盘上，当需要换入的时候，能够再次把数据读进来。因为我们是人，我们不能完美地把我们脑子里的东西备份出来，后续也无法再完美地恢复。因此，切换是有成本的，因为我们在处理其他事的时候必须记住之前脑子里在想的东西。那也需要占用时间。
因此，这里有一个情境切换的问题，我们需要花费时间把脑子里的东西换出去、换回来。所有这些时间和不完美会累加起来。因为我们是人，我们不能为各个任务完美地分配自己的时间。假设我们手上有3个任务，我们不能做到在每个任务上花费33%的时间——只要我们乐意，我们想在一个任务上花多少时间就花多少时间，平均33%只是一个假设罢了。
接着，让我来解决100%利用中没有思考的问题。如果你想让大家考虑换一种新的工作方式，怎么办？如果你令他们满负荷地工作，他们会尝试吗？没机会！他们不会考虑，因为他们没有时间。
因此，你让大家机械地工作：用他们了解的最佳方式去服务于各种中断、做尽量小块的工作、做到足够多就算通过。他们不会想办法去提高。他们不会想办法去帮助别人。他们不会尝试创新。他们只是在想，“我怎样才能从这堆积如山的工作中解脱出来？”这对他们来说是很恐怖的，对产品也不好，对与他们打交道的任何人都不好。
当你让人们工作在100%利用的状态，与你计划让他们每天大概只干6小时的技术活比起来，你从他们那里得到的工作成效会小得多。人们需要时间去阅读邮件，去参加临时的会议，休息一下，进行一些架构方面的讨论，喝杯咖啡，或者做点别的什么事。如果你为上午计划一大块的工作，为下午再安排几个大块的工作，并把会议的数量降到最低，技术人员会很好地完成分配给他们的工作。
如果你在一个喜欢开会的组织里工作，你甚至不能计划每天6小时的技术活——你必须计划得更少一点。会议在浪费人们的时间。
但不管怎么样，如果你按照100%利用来计划，在整个组织范围内完成的工作会少得多。你营造了一个可怕的工作环境，这还是一个没有创新的环境。那不像是一条成功之道，是吧？
敏捷和精益让神话破灭
敏捷和精益不会使“100%利用”烟消云散，但它们让神话破灭了。通过把所有的工作装进Backlog（一个管理积压工作的仓库），这有助于管理层和研发团队看清楚每个人应该做的事情，以及大家面临着多大的挑战。这很不错！
一旦每个人可以把工作可视化，你就能围绕它开展工作了。也许某些工作确实与产品路线图相关，但不必在这个迭代里完成。也许有些工作是为另外一个项目做的，应该被推迟到下一个迭代周期。这很好——这就是项目组合管理。也许有些工作应该由某人来做，而不是这个团队来做。这很好——相关管理者需要出面协调。
不管你做什么，只有你看到了工作，你才能有所作为。只要你完全地把工作可视化，你就能管理。
记住，如果你被100%利用，那就没人能做事了。如果你想为你的组织贡献实足的价值，你需要让自己被“利用”到50%～60%。因为浪费思想（不管什么思想）是件可怕的事。