这段时间阅读内容较少，只简单阅读了《人月神话》一书的6-9章。这一段的内容比较前几章专业性明显加强，江苏了很多关于项目的空间和时间安排的一些细节问题，引起我的兴趣的是“提纲掣领”这一章的内容。这一章述说了关于项目中的文档的一些情况。技术、周边组织机构、行业传统等若干因素凑在一起，定义了项目必须准备的一些文书工作。对于一个刚从技术人员中任命的项目经理来说，这简直是一件彻头彻尾令人生厌的事情，而且是毫无必要和令人分心的，充满了被吞没的威胁。但是，在实际工作中，大多数情况都是这样的。计算机产品的文档、软件项目的文档，按照书中所说，他们的最终成文未必最为重要，最重要的是成文过程中大家一起沟通得出了所有人都认可的结果。书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到 清晰、确定的策略。另外，项目文档也起到了减少无用重复沟通的过程，很多时候，一些事情会被程序员遗忘，他们不得不再次向项目管理者询问，这一过程很容易产生误导性分歧，而如果将项目文档书面化，能大大改善这一点。

下面是阅读总结：

在以往的学习中，我和很多同学因为没有接触过大型项目，没有书写项目文档的习惯。虽然在学习UML之后我们已经开始有这个意识，但是在实际执行中，却因为嫌麻烦等原因放弃了构建文档这个过程，这对我们习惯的培养是非常不利的。在上一篇中，我也提到了关于项目文档的内容，

书中给出了如下的格式需要：

做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。

做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。

时间：进度表

资金：预算

地点：工作空间分配

人员：组织图。

今后的团队合作，在开始时，我也要向书中所描述的一样——从商讨结构的会议开始，然后开始书写代码。不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。接着，他会和其他管理人员一样要求各种文档。