流于形式的沟通
所谓沟通，即是人与人之间的交流，在软件工程中则包括客户与项目经理的沟通，项目经理与开发人员的沟通，开发人员与计算机的沟通，毫无疑问这些沟通都需要语言。正如开发人员与计算机沟通需要c语言一样，项目经理与客户沟通也需要语言，当然并不是c语言了。
在一个项目中，客户通过与项目经理交流来表达自己的目的，再此过程中，开发人员最好不要直接面对客户，因为开发人员不能跟客户进行很好的沟通，而项目经理有这样的优势：他可以不用了解c语言，也可以用一种非c的语言来与客户交流。在做需求建模时，需要使用一些软件行业中习惯的符号和标识。这些符号和标识即是UML，它是建模世界的世界语。其实在一些情况下，在项目中使用UML只是完全不懂的老板，以及什么都懂的博士的主意，而真实场景中去做事的那些客户与项目成员，其实是未见得能用好UML的。所谓“问道于盲”，我们需要在正常人与盲人之间建立一种沟通的方式，既然盲人不能睁开眼睛，那么你就闭上眼睛好了。所以，在与客户交流时，你要确认你的沟通方式是不是有效，而不是追求这种方式是不是UML表达的是否准确。
好了，那么为什么非要让客户看UML图呢？如果有满足“极限编程”的“现场客户”，那么当然不用画用例图。相反，如果客户雇了一个专家组来评审软件需求，；那么你只能老老实实的画用例图了。当然，如果顾客雇了一个专家组，那么就无需与客户进行非编程语言的交流了。一旦确定了项目中的沟通者，那么你就可以约定在项目组要使用的沟通方式。其实，在一个项目中，倘若这个项目并不是很大，客户并不想为这个项目投入太多的精力，那么在这个项目中的沟通环节距应该简化，缩短沟通时间次数，并提高沟通质量（毕竟项目小而没有太复杂的事去解决），所以最简沟通就出现了。在沟通前，先了解客户在公司层面的外在表现、内部运营管理手段以及客户在项目中即已确定的需求和可能发生的需求和客户围绕其公司行为（和方向）所提出的需求。应该清楚的是，保障的每一次沟通的有效性都是最重的事。在一个项目中，维护旧项目比做新项目更难，其实可以减轻这种感觉的方法就是留下历史记录。如果我们在做项目时留下历史记录，那么别人在看这个项目时，就不会是两眼一抹黑。历史记录的丰富与准确为项目的后继开发、维护提供了可能。但是历史记录与注释不是一码事，注释是为了阅读代码的人留备的，而历史记录是为整个项目而记录的。
流于形式的沟通有很多，其实沟通是具有目的性的，如果没有明确的目的与客户沟通，那么就是浪费时间，拖延项目的进度。
