为什么需要使IT工作可视化并控制半成品

本书中我最喜欢的（也是唯一的）一张图表显示，等待时间是工作中心中某个资源忙碌程度的函数。埃瑞克用这张图表来说明为什么布伦特的30分钟的简单变更要耗费几个星期才能完成。原因显然是，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，我们每次交给他的工作都只能在队列里枯等，如果不进行加速或升级处置，就永远不会完成。

图表显示：横坐标轴上是工作中心中给定资源的忙碌百分比，纵坐标轴上是大致的等待时间（更确切地说是队列长度）。曲线的形状表明，当资源使用率超过80%时，等待时间就会直线上升。

本书中，比尔及其团队意识到，他们对项目管理办公室承诺的交付期会带来怎样的灾难性后果。

我告诉他们，埃瑞克在MRP-8对我说过，等待时间取决于资源使用率。“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说，如果一个资源的忙碌时间是50%，那么它的空闲时间也是50%。等待时间就是50%除以50%，也就是一个时间单位。就说是一个小时吧。所以平均来说，一个任务在处理前的排队等待时间为一个小时。”

帕蒂似笑非笑地说：“哦，当然了。因为输入字符只需要30秒，对不对？”

比尔及其团队意识到，他们那个30分钟的简单任务实际上需要7个交接步骤（也就是服务器团队、网络维护团队、数据库团队、虚拟化团队，当然还有布伦特、布伦特、布伦特）。假设所有工作中心都有90%的时间是忙碌的，那么这张图表告诉我们，在每一个工作中心的平均等待时间是9个小时。由于工作必须经过7个工作中心，总共等待时间就是7倍：63个小时。

也就是说，总的“有效时间”（有时候也称为“加工时间”）只有总交付周期的0.16%（30分钟除以63小时）。那就意味着，在总交付周期99.8%的时间里，工作只不过在排着队等待被执行（例如，在报修系统里等和在电子邮件里等）。

我的合著者乔治·斯帕福德和我同在华盛顿州立大学参加詹姆斯·霍尔特博士（在延伸阅读部分有更详细的介绍）的EM526约束管理课程时，我们首次见到了这张图，它如此出色地显示出，高资源使用率所导致的长时间排队的破坏性本质。

遗憾的是，我不知道这幅图的确切来历。有人和我一样相信，这幅图是立特尔法则的简化版本。根据这个法则，我们假定的是只有一个工作中心、均匀的工作队列（例如，所有任务需要的完成时间都相同）、工作之间没有延迟等。

在这幅图中，我相信“等待时间”其实代表着“队列长度”。也就是说，由于它不是所用时间，因此没有时间单位（也就是说，既不是分钟，也不是小时、天）。关于此书派生出来的最棒的讨论（及其合理性/不合理性）都可以在Linkedin网站上本书的页面看到。这些讨论尽管有时略显尖刻，但确实充满智慧。

我的看法是，科学的目标是用最少的原理来解释最多的现象，并揭示惊人的内涵。我认为这张图很能说明问题。它有效阐释了过度压榨IT工作者的灾难性后果，以及在IT运维部门使用传统项目管理方式的错误。