第四章主要讲述的是沟通，作为程序员我们能很好的与客户沟通吗，答案是否定的。开发人员总是先要接触客户，了解客户到底想要什么，来确定到底要做什么。但是客户不懂C，开发人员就不能有效的与客户沟通，就需要咨询公司借助UML来介入需求阶段，帮助了解和分析需求。因为客户不会C当然也不会UML，此时最直接的问题还是与客户如何交流？最为开发人员最重要的就是与客户交流，来了解客户的需求从而进行研发。无论是开发人员还是咨询公司，想达到的目的都是了解客户的需求，但是在这期间C和UML，客户都是不了解的。这就引出了一个很重要的问题，怎么才能做到有效的沟通。
“我们需要在正常人与盲人之间建立一种沟通的方式，既然盲人不能睁开眼睛，那么你就闭上眼睛好了。”UML 图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及? ? 更深入的交谈。通过甲骨文我们了解了只要约定一套“语法”并且得法就能达到良好的沟通的目的，所以你要确认你的沟通方式是否有效，而不是去追求这种方式是不是 UML，以及用 UML 表达得是否正确。与客户沟通是方式是多变的，要取决源头，是一个专家组，还是一个不懂UML的人，就要改变不同的沟通方法。
减少沟通和保障沟通质量的问题是尤为重要的，保障每一次沟通的有效性都是最重要的事。每一次沟通，都是向客户了解更深层次的需求的机会，因此在见到客户之前，设计出所有的问题和提问方式。这样就了解了客户项目中所有会产生需求的信息点。通过设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设，来了解客户的需求，所以通过设计提问来保证沟通的质量。
项目的中断和中止，很多的项目在负责人员离开后，就自然而然地死掉了。一切的原因“没有 history”。我们做项目的时候，如果不留下历史记录 (History)，那么以后别人来看这个项目，也会是两眼一抹黑，项目便就此中止；要么就花大量的人力物力来攻关。维护旧项目比做新项目更难，在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道。 项目的 History 作为跟这种“不存在的角色”沟通的一种方式。History 的丰富和准确为项目的后继开发、维护提供了可能。History 是为整个项目而记录的。一些参考的记录内容有：需求阶段、设计阶段、开发阶段、测试阶段。通过History留下历史记录，可以方其他人更好的阅读我们的程序。在JAVA上机课上老师说的最多的一句话就是“加注释”，加注释不仅可以为我们编写程序理清思路，也方便了其他人来阅读我们的程序。
沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目。沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。UML 的确是解决沟通问题的最佳手段之一，但不是万能的方式。使用与不使用 UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。沟通方式的选择对于达到沟通的目的也是很重要的。
参加比赛项目时，就要做到与队员的良好沟通，与项目的良好沟通。