第三章根除低下的效率

就如当下的经济困难时期，人们不再发出社会不公这样的陈词滥调。很多时候，我感到轻松了许多，因为我再没听到说英格里德的收件箱中有好多邮件，说布赖恩又怎么怎么搞砸了工程创建，说苏雷什负责的服务开发日程拖了大家后腿。

然而，我们正处于困难期，我们还要为恼人的错误打补丁。你要什么时候再打起精神来修复大堆害人的程序漏洞？确实，还毫无头绪。

令人惊奇的是，好多一般性的问题用两种简单的方法就可以解决——单件流和核对清单。有大量的行为与过程理论可以说明这些简单的办法很奏效。这里的重点是它们很有效，而你与你的团队没有它们的话就会很没效率。

都很简单

打开英格里德的邮箱。跟大多数邮箱一样，英格里德的邮箱都快满了。她花了大量的时间来处理，但是邮箱只会越来越满。她总是在邮箱中迷失，找不着想要看的邮件，或反复查看同一封邮件。很无助。

如果英格里德采用单件流，那就管用了。单件流会提示她一次处理一件（一次邮件消息），直到这个消息处理完成。“处理完成”指的是她再也不用看那条消息了（除非是为了回复与之相关的邮件）。

以下说明单件流是怎么奏效的。英格里德每次查看一条邮件消息的时候，她就采取以下4种步骤之一：

1她删除了邮件消息（我最乐意的）。

2她把它放进了一个文件夹。

3她把邮件转发给了另一个人，然后将其删掉或放到文件夹里。

作者注：你怎样保证能时时跟踪一个非常重要的转发邮件？我采取以下方法之一。

我把我转发的邮件放到一个特殊的文件夹里以示谨记。这封邮件一直呆在那里直到我收到回复或再给对方发一次提醒（之后这次提醒的信息也放到这个特殊的文件夹里）。在没有非常特别或重要期限要求的时候我都使用这种方法。

我把我的转发邮件移到我的日程表里，这样日程表就能提醒接收者按约定时间回复邮件或处理相关问题。在有非常特别或重要期限要求的情况下我采取这种方法。

4她回复了邮件，之后就删除了该邮件或将其存到文件夹里。

就是这样。她从来不用打开一个邮件消息然后还是把它放在收件箱里。每天结束后，以及之后的每一天，她的收件箱都是空的。她从不会错过、丢失或再看一次某封邮件。

单件流是很有效的，因为它节省了管理费用及避免了重复劳动。每次你查看一条新的邮件消息时要进行一次上下文切换，这样就产生一次管理费用，每次当你重新查看一条消息的时候，就是一次重复劳动。有了单件流，管理费用就能降低，而重复劳动就不会再发生。

作者注：是的，“一次过目”的准则也有例外，但是这种情况只占5%。有一天就在我身上发生过。即使那些邮件消息都放到了特殊的文件夹里以示提醒，我还是要用邮箱的过滤功能预先从讨论组中过滤邮件。如果你想知道怎么做，而不想把邮箱里的邮件全部删除，可以看下面的步骤。

1及时查看与你手头工作相关的邮件并把它移到特殊文件夹里。

2为剩下来的与你工作职责及兴趣相关的邮件建一个文件夹。

3在邮箱里检索与前两个文件夹匹配的邮件，再把它们放到相应文件夹里。

4浏览一下特殊文件夹，用单件流方法把90%的邮件清除。

现在，你走上正轨了。

似曾相识——一次又一次

布赖恩总是搞砸工程创建。你可以对布赖恩实施惩罚，直到他害怕了经常检查代码。但只是这样做的话会产生其他问题。

一个较好的办法是给布赖恩一个核对清单。人们普遍误解了核对清单，致使开发利用不当。遗憾的是，在布赖恩把代码集成到创建里之前，善意、顶真的人会把所有的东西都放到他要核对的单子里。这不仅浪费时间，而且没效率。

布赖恩的核对清单应该只保留引起创建失败的一般性问题（最好少于一页）。这样在布赖恩提交代码的时候一眼就能看明白。这样目标实现起来就会很快、很简单而且有效率。

太长或太复杂会让布赖恩搞混，太短也会没效率。幸运的是，大多数错误都是一般性的。因此，所有的团队应该做的是收集引起创建失败的一般性或至关重要的问题，再把它们放到核对清单里。这对设计复审清单、代码复审清单以及所有核对清单都是一样的。

记住，在你改变失败的设计模式时要更新你的核对清单，不然它们就走味了。核对清单防止了一般性错误的发生，而且有利于养成好的习惯。一些你所采用的结构化的、自定义的过程都应该有一份简单的核对单——除非你想象布赖恩一样搞砸工程创建。

作者注：你或许会在决定什么应该放到核对清单里存在思想斗争。你不应该这样。记住，你是要把一般性的或至关重要的问题放到清单里，而不是所有一切发生过的问题。

举个例子，几个月前我将核对清单附到了我的E mail签单里，我发出了每封邮件。核对清单里我只列出了几年来我一直在犯的两个错误，但现在一直没有犯了。

检查一下抄送与隐藏抄送名单是否准确。

检查一下标题是否正确。

第三章 根除低下的效率