第三章 团队缺乏的不只是管理
项目开发过程中，三人以上的团队要分清楚各自的职责，功劳多的可以大大的奖赏，但是项目失败了，要有人站住来承担责任。
项目的完成有两个测量标准，一个就是时间，一个就是质量。软件开发的时间是谁也不能够保证的，在开发初期定的时间标准会随着软件开发的过程改变，那么时间的问题只能是更加的准确到某一个时间，谁也不会甚至不能说确保的那一天就完成了这个项目，话说回来，项目经理最一开始可能就会面临失败。
公司的转型不是一件容易的事情，首先要改的就是组织机构，没有组织机构就没有制度的建设，皮之不存，毛将焉附。
程序开发之前，我们要确定好制度，没有制度，就没有规范，没有规范就会造成混乱。最中可能会导致项目的失败。
第四章 流于形式的沟通
沟通不能是一种形式，沟通要有目的性，没有目的性的沟通只会浪费时间，而且更要注意的是流于形式的沟通可能是使得你的项目被不断的推翻和不断的延误的直接原因。
沟通问题不仅仅存在于与客户交流之中，还存在于与项目的各个角色之间。UML的确是解决沟通问题的最佳手段之一。但只要是行之有效的、能在各个项目角色之间通用的，就是好的沟通方式。
沟通作为一种渠道，是软件公司与客户之间达成一致的有效手段，但是沟通要有正确的方法，客户不懂得什么是UML，不会用C那么你就不要用这些来与客户进行沟通，不管是你用到什么沟通方式，什么沟通工具，或者语言，沟通的目的是要明确的，要更好理解客户的需求。
沟通还要注意效率性，要进行有效的沟通，客户不想你总是骚扰人家，见面的时候一定要注意沟通的效率性。
第五章 失败的过程也是过程
瀑布模型将软件开发的过程分成需求、分析、设计、开发和测试5个阶段。
工程只是实现的一种途径。否则，我们做完了工程的没一个过程，却没有完成项目的每一个“实现目标”。
过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需，因地制宜，择善而从了。
越是简单的东西，往往越是接近与本质。
项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同完成这个项目。