阅读了《大道至简》的第五章，这章在前面的基础上又进了一步，有了技术和团队，加上有效的沟通，接下来就要接项目做工程。
做工程不是做过程，书中为我们举出了一个有意思的图片，图中每个人都有自己的任务，每个人都做自己的事情，但是最后的工程和想要的相差甚远。这是个讲沟通的经典例子，但是用它来说明工程也是很合适。按照模型的这个样子，做完过程的每一个阶段， 并不等于做工程。或者说，工程并不是这样就可以做成的。 无论是用 RAD 模型还是 RUP 模型来做工程，即使是亦步亦趋，也做不好工程。虽然用瀑布模型开发的过程分成需求、分析、 设计、开发和测试等 5 个主要阶段，从实际工程中提炼出来是值得称道的，但是，这样的工程如果只是为工程而工程也不会有结果。
做工程的本质其实是结果。无论是一个小东西还是一个大工程，我们一开始的目的就是要实现它。为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD 之间的区别的人，可以把每一个过程的流程图都画出来， 却也被这每一个流程给捆绑得死死的。
接下来，书中讲了关于过程的模型，从瀑布模型到各种经典的模型。瀑布模型描述了开发的主要环节，于是一群人把这些环节拧来扭去或者反复迭加，就成了 RAD、螺旋、RUP。作者在CSDN 论坛中看到一个漂洋过海东渡扶桑的取经人，贴出了一个被称为“日本 IT 工业发展史的活字典”牛人指点的“V 字型模型”。其实实质上这也是瀑布模型，但是这是因为日本近年来老龄化严重，因此劳动力短缺导致的劳工输入和项目外包，直接影了它的组织管理模式。无论是在本国雇佣外来劳工，还是将项目直接外包给国外的开发团队，项目成果的阶段性考察都是他们的第一要务，这直接决定了何时、如何，以及由谁来进入下一个环节。 因此 V 模型变得比其它模型更为实用。模型的左端是外包给的团队或者公司，而右端则是日本软件企业中有丰富经验的工程人员。这样既节省人力，又可以保障工程质量。事实上，即使左端外包方是由多个团队同时承接， 右边的工程人员也不需要更多的投入。 而我们学到的只是他们的一种模式，而不是随机应变的方法。
最后书中告诉了我们做工程正确的方法，做工程不是蒸馒头，有模子，照着做出来就可以的。做过工程的人知道，项目是组织的，而项目经理的工作，就是要去组织这个工程中的各个角色， 使得分工明确，步调一致，共同地完成这个项目，这样一个工程才能实现。