这一章主要讲了过程与工程的关系。由于我经验尚浅，并没有实际接触过工程，所以对书中的一些道理似懂非懂。文章开头的一张描述交流问题的图片编足以说明前两小节的中心。从客户的手里接到一个工程，虽然按照经典的模型将这个工程划分为一个一个过程，然后分别交给不同的人来完成。这看起来并没有什么不合理。然而第二小节就指出了在实际应用中出现的问题：那就是每个过程中的工作人员都只是在走过场，并没有竭尽全力做完做好要求的工作，只是在生搬硬套那些优秀的模型，却没有理解这些模型背后的精髓。
为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD之间的区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的， 再也没有挣扎一下的力气。
第三小节的标题非常直接——实现才是目的。作者非常直接地指出，软件工作人员大多数都在舍本逐末，一味地追求各种模型，却忽略的最核心的目的，也是最初始的目的——实现客户的目的。
第四小节——过程不是死模型，更是深刻的说明了这个观点。把一个复杂庞大的工程划分为一个一个的小的过程然后一一实现这本没有什么错，而且是非常正确的。但是目前的情况是，软件工程的工作人员已经思维僵化到只会生搬硬套这些模型，却忘记了最核心的目的。一个个优秀的模型原本是经验丰富的公司或团队在实际工作中慢慢总结出来，用来帮助我们更好地完成工作的，但是现在软件工程人员的生搬硬套导致这些原本用来帮助我们的优秀模型反而成为了束缚我们的枷锁，成为了我们在做过程中沉重的负担。
第五小节和第六小节主要讲了“空架子”和“实质”的关系。这个我并没有怎么看懂，但是大约知道作者的意思应该是说，在工程中到底要使用哪种模型，一定要在理解各种模型的实质和精髓的基础上，结合实际情况选择合理的解决方案。切忌只为一个空壳子，花架子而一味的追求贴合某一个并不符合时间的模型，反而丢失了最重要的精髓
工程不是做的，是组织的。这个比喻很浅显易懂。这一小节就是说明一个优秀的项目经理应该做的事情——合理分配组织工作，使得一个小队能齐心协力完成工程。
所以我们当然不能“做”工程，而是要“组织”工程。项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目
