此章的核心是执行，并给出了大型团队（~1000人）的例子，供我们参考。但中小团队又该如何呢？
规格文档
这是PM、PD的主要产物，文中的描述是：
手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节。
同时给出了修改时的建议
规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。然而对实现人员而言，修改的阶段化是很重要的——在进度表上应该有
带日期的版本信息
文档必须非常的细致和精确，同时不要约束实现人员，我认为前提还得是要遵循设计的一致性
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准一种实现方法，但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要
形式化定义
关于这一节，我认为书中观点是： 统一一份约定； 避免在某些概念上的歧义；
会议是第一生产力
例会的级别
我们把会议分成两个级别：周例会和年度大会——这实际上是一种非常有效的方式。 后面还提到 年例会可以一年举办两次
会议需要有纪要，特别是修改需要书面形式。如果意见一致固然很好，如果不一致，首席需要拍板。
好处
- 数月内，相同小组——结构师、用户和实现人员——每周交流一次。因此，大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
- 上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
- 当问题出现时，在界线的内部和外部同时寻求解决方案。
- 正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致。
- 清晰地授予首席结构师决策的权力，避免了妥协和拖延。
年会 （仅大项目可行）
随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。对于这些问题，有时周例会没有重新考虑，慢慢地，很多小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题，我们会举行年度大会，典型的年度大会会持续两周。
出席人员包括体系结构小组、编程人员、实现人员的结构代表，同时包括编程经理、市场和实现人员，由项目经理``主持。
每个人都在倾听，每个人都在参与，每个人对复杂约束和决策之间的相互关系有了更透彻的理解。
会议外沟通
文中建议沟通都要留档，这样方便复盘（甩锅~）