第四章主要讲了在做项目时我们如何与客户进行有效的沟通的问题，让我又一次意识到做项目真的不是一件简单的事，软件工程不仅是一个团队的工作，它真的是一件大工程。第四章第一节就讲到了这样一个问题： 客户不会用 C，难道就会用 UML 吗？ 看到题目后瞬间就意识到了客户与程序员之间要达成意见合适且有效的合同期间的沟通是非常重要的。比如说，你总不能用C UML这些语言的专业词汇去和客户沟通，因为他们是根本听不懂的自然达成项目的意见一致也成了天方夜谭，毕竟我们在学这些编程高级语言时也费了不少功夫，掉不少头发呢，虽然你很想展示你的专业语言，但是沟通的结果才是最重要的。
第二节就说到了 “项目文档真的可以用甲骨文来写 ” 这样一个奇葩的题目，但是看完作者的解释却感觉非常有道理，与其让你画一些“乱七八糟”的用例图，还不如有甲骨文般的象形字让客户看得明白。书中有这样一段话：“在韩愈的《答陈生书》中，他因自己不会“速化之术”， 所以说陈生是“求道于盲”。然而他用了一个不恰当的比 喻：要知道盲人并非不知道路如何走，只是他不能象常人 一样描述他所知道的路。因此“问道于盲”是没有错误的， 真正错误的是你睁着眼睛问。 我们需要在正常人与盲人之间建立一种沟通的方式， 既然盲人不能睁开眼睛，那么你就闭上眼睛好了。UML 图在一些客户眼里无异于盲人的世界，如果需 要向他们做需求调研，你只能使用一种这些客户能够理解 和接受的方式，例如表格、流程图以及⋯⋯更深入的交谈。 你要确认你的沟通方式是否有效，而不是去追求这种 方式是不是 UML，以及用 UML 表达得是否正确。——客 户是因为他认为你理解了他们的需求，而在“需求确认书” 上签字，而不是因为你的 UML 画得是否精准。 ”既然客户啥也不懂，那就好办了，你就抛下自己学到的专业语言变成啥也不懂就OK了，就像我们在茶余饭后聊天一样将已建项目达成。
第三节提到了沟通效率的问题“ 最简单的沟通 ”。因为考虑到实际情况我们做一个项目，特别是这个项目不是特别大的时候与客户进行沟通交流的机会并不多，总起来也就那抹三四次。那如何在这三四次简短的沟通中实现最大化的信息交互就成了项目成功与否的关键。 因此，减少沟通 和保障沟通质量的问题就显得非常突出。再此章节中作者为我们的有效沟通做了四小步的例子，只有详细的了解到情况后才可以着手做项目。恩， 就是这样。
第四节讲到了一个很关键的问题“为不存在的角色留下沟通的渠道 ”。这是个神魔意思吗？！ 很简单咯，就是在做项目的时候一定要想到 为以后项目的维护“留一手“
”维护旧项目比做新项目更难，许多人深有同感。然而 这些“有同感”的人又何曾想过，自己在做“新项目”的 时候，要为“项目维护”这种还不存在的角色，留下一个 沟道、对话的渠道呢？“这是书中的原句。至于要留什么要总摸做，书中都有介绍：
需求阶段：与谁联系，联系方式、过程、结果以 及由此引发的需求或变更； )
设计阶段：如何进行设计、最初的构架、各个阶 段的框架变化、因需求变更导致项目结构上的变 化(有助于了解构架的可扩充性)；
) 开发阶段：每一种技术选型的过程、每一种开发 技巧的细节和相关文档、摘引的每一段代码、算 法、开发包、组件库的出处和评测；程序单元的 测试框架；每一个设计和构架变更所导致的影 响； )
测试阶段：还记得测试用例和测试报告吗？那是 最好的 history 之一。
这样一来我们的项目就会省去以后很多的麻烦。
最后一节”流于形式的沟通“也正是本章的题目，”沟通是具有目的性的，如果在没有明确目的的情 况下与客户沟通，那将是浪费客户和自己的时间。这种目 的，可以是了解项目的讯息、挖掘潜在的项目⋯⋯最末了， 才是交流感情“这句话就道出了本节中的精髓（个人见解）。要带着目的去沟通，得到自己想要的信息，表达出自己的见解和看法才是关键。至于在哪里请客户吃什么饭喝什么酒那不过是形式而已。
沟通问题不仅仅存在与客户交流之中。还存在于与项 目的各个角色之间。项目的分析报告为设计人员所看不 懂，设计人员的方案为开发人员所看不懂，而开发的结果 以为测试人员所看不通。等等都是沟通问题。 达到和工作人员的良好沟通也是非常重要的。