软件项目的要求：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。
这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目经理给出了实实在在的操作步骤。在刚开始的时候APP我们就开始做需求分析，弄了一个Word文档去设计那一部分是什么，需要有什么功能，还专门用一节课的时间做了PPT去讲解我们这个软件的主要功能跟设想实现什么功能；对于我们来说，这个app也是一个小型项目，但是我们也有自己的目标用户手册，内部文档进度预算。都写在自己的博客里面，还有每天的进度，都是在自己的博客里面进行分析。
对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。 软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。目标和开发策略上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。 对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。 维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。 缺陷修复总会以（20－50）%的机率引入新的bug。 在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。 同样，设计实现的人员越少、接口越少，产生的错误也就越少。所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程。
由于我们是每个人负责自己的那一部分。而现在这种情况，大家都在自己的家中。每个人和每个人的软件配置都是不一样的。所以当导入别人的项目的时候，会出现很多的错误。导致我们很多时间都在用来解决这个错误，分散了精力。而且我们这个，带来的用户体验也就没有了那么好。当我们开始做这个项目的时候，就会预想到哪一部分是比较难实现的。这也就是未雨绸缪。认识到自己所处的现状，发现自己的不足，然后再去学习。
一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。每一天的工作进度都会发在博客里面，如果今天没有工作，当我们在发表博客的时候就会显得格外的艰难。然后还得想办法去弥补上这个错误，会给我们的第二天增加很多的负担。当我们在博客里面写下我们所没有做的事情来说，就是在弄虚作假。但是对于我们的app来说更是很难弥补的。
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。