第三章 根除低下的效率

    规范书基本上都是可怕的。不仅仅指项目管理规范书，而且也包括开发规范书和测试规范书。我说的“可怕”，主要是指难以撰写，难以使用，而且难以维护。你要知道，这很可怕！规范书往往还是不完善的，组织得很差，并且没有得到充分的复审。规范书永远都是这个样子，也看不到有任何变好的迹象。

    为此，我想要指责项目经理，部分原因是因为我喜欢这么做，但更主要的还是因为他们是糟糕规范书的始作俑者。然而，事实不允许我指责项目经理。人人都在写糟糕的规范书，而不只是项目经理。即使项目经理偶尔写出了上好的规范书，但其他大部分的还是很糟糕的。不管谁来写，上好的规范书总是难以撰写和维护的。

    如果项目经理不该为那些以次充好的规范书承担罪责，那么该指责谁呢？管理层将是最直接的目标（另一群我喜欢指责的人）。事实上也是，有些组织，比如Office部门，一贯以来写的规范书都比其他部门的要好。因此，管理层显然在其中发挥着作用。然而，Office部门这么多年来调换过很多次管理层，因此，这里的原因必定比主管的人更加深层次。

    树立靶子

    现在清楚了，我应该去指责写规范书的过程——我们是怎么写规范书的，以及我们使用什么工具。这个过程是烦琐、艰难并且乏味的。规范书模板冗长、吓人，复杂到无法驾驭。所有这一切使得要写成一份上好的规范书，比披着皮大衣、穿着拖鞋想要去赢得一场马拉松比赛还要无望。

    一些落后于时代的杞人忧天者可能会说：“写规范书的过程如此荒谬紊乱是有原因的。所有的模板元素和过程步骤都是用来避免以前发生过的灾难的。”看到了吧，你不必去担心从公司高层传达下来太多的官僚主义，其实，在下面的基层已经自己累积了很多。

    病态的过程总是源自于最好的意图。麻烦出在，这一路走来，最初的目标和意图都不知不觉地迷失了。唤醒这个目标和意图，使用新的、更好的方法去实现将会使它们重归正途。

    作者注：我在波音公司工作了5年。在那里，不是所有但绝大部分官僚主义看起来都来自于公司高层。我已经在微软工作了12年。在这里，不是所有但绝大部分官僚主义看起来都来自于基层。我们在最底下的层次，工作独立，很自由。有时，这意味着我们这是在作茧自缚。

    沟通分解

    所有项目管理、开发和测试规范书的目标，都是为了跟不同时间、不同地点的人进行设计和设计决定的沟通。我们想要使这种沟通变得容易而稳健，并且进行大量的反馈和质量检查。

    假设你还没注意到，这里有4个独立的要求：

    ·容易

    ·稳健

    ·反馈

    ·质量检查

    每个要求都可以通过一个不同的解决方案来满足。“我们只需在规范书中多加几节来满足所有的要求”，这种方法跟“我们只需给这个类多加几个函数来实现所有的功能要求”一样的愚蠢。我们还是对这些要求逐个来分析吧。

    保持简单容易

    规范书必须要容易写，容易懂，并且容易维护。它应该使用标准的符号（比如UML）来绘制图表，使用通用的术语用于文字表达。它不应该承载太多的内容或者说得过于深入。

    格式越简单越好。在“工程卓越手册”（Engineering Excellence Handbook）中的通用规范书模板有30节之多，并且还有3个附录。而上好的Office规范书模板也有20节。它们都太复杂了！

    一份规范书只需要3节，再加上一些元数据：

    需求：为什么会有这个功能？（跟应用范例和客户角色联系起来。）

    设计：它怎么工作？（图片、动画和图表特别有用。）

    问题：做了什么决定？风险和权衡都有哪些？（比如依赖关系。）

    元数据：标题、简短描述、作者、功能团队、优先级、成本和状态等。

    就这些了！“状态”元数据可以是个工作流，也可以是个检查清单，但不能太复杂。

    “但威胁模型放在哪里？还有隐私声明呢？源代码插桩或者性能度量呢？”我可以肯定你会提出这些要求。请你冷静一下！这些条目属于质量检查，我在后面很快就会谈到。规范书结构本身是简单的，比实际需要的多一点或少一点都不行。这样才能容易写，也容易被人读懂。

    在线资料：规范书模板（Spec templatedoc）。