第三章 团队开发与管理
这里团队从人数上来说至少是三个人，但这并不是固定的，团队的基本特性是主从、监督和责任。这时首先就要选个领导了，这里有很深的学问，领导不一定是技术最好的、最全面的，但一定是最有大局观、最能调动大家的积极性的！最重要的要能管理好这个团队，能承担团队的责任，虽然不说项目失败了就要掉脑袋，但是项目经理的责任就是最大程度的避免失败。项目工期的问题不能解决，就不能保证项目成功。只有经验更加丰富，才能更尽可能地逼近“合适的工期”。因此在此之前，项目经理面临的就是失败。这个失败可能不是项目经理本身能力所决定，或者也不是团队成员的工作所决定，而是在一开始，那份给客户的项目协议就签错了。项目经理是需要时间来成熟的。他需要有机会来承受错误，而不是一开始就享受成功。
体制的内涵是分两个方面的，其一是“体”，即“体系”；其二是“制”，即“制度”。“ ISO质量体系”所产生的那份手册只是“制度”，在它的背后，所要求的是对旧有“体系”的改变。皮之不存，毛将焉附。只有建设好健全的体制，才能更好的管理。动摇了制度的人不是犯错的员工，而是管理者自己。最好的方法是赶紧修订制度，而不是修理人。
我们要认清自己在团队中的角色，对于团队项目中的任务我们要采取认领而不是分配的则。是“部门经理”还是“开发人员”，这个还是要认清好角色的。在开发经理和开发人员之间，既存在主从关系，也存在协作关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。
跟随蚂蚁。但不要栽进蚂蚁洞里。明确分工是你的管理职责。做管理≠做伯乐。
第四章 流于形式的沟通
做项目之前首先要做的就是和客户进行有效的沟通，把客户的需求的了解的更加深入详细。但这一般不是程序员去做的，而是项目经理。因为程序员沟通时总会把用户当成计算机来打交道，希望用户会编程语言，然后他们用对普通用户来说高深莫测专业术语来进行交流，用户听不懂，程序员更是着急，不一会就得拍屁股走人。因此保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
第五章 失败的过程也是过程
很多人把问题的本质给忘掉了。从最开始，从我们编程开始，我们的目的就是实现一个东西。无论这个东西是小到一个称手的工具，还是一个大到千万的工程，我们的目标，都是要“实现”它。过程不是死模型 ，要具体问题具体分析，懂得灵活变通。否则得不偿失，既费时费力又得不到好的效果，这又是何苦呢？要想不拘泥于模型，就要对模型的本质有深入的了解，知道它每一步过程方法，而不仅仅是拘泥于表面现象。越是简单的东西，往往越是接近于本质。能“做”工程，而是要“组织”工程。项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目。