在这次的阅读中，我重点阅读了祸起萧墙（Hatching a Catastrophe）这一章节。
一、书中说到，往往重大的灾害都是比较容易处理的，因为它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。
“但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。”
所以说我们应该时刻保持高精度的目光，以可以敏锐的发现团队和技术上的小错误。
二、好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出合理要求的一项服务，而不确切的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会彻底碾碎小组的士气。慢性进度偏离同样也是士气杀手。
对计划和控制职能进行适度的技术人力投资是非常值得赞赏的。它对项目的贡献方式和直接开发软件产品有很大的不同。计划和控制小组作为监督人员，明白地指出了不易察觉的延迟，并强调关键的因素。他们是早期预警系统，防止项目以一次一天的方式落后一年。
读完这一章节，最大个感悟就是：最大的破败往往是最不易察觉的！也让我开始思考如何才能提升自己对软件开发过程中的问题的敏锐的发现能力。