本周继续阅读《人月神话》，本周度过的部分是第十章和第十一章（“提纲挈领”和“未雨绸缪”），以下是对该两章的感想。
一、提纲挈领
提纲挈领一章描述的是经理与文件的关系。作者一开始便给文件做了定性：文档的某些部分包含和表达了一些管理方面的工作，其准备工作是集中考虑并使各种讨论意见明朗化的时刻，其跟踪维护是项目监督和预警的机制。
作者通过“计算机产品的文档”、“大学科系的文档”和“软件项目的文档”，来阐明文档如何展开上述工作。
我们可以看到，所有的文档都包含的项目是以下几个：目标、机构分类、技术要求、时间表、预算。这几项几乎包含了一个工程中所有的管理要素。
文档的必要性在于它的三个具体角色：书面决策、沟通渠道和数据基础与检查列表。第一项使得工作规范化、工作目标清晰化（目标、机构分类、技术要求），第二项使得决策被团队成员所知晓，而第三项则可以让经理对项目所处的状态有一个大致的了解（时间表、预算）。
二、未雨绸缪
未雨绸缪的英文是“Plan to Throw One Away”，因此这个中文翻译不太恰当。实际上这一章讲的是，应该实行实验性开发，并且随时做好丢弃原本成果的准备，而不是把第一次开发所得的产品提交给客户去使用。
实际上对于大多数项目，第一次开发的系统很有可能是太大、太慢或者是难以使用的，且新的技术和概念的产生很可能使已有的系统开发出来就已经过时。解决办法简单粗暴——从零开始，设计一个更灵巧、方便、小巧的系统。但是实际上，在开发之前，这些问题是无法得到解决的，毕竟项目经理不能未卜先知。
因此，这个问题变成了“是否抛弃原型，亦或将原型直接发布给客户？”，对此，作者的结论是“为舍弃（变更）而计划，无论何时，都一定要这样做”。
如何变更计划系统呢？作者描述的不多，而唯一被强调的一点是：使用高级语言和自文档技术，以减少变更引起的错误。
变更引起的问题，最大的一点就是BUG，而维护系统、修复BUG的过程，被作者形象地称作是“前进两步，后退一步”，因为维护系统消除BUG之时，会以20-50%的几率引进新的BUG。而解决方式则是，使用能消除、至少是能指明副作用的程序设计方法，且尽可能使用较少的人员和接口。
