有很多流于形式的沟通，但流于形式的沟通却不可取。
“沟通”存在目的以及方式。有目的，所以要设计；有方式，所以要选择。那么在设计和选择的过程中，
考虑时刻出现的客观和不确定因素，成为了沟通的必修课。
如果两个人之间没有共通的一种交流方式，那么他们就无法了解对方的需求和目的，也就不要提最后
两人可以得出什么结论和解决方案。若是让一个开发人员与客户进行交流，那么就必须让他以需求调研的
身份出现在客户面前，如果无法适应这种转变，那么沟通无法进行或者根本达不到应有的目的。
所以，要解决沟通的问题，真正了解客户的需求，往往是行业咨询公司的事。只是其中存在一个问题，
他们喜欢把事情搞得很复杂，也就是说其有自己的专业说法，这种说法包含了两个方向：与客户的沟通、
与项目人员的沟通。那么问题来了，客户不懂ML，分析师要怎样形象又具体地去解释以及了解客户的真正
需求？这和客户不了解C所以开发人员无法用C与其沟通是同样的道理。也就是说，在这里沟通方式的选择
出了问题。
那么，如何选择一个真正合适的沟通方式。甲骨文可以用来写项目文档吗？答案是肯定的，为什么。
只要运用得法，它一样可以用来画用例图、写用例规约，只要规定一套语法，同样可以用甲骨文来做活动图、
类图、构件图以及相关的规约。这样以来，如果你的沟通对象是商周文化的考古学家，同时你也精通这种语
言，两人就可以进行畅通的交流，深层了解需求及分析。就像盲人看不到路，他不知道眼里的路是什么概念，
那么为了能与其沟通，正常人要站在相同的位置去了解，也就是闭上眼睛。只要记住，互相精通同样的语言
处在同样的位置，才是最好的沟通方式。
那么沟通的过程，我们究竟要交流些什么，不明目的不明内容的说一通，也是在浪费时间。保障每一次
沟通的有效性是最重要的事，每一次的沟通机会都是向客户了解更深层次需求的机会，因此在见到沟通对象之
前，你就应该设计了所有的问题和提问方式。
为不存在的角色留下沟通的渠道。一个项目，总会有别人来看，或者在完成的过程中出现了某种未预见的
突发情况，导致负责人员或项目人员的撤席，这些情况，都需要有一个历史记录来作为参考，甚至直接起到项
目交接的决定性作用。历史记录基本包括项目的需求阶段、设计阶段、开发阶段以及测试阶段。
最终重申，流于形式的沟通不可取。项目人员与客户之间的沟通，项目各个角色之间的沟通都是完成一个
项目的关键，根本还是在于沟通方式的选择，只要是行之有效的、可以在各个角色之间通用的，就是好的沟通
方式。而流于形式的沟通，只能使项目不断推翻和不断延迟。