本章开头就讲了在以后所面对的问题：客户需求，作为一个软件开发人员在编写程序前就一定要知道最终所做程序的目的，要不然客户是不会买帐的，那么在开发前与客户沟通就是必须的。
客户是咱们服务的对象，但客户并不一定会知道我们所做的努力，于是沟通是至关重要的，我们平时是与电脑沟通的，而直接面对用户是不同的，就如项目经理所拥有的优势，他可以不用了解c语言，也可以用一种非c的语言来与客户交流，但如果开发人员去沟通那是灾难性的，他们会很平常的说出一些专业性的词语，客户会摸不到头脑。作为一个沟通者，他们会说出客户能听懂的语言，让客户简单的了解到程序的结构。
在项目中使用UML未必见得好用，所谓的UML就行我们所说的说明书，只不过更加细节罢了，NML由“用例图”和“用例规范”组成。这些就像是甲骨文一样，例如甲骨文中的“家”，就是上有房子下有猪，这个定义与UML是一个意思。UML图在一些客户眼里无异于盲人眼中的世界，如果需要向他们做需求调研，那么你只能使用一些客户能够理解的方式。一旦源头确定，你就可以接下来约定在项目中要使用的沟通方式。在沟通方式中最简沟通时必须的，假如一个项目并不大，从主观上来说，客户并不会为这个项目投入太多的精力，更重要的是，我们在前期交涉中已经发现：这个客户代表为大量其他的项目和工作所困扰，他不会有时间来处理我们的问题，因此，减少沟通和保障沟通质量的问题就显得非常突出。在我们提问时，每一个提问涵盖尽可能多的信息点，尽可能地具有发散性以便形成更多的一轮和假说。还应该清楚的是，保障每一次沟通的有效性是最重要的事，沟通并不是打电话或者请客户吃饭那么简单的事，最好在见到客户之前，你就已经设计开了所有的问题和提问方式。流于形式的沟通是没有益处的，沟通应该是具有目的性的，如果在没有明确目的的情况下与客户沟通，那是浪费客户与自己的时间。沟通问题不仅仅存在与客户交流之中，还存在于与项目的各个角色之间，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不懂。因此，沟通是要行之有效的、能在各个项目角色间通用的，就是最好沟通方法。
本章主要讲的是在今后工作中所遇到的问题，流于形式的沟通，会使你的项目被不断推翻和不断延迟。