流于形式的沟通
一客户不会用C，难道就会用UML吗？答案是否定的。身为开发人员，我们不能站在自身的角度去评判顾客的想法。不是考虑顾客会不会，我们教会她使用，而是让顾客明白系统，门外汉也能看得明明白白。开发人员最好不要直接面对客户 ，而是让可以不用C语言与客户沟通的项目经理去面对客户，或者开发人员尽早进入状态，避免不必要的误会。
二 项目文档真的可以用甲骨文来写
独孤慕岑经在一篇《UML，OOADand RuP》中讨论到UML实际应用中的问题。其中的两个问题是：
（1）大部分的使用者，一级客户的信息人员，其实没有足够的能力，来确认这些文件《Usercase》的正确与完整性。
（2）除了客户不了解UML，OOAD跟RUP以外，另一个更糟糕的现象是project team 里面的人于不懂
仅以UML的user case 来说，由例图和用例规约组成。规约跟我们写的需求说明书差不多不过更加详细，而且还有一套相应的方法论来阐述如何去实做。显然甲骨文一样可以描述范围和关系。所以只要运用得法，甲骨文一样可以用来画例图和谐用例规约。
（三）最简沟通
我们可以综合一下两个方面的因素来抽取客户所关心的因素。
（1）客户在公司层面的外在表现，内部机制和运营手段。
（2）客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为所提出的需求。
我们开始设计提问，然后确立了项目的实际目标，以及远期的方向。接下来就是设计需求条目。然后是分析设计，然后完成了整个项目的需求报告分析。保障每一次沟通的有效性都是最重要的事情。每次沟通都是向客户了解更深层次的需求机会所以见客户在之前设计好所有问题及提问方式。
四 为不存在的角色留下沟通的渠道
历史记录与注释不是一回事。代码中的注释是为阅读代码而留备的，而历史记录是为整个项目而记录的，一些参考记录内容有：
需求阶段：与谁联系，联系方式，过程，结果以及由此引发的需求或变更。
设计阶段：如何进行设计，最初的框架，各个阶段的框架变化，因需求变化导致项目结构上的变化；
开发阶段：每一种技术选型的过程，每一种开发技巧的细节和相关文档，摘引的每一段代码，算法开发包，组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所引起的影响；
测试阶段：还记得测试用例和测试报告？那是最好的历史记录
（五）源于形式的沟通
沟通具有目的性，这种目的，可以了解下项目的 讯息，挖掘潜在的项目。。。最后才是交流感情。沟通问题不仅仅存在可与客户交流之中。还存在于与项目各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测人员所看不懂等等都是沟通问题。UML是解决沟通问题的最佳手段之一。但并不一定非要在你的项目中使用，只要行之有效，能在各个角色之间通用的才是最好的沟通过方式。
一个项目的完成需要项目组内部人员的交流还要有项目人员和客户的沟通，并且不要用专业术语去与客户交流，要选择一种行之有效的，客户可以接受的方式去沟通。
所以，在我们不过做什莫事情之前，我们都应学会先和别人沟通，只有沟通有效了，才能把事情办好，才能让自己的产品得到别人的认可。沟通及有效，沟通好了，一切尽在不言中，沟通是一切成功的源头。