交流沟通使开发人员明白了用户的需求，有了要实现的目的项目。项目的进行中也少不了与客户的交流沟通，项目完成后的交流沟通当然也更有利于两公司之间更好的交流合作。好的沟通成就了事业，实现了双赢的目标。然而也不免流于形式的沟通，在项目回顾中，你应该认识到流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接的原因。
客户不懂得c语言程序也不知道如何对程序员来表达自己对所要求项目的详尽的要求，我们不能要求客户必须懂得计算机要求，毕竟客户是与我们交流，我们做的才会是与计算机交流，使它替我们做成一些事情。那么项目经理或者需求调研的角色就出现了，这职位被要求深谙项目所涉的业务，但这往往是我们做不到的，因为我们是软件公司，而不是做这些客户业务的公司。于是咨询公司出现了，他们用一种建模的思想与我们的客户进行业务需求，用一些标识符来传达思想，他们用的是模型语言里的世界语，但是客户不懂得的C语言，他们会对UML有很好的理解么。
UML的Use Case由用例图和用例规约构成，还有一套的方法来阐述如何去实作，规约类似于说明书，有了更多的细节，图则使用了几个图形符号来描述系统边界和角色关系。UML作为一种与客户之间沟通的方式，方便了沟通。然而需要注意的是模式本身的精确性并不是我们所极力追求的。我们需要的是有效的沟通，模型只是手段。如果可能的话，可以满足极限编程那也是方法啊，需要留意的是方法不唯一。
UML的确是解决沟通问题的最佳手段之一。仅仅一个项目不会让组员深刻理解他的意思。也并不是每个项目都必须使用。客户理解并支持UML,项目才会有一个好的UML的使用环境。然而，使用不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的，能在各个项目角色间通用的都是好的沟通方式。
沟通需要根据客户的时间，精力来确定时间的安排。一个项目的完成需要根据实际了解客户产生需求的信息点，确定目标及方向，设计条目。每一次的沟通不应该仅仅是吃饭喝酒谈感情，重要的是根据客户的意思及时调整项目实施方向。应该清楚的是，保障每一次沟通的有效性是最重要的事。
中国有五千年的文明史，而有史可查的仅有三千年。是古人的主观原因亦或是秦始皇等人对书籍的破坏最终造成了一段历史的残缺，我们现在只能根据化石，c14等来推测。工程项目亦是这样，项目中如果没有历史记录，要么只能存而不论，要么则需要花费巨大的人力物力。因此做好每一个阶段的历史记录并记下你的名字，那些人就可能通过你找到问题的源头。为不存在的角色留下沟通的渠道是一种行之有效的沟通方式。