今天读了大道至简的第四章——流于形式的沟通。通过学习这一章的内容，我知道了沟通在完成一个项目的过程中必不可少，而如何进行合适有效的沟通，这一章给了我们明确的答案。
第一节：客户不会用C，难道就会用UML吗？这一节主要是说我们作为程序的开发人员，总是要首先接触客户的，这样我们才能知道要做什么。当然我们肯定希望客户学习过C语言，这样我们就可以更清楚的了解他们的想法。然而这显然是一种不现实的想法，客户没有笨到愿意去学习C语言去描述他们的需求。而在实际的项目经理与研发人员和我们这些编程的人员交流的时候，我们的解决方法是什么？是模型语言。然而着其实就像要求客户学习C语言一样，要求他们用模型语言来和我们交流也一样是行不通的。
第二节：项目文档真的可以用甲骨文来写。其实一些项目中的情况往往是这样的，在项目中决定使用UML的是什么都不会的老板和什么都会的博士。而在真实场景中去做事的客户与项目成员，往往用不好UML。其实语言可以有很多种，就像甲骨文一样，如果你运用得法也可以用来描述用例。而在与用户的交流过程中，既然他们不懂得UML，我们又何必非要用UML与其交流呢？这就像是我们需要在正常人与盲人之间建立的一种沟通方式，既然盲人不能睁开眼睛，那么你就闭上眼睛。所以说我们在于客户沟通时，要确认自己的沟通方式是否有效，而不是刻意的去追求这种方式是不是UML。
第三节：最简沟通。这一章强调的是有效沟通，作者通过他做一个项目的实际过程告诉我们要如何进行有效沟通。首先，在沟通前要先了解该公司的具体情况：比如公司的经营理念，组织结构形式等。在充分了解客户信息后，我们开始设计提问，然后进行沟通，通过沟通确定项目的实际需求，然后进行整理，接着用很短的时间完成一个初步系统模型。然后这时进行面对面的沟通，听取客户的意见，然后根据客户的意见进行下一步的设计。需要注意的是，在每次沟通的时候，我们都需要尽量做到有效沟通，而这就需要在沟通之前，想好问题和提问方式。
第四节：为不存在的角色留下沟通渠道。这节内容主要讲的是我们在做项目的时候，要做好历史记录，这样才能避免一些项目因为负责人的离开而终止，还能为以后维护项目的人——那些不存在的角色留下沟通的渠道。而要做好历史记录，就需要我们将需求阶段，设计阶段，开发阶段，测试阶段的历史详细的记录下来，当然在记录的时候不能忘了记录下当时的时间和自己的名字。
第五节：流于形式的沟通。很多时候，我们所听到的沟通，都是一种形式。很多情况下，只是一种交流感情的形式。沟通问题不仅存在与客户的交流中，还存在项目的各个角色之间。UML虽然是解决问题的最佳手段之一，但是我们不要指望每个项目都能用它。其实使用与不使用 UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。在每一次回顾项目时都应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
总之，这一章让我学到了在项目开发的过程中如何去沟通，如何才能进行最有效的沟通，而不是流于形式的沟通。只有我们学会有效的与客户和团队中人员沟通，才能开发出好项目。