须懂得倾听，在听意见的时候，不要过于自信!应该创造一个良好的交流环境，一个好的交流环境可以激发人的思维，一个差的交流环境会抑止交流的欲望。而在这个环境中，PM的心态是比较重要的。
我发现每个软件公司几乎都有例会制度，但是每次例会的效果越来越差，几乎就变成了一个人说话了。例会制度本来是为了保证交流，增加交流。但是，由于这种例会形式过于正式，所以使人感觉气氛压抑，所以就抑止了交流欲望，结果反是减少了交流!氛围决定交流的效果，比如PM请项目组人员去喝酒，这时的话肯定比例会时的多!
以前看到美国人、印度人每天下午都有一个喝咖啡的时间，曾经很纳闷!现在感觉到了，原来是调节交流氛围的!
软件文档的必备要素
和大多数同行一样，我明白软件文档的重要性。不幸的是，在任务开始前我很少阅读文档。相反，我常常像视线不清的父母一样，在装配好他们孩子的自行车之后，还落下一两个零部件没装上。 如果我们明白文档的重要性，那为什么我们不更经常用它呢?然而，许多软件文档存在以下问题：
· 错误的语法和/或拼错的词语
· 不完整
· 过时或不准确
· 过于冗长
· 未经解释的缩略语或专用术语
· 查找信息困难
存在这些问题的主要原因是软件文档常常被退居次位。工程预算迫使我们优先考虑开发过程中的主要活动，也就是那些可以看得到利润的地方。编写文档需要成本，因而它常常成为一项主观上的活动，而且通常被认为没有重要作用，应该尽量避免。许多项目经理认为客户不需要文档，它只是用来装点门面的。 软件文档质量差的另外一个原因在于文档撰写者。许多应用程序开发经理认为软件文档的编写是软件开发过程的一个标准组成部分，因此要求开发人员在编码的过程中产出文档。
尽管这种做法在理论上行得通，但它没有考虑开发人员编写文档的能力。简单来说，技术人员是用来开发软件而不是编写文档的。为了解决这个问题，许多应用程序开发经理雇佣专业技术文档编写者或业务分析师，以期改进软件文档的质量。但这又遇到了另一个难题：专业编写者及业务分析师的技术水平有限。
解决这个问题要考虑需要编写的文档以及文档的预期读者。一般的规则是，写文档需要团队协作，这样就允许开发人员和文档编写者利用彼此的长处，取长补短。例如，如果预期读者是系统设计师，开发人员需要提供技术细节，然后文档编写者按照正确语法组织和编辑内容。不考虑预期读者或专门编写者，软件文档的质量取决于其可用性，可从以下6个方面去评价其可用性：
· 应用性：文档是否提供相关信息?
· 及时性：信息是否及时?
· 准确性：信息是否正确?
· 完整性：文档是否足够详细而又不会太过拘泥细节?
· 可得性：文档是否随时可得?
· 可用性：你能否很快凭直觉就找到所需信息?
软件文档的最主要目标是传达一个系统的技术要素和使用方法。第二个目标是提供软件开发过程中的需求，决策，行为，角色和责任的书面记录。只有实现了这两个目标，软件文档才真正提供了有意义的信息。
任务监控
在项目组中经常出现一种情况，就是PM对各个组员的工作检查太多，导致很多工作不能及时执行。在项目组中也有很多这样的情况，就是PM不知道如何去做一份可行的计划，不清楚如何去分工。当然以上工作主要看PM的能力，但是也要看方法。就拿第一种情况来说。交流会起多大的作用?这首先要分析一下，PM为什么增加检查力度，细致且繁琐。PM担心组员不能把任务保质保量的完成，所以就不断的检查。这种担心是有必要的，但也在