《人月神话》（P7）编写手册和组织开会

贯彻执行

本章讨论的问题是结构师如何确保每个人听到、理解并实现他的决策？

文档化的规格说明——手册

手册是结构师的主要工作产物，它描述和规定了用户所见的每一个细节。规格说明总是不断的在修改，所以也应该具有版本信息。规格说最重要的是清晰、完整和准确，所有文字要相互一致，这比写的生动要重要的多，所以说明往往都比较枯燥。如果说手册有专人编写，那么必须由一个或两个人来完成，以此保持文字和产品的一致性。而且一定要重视这些琐碎的事情，因为很可能失之千里差之毫厘。

形式化定义

整个手册需要同时包含两种记叙方式，形式化定义和记叙性定义，形式化定义为主，记叙性定义为辅。形式化定义是精确的，倾向完整的，但是却不那么好理解。记叙性文字可以提供实例，强调对比关系，以及解释原因。另外，形式化定义仅仅用于外部功能，说明它们是什么。

使用实现来作为一种定义方式是有优点的。首先问题可以通过测试得到清晰的答案，其次对于需求总是实现的比较精确。但缺点也是明显的。实现可能过度的规定了外部功能，可能会遗漏很多与实现共生的副作用。因此，当遇到尖锐的问题时，实现有时会给出未在计划中的意外答案，这些答案都是粗糙的，从来没有被仔细考虑过的。

会议和大会

这一节说到，允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布，当然也可以用邮件的形式。结构师还有个义务就是组织大家开项目例会，任何人都可以提出问题和意见，但主持人和决策者是结构师。在会议中，重点是创新，而不仅仅是结论，小组应该试图找到解决问题的各种方法。需要注意的是，作者提倡在会议之前，以书面的形式呈递项目中出现的问题，以此提高会议效率。

这种会议是很高效的，首先每个人都密切参与，当问题出现时同时寻找解决方案，其次明确的授予了熟悉结构师决策的全力，避免了妥协和拖延。

产品测试

项目经理最好的朋友就是他每天要面对的对手——独立的产品测试机构（小组）。每个开发机构都应该有这样一个独立的技术监督部门，来保证其公正性。

最后还提到，测试小组也是客户的代言人之一，不时的也会发现一些没有贯彻执行，或者正确理解的地方。换而言之，测试小组也是使得设计可以保持一致性的必要手段，所以也应该尽早着手，项目初期就开始测试。

以上是《人月神话》第六章——贯彻执行的全部内容

本章描述了结构师的工作内容和责任所在，和上一章比起来责任内容显得更加的具体。结构师是管理人员，但他本身的工作却很繁多，不是那种光动动嘴皮子就能完成的工作。工作包括制定和维护一份精确的手册，组织开会完成决策，以及协调测试人员。总感觉还缺点什么，可能作者准备在下一章会继续补充结构师的职责吧。

其实结构师和现在产品经理、程序主管的工作都有不少相似的地方，在当时那个年代，就已经产生了类似的观念，是在是不容易呢。