使用，而且难以维护。你要知道，这很可怕！规范书往往还是不完善的，组织得很差，并且没有得到充分的复审。规范书永远都是这个样子，也看不到有任何变好的迹象。
为此，我想要指责项目经理，部分原因是因为我喜欢这么做，但更主要的还是因为他们是糟糕规范书的始作俑者。然而，事实不允许我指责项目经理。人人都在写糟糕的规范书，而不只是项目经理。即使项目经理偶尔写出了上好的规范书，但其他大部分的还是很糟糕的。不管谁来写，上好的规范书总是难以撰写和维护的。
如果项目经理不该为那些以次充好的规范书承担罪责，那么该指责谁呢？管理层将是最直接的目标（另一群我喜欢指责的人）。事实上也是，有些组织，比如Office部门，一贯以来写的规范书都比其他部门的要好。因此，管理层显然在其中发挥着作用。然而，Office部门这么多年来调换过很多次管理层，因此，这里的原因必定比主管的人更加深层次。
现在清楚了，我应该去指责规范书过程——我们是怎么写规范书的，以及我们使用什么工具。这个过程是繁琐、艰难并且乏味的。规范书模板冗长、吓人，复杂到无法驾驭。所有这一切使得要写成一份上好的规范书，比披着皮大衣、穿着拖鞋想要去赢得一场马拉松比赛还要无望。
一些落后于时代的杞忧者可能会说：“规范书过程如此荒谬紊乱是有原因的。所有的模板元素和过程步骤都是用来避免以前发生过的灾难的。”看到了吧，你不必去担心从公司高层下来太多的官僚主义，其实，在下面的基层已经自己累积了很多。
病态的过程总是源自于最好的意图。麻烦的是，这一路走来，最初的目标和意图都不知不觉地迷失了。唤醒这个目标和意图，使用新的、更好的方法去实现将会使它们自动现身。
作者注：我在波音公司工作了5年。在那里，不是所有、但绝大部分官僚主义看起来都来自于公司高层。我已经在微软工作了12年。在这里，不是所有、但绝大部分官僚主义看起来都来自于基层。我们在最底下的层次，工作独立，很自由。有时候这也意味着，我们被授予了足够的绳子用于勒死我们自己。
沟通分解
所有项目管理、开发和测试规范书的目标，都是为了跟不同时间、不同地点的人进行设计和设计决定的沟通。我们想要使这种沟通变得容易而稳健，并且进行大量的反馈和质量检查。
假设你还没注意到，这里有4个独立的要求：
？ 容易
？ 稳健
？ 反馈
？ 质量检查
每个要求都可以通过一个不同的解决方案来满足。“我们只需在规范书中多加几节来覆盖所有的要求”，这种方法跟“我们只需给这个类多加几个函数来实现所有的功能要求”一样的愚蠢。我们还是对这些要求逐个来分析吧。
txt小说上传分享
保持简单容易
规范书必须要容易写，容易懂，并且容易维护。它应该使用标准的符号（比如UML）来绘制图表，使用通用的术语用于文字表达。它不应该承载太多的内容或者说得过于深入。
格式越简单越好。在“工程卓越手册”（Engineering Excellence Handbook）中的通用规范书模板有30节之多，并且还有3个附录。而上好的Office规范书模板也有20节。它们都太复杂了！
一份规范书只需要3节，再加上一些元数据：
？ 需求：为什么会有这个功能？（跟应用范例和客户角色联系起来。）
？ 设计：它怎么工作？（图片、动画和图表特别有用。）
？ 问题：做了什么决定？风险和权衡都有哪些？（比如依赖关系。）
？ 元数据：标题、简短描述、作者、功能团队、优先级、成本和状态。
就这些了！“状态”元数据可以是个工作流，也可以是个检查清单，但不能太复杂。
“但威胁模型放在哪里？还有隐私声明呢？源代码插桩或者性能度量呢？”我可以听到你在提出这些要求。请你冷静一下！这些条目属于质量检查，我在后面很快就会谈到。规范书结构本身是简单的，比实际需要的多一点或少一点都不行。这样才能容易写，也容易被人读懂。
在线资料：规范书模板（Spec ）。
变得稳健
规范书必须是稳健的。它必须是可被验证的，并且所有定义的功能需求和质量需求都能被满足。你可能会问，“怎么做到？！”但你说“怎么做到？！”究竟是什么意思？怎样在第一时间验证需求？那就要编写测试，对吗？对！这就是你怎么写出一份稳健的规范书的方法。在规范书的第一节中，当你列出功能和质量上的需求时，应该包含如下内容：
惟一标识 优先级 功能或质量 简短描述 相关应用范例 用于验证需求的测试
如果你不能指明一个测试来验证一个需求，那么这个需求就不能被满足，因此要把需求丢弃。不能丢弃？那好吧，重写需求，直到它能被测试为止。
作者注：我相信，一个可靠的设计把“测试”和“需求”放在基本同等重要的地位。每个需求都应该有一个测试。每个测试都应该基于一个需求。这将导致：清晰而可被验证的需求；更加全面的测试；一致的完成标准（即所有测试通过等于所有需求得到了满足）；以及更好的设计，因为测试驱动的设计自然要更加简单，更加内聚，具有更松的耦合。
书包 网 。 想看书来
获取反馈
在规范书付诸实现之前，越多的眼睛看到它，它就会变得越好，并且将来要求的返工也会越少。如果你想很容易就能获得反馈，你也想别人很容易就能提出反馈，至少你要将规范书草稿放到SharePoint上，并进行变更跟踪和版本控制。做得更好一点，你可以把规范书放到一个维基站点上去，或者贴在功能团队主要活动区域的一块白板上。
撰写规范书的这个过程、反馈和变更管理需要有多正式呢？像我在前一个栏目讨论的那样（即本章的“停止写规范书”那个栏目），正式的程度取决于沟通是否直接，以及沟通的“带宽”有多大。在同一个共享区域、同一个时间、工作在同一个功能的人们，他们可以使用很不正式的规范书和过程；而在不同时区、不同时间、工作在不同功能的人们，他们则必须要有高度正式的规范书和过程。
不管怎么样，你想让规范书随时都可以修改，直到团队认为它不需要再改为止。那你怎么知道规范书不需要再改了呢？答案是，要等到测试团队验证规范书通过了所有的质量检查。
集成质量检查
这是我们目前正在使用的规范书最离谱的地方。各个部门不是把安全、隐私和许多其他问题当作质量检查，而是把它们一节一节单独地写在了规范书中。这是个灾难，原因是：
？ 规范书变得更大并且复杂得多。
？ 作者必须在各节中复制信息。
？ 读者对后面的节次重视不够，导致严重的质量缺口。
？ 设计变得难以理解，因为它们的描述分散在多节之中。
？ 错误和缺口很容易被忽略，因为没有一个节次对设计作了完整的描述。
？ 更新几乎是不可能的，因为一个最新的改动会影响多个节次，牵一发而动全身。
取而代之的是，采用适合于每一份规范书的质量检查，它以一个清单的形式出现，并且每个人都能触手可得。一开始的几个检查对于每个团队都是一样的：
？ 需求清楚、完整、可验证、并与有效的应用范例关联了吗？
？ 设计满足了所有的需求吗？
？ 所有关键的设计决议都被解决并存档了吗？
接下去的一套质量检查也相当基本：
？ 所有的术语都被定义了吗？ ？ 有没有兼容性问题？
？ 安全问题解决了吗？ ？ 故障和错误处理解决了吗？
？ 隐私问题解决了吗？ ？ 谈到安装和升级问题了吗？
？ 用户界面完全可达到吗？ ？ 维护问题解决了吗？
？ 为全球化和本地化准备好了吗？ ？ 备份和恢复问题解决了吗？
？ 对于响应和性能的期望是否清楚并可测量？ ？ 是否有足够的文档用于支持故障检修？
？ 源代码插桩和可编程能力定义清楚了吗？ ？ 有没有潜在的问题会影响打补丁？
各个团队还可以为他们自己或者他们的产品线增加更多的质量检查，解决他们常常面临的特殊的质量问题。
在线资料：规范书检查清单（Spec ）。
这里的关键是，设计节次对功能进行了完整的描述，而质量检查保证了没有东西被遗漏。是的，这意味着设计节次可能会变得非常庞大，以覆盖所有需要涉及的领域。但这些领域不再是把功能按照每一个质量要求展开的累赘品（比如对话框的安全、对话框的隐私、对话框的可达到性等）。
取而代之的是，所有的领域将是功能的逻辑组成部分（比如应用程序编程接口、对话框、菜单等）。重复消除了。每个功能组成部分完整地被描述出来，并且所有的质量要求都融合在了设计情境中。
作者注：一个奇怪而有趣的巧合：在本栏目发表之后的第二天，Office部门把他们的规范书模板做了简化，只使用单独的一个节次来描述设计，并且采纳了我发布的质量检查清单。尽管我不能对这个改变邀功，但我的成就感着实得到了满足。
书 包 网 txt小说上传分享
差别在哪？
如果增加了所有的这些检查和测试，你可能会怀疑我根本就没有对规范书作出简化。其实，这里的最大改动是：
？ 节次的数量减少到了只剩下3个（需求、设计和问题）。
？ 设计在一个节次中得到了完整的描述。
？ 所有功能和质量上的需求都可以被验证。
我也已经谈到了，我们还有机会把规范书写得不那么正式一点，并且更容易被理解。
那么谁该为糟糕的规范书负责呢？其实我们都有责任。不过，糟糕的规范书主要还是由不良的习惯和糟糕的工具造成的。只要做一些小小的改变，并且使用大大简化的模板，我们就能改进我们的规范书，改善部门之间的沟通，并且促进工种之间的关系。总而言之，这样做可以让我们在微软工作得更加开心而富有效力。
第9章
成为管理者，而不是邪恶的化身
本章内容：
2003年2月1日：“不只是数字——生产力”
2004年9月1日：“面试流程之外”
2004年11月1日：“最难做的工作——绩效不佳者”
2005年9月1日：“随波逐流——人才的保持和流动”
2005年12月1日：“我能够管理”
2006年5月1日：“不恰当的比较——病态团队”
微软文化中有这么一部分：“不要抱怨任何事情，除非你已经为它找到了建设性的改进意见。”没错，我常常抱怨我们的管理层。更糟糕的是，我在这个公司的12年时间中有8年是在做管理者。“那你对管理者的改进有什么建设性的意见呢？”很有趣，你应该这么问。
如今，新任的管理者可以得到相当多的扶持，但是当我第一次成为一名主管的时候，我与以前的管理者共事的经历成为了我惟一的资本。我做得还行，不过我也从工作中和我的导师那里学到了大量的东西。5年之后，我加入了现在的这个组织。给新任主管和经理提供我曾得到过的有效而具体的帮助，成了我工作中头等重要的事。I。 M。 Wright写的关于管理的文章中，很多都直接来自于我为新任管理者准备的资料。
在这一章中，I。 M。 Wright论述了如何进行有效的管理，而不必让你成为恶魔。第一个栏目教导管理者要合理使用度量，并指出了一名卓越工程师所具有的特征。第二个栏目谈到了面试和招聘。第三个栏目带你一起走过了管理绩效不佳者的敏感地带。第四个栏目涉及到了人才的保持和流动。第五个栏目揭示了成为一名优秀管理者的最低要求，以及如何才能从优秀提升到卓越。最后一个栏目传授了把一个病态团队变得健康而富有生产力的秘方。
坦率地说，我从来就没想要成为一名管理者。我已经做了17年成功的个体贡献者和架构师。我最后成为管理者，是因为我对产品有一些自己的想法，我想了解如何去运转起一个业务。令我惊讶的是，我发现管人比编程更加让我着迷和满足。也许其中的部分原因是我当上了爸爸——养育一群孩子跟发展一个团队在很多方面是相似的。但更主要还是因为跟人相比，电脑是可预测的、死板的。哈，当然，电脑能够给你带来惊喜和快乐，但那个程度还达不到人给你带来的。我仍然热爱编程，不过我发现跟人打交道要更加有益得多。
——Eric
小心你希望得到的东西
2003年2月1日：“不只是数字——生产力”
只有我是这样吗，还是外星人接管了我们所有管理者的大脑，让他们深信，数字能够精确地代表一个产品的质量或者一个开发者的价值？我们到底还要忍受多少令人作呕的数据收集、分析和预测，才能让那些被误导的管理者得到足够的满足，以使他们不再来打扰我们、让我们能够做自己的工作？如果我们能够集中精力在编码上面的话，我们其实能够完成比现在多得多的工作，难道只有我一个人内心深处有这种感觉吗？
不过，目前的趋势是，对我们创作的东西及其创作方式做越来越多的“度量”，并且使用这些度量去判断我们产品的优点——还有人的优点。似乎解放我们的大脑是有益的。你是否意识到，有多少自作聪明的管理者靠“编码成功度量”给团队成员评分，然后很轻易地就对他们判断最正确的人放马后炮？
作者注：《Interface》的编辑要求我写一篇关于度量的文章。我不认为这就是当初他们脑子里想要的东西，但最后期限摆在那里，我也交出了他们规定字数内的文字。
《Interface》上的文章是“度量开发者的生产力”，它很