一个团队的合作，一个合作的正常进行，最重要的就是沟通。《大道至简》的第四章，紧跟上一章的团队合作，为我们介绍了沟通的方法。
文中为我们介绍了这样一种情况，当客户与调研人员探讨需求问题时，总是把事情弄的十分复杂，双方不能很好的沟通，原因在于，调研人员过分流于形式，用专业的语言介绍自己的产品，而客户对于这种语言不能很好的理解，导致需求不明。大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件(User Case：由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如果去实作。图则很简单，就是几个图形符号来描述系统边界和角色关系。) 的正确性与完整性。除了客户不了解UML，OOAD跟RUP以外，甚至创作团队里面的人也不懂。这不禁让我们怀疑这个公司的能力。如果双方用都不能使用的语言来沟通，莫不如直接用最简单的方式，忽视掉权威和形式，双方只要能够理解，即使是甲骨文一样更加有效。UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式。 你要确认你的沟通方式是否有效，而不是去刻意追求这种方式的专业。客户是因为他认为你理解他们的需求，而在“需求确认书” 上签字，而不是因为你的 UML 画得是否精准。
而后作者给我们介绍了一种与客户沟通的方法，最简沟通。在一个不大的项目中实行这个计划，这个计划只有三条：在一个月中，只能跟客户作三次联系； 三次联系中，最多只能有一次面谈的机会； 一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划。 这样可以提高双方效率，而且在客户的角度，一个小项目不会耽误太长时间沟通，既能节约时间，又能满足需求。应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
所以，只要是行之有效的方式，无论uml还是白话，都可以，不要流于形式。