对于后者，实际还是一个项目管理和沟通的问题，规范的管理制度、严格的执行应该可以保障项目的进行，比如定期的项目进度报告等、定期的检查，都可以有效的控制项目的进度和计划。

对于前者，我认为是属于公司的管理制度上的事情，流川所说的，我觉得都是属于沟通的途径，具体的还在于管理者对这类事情的态度。举个例子，我现在所在的公司中，有质量管理部，其职责就是对全公司的质量目标进行监督
，同时负责产品、项目和工程的信息发布。如果执行的彻底的话，这个部门实际就是部门间或项目组间的桥梁，但实际上，我感觉他们仅是在敷衍了事，为什么呢？我觉得原因就在于执行的不彻底和权利的不明确。执行的不彻底
造成该部门的人只能对付着做事，权利的不明确造成他们对其他部门和项目组没有实际的约束力。

实际上，如果要是公司的项目都是基于公司自己开发的产品的话，那么这种交流相对简单，只要注意以产品组为主维护好来自客户的需求基本上就够，一般性的交流也是以产品开发的里程碑为时间点。

但是，多数时候，项目组与项目组之间并不能完全依靠公司的产品，甚至于公司本身就没有什么产品、或者产品的研发计划比较乱。对于这种情况，对于有产品的，那我觉得首先是做好产品的开发计划，并且这个计划得到批准之
后，公司首先应该是要重视并保障这个计划的执行，在这个基础上，各个项目组可以围绕着产品开始交流，同时也可以给产品组反馈前方的意见。
对于基本上没有自己产品的情况，交流基本上可以维持在技术或经验的层面上，比如定期的技术沙龙、项目经验汇报等，也就是程序员交流程序员的经验、项目经理交流项目经理的经验。至于比较理想的情况，想做到不同项目组
之间在开发等方面的重用的话，个人认为比较困难，因为这牵涉到多个项目的设计和实施，牵涉到的人员也比较广，难易控制，也不现实。

综合一下，我感觉在项目组的交流这个话题下，首先就是确定中心问题，那么有产品的可以以产品为中心议题，没有产品的可以以经验、技术为中心议题。确定了中心议题之后，方式、方法有很多，找一个适合公司情况的、适合
各个项目组时间安排的，在加上公司中高层的重视，具体的实施起来并不是很难的事。

说实话每个项目组都紧张关注自身的项目，并都有项目经理带领。如果一个项目团队关注另一个项目团队的项目，可能会被视为多管闲事。当然如果若干项目团队在一个大项目合作，那交流的机会可能性比较大。

比如说产品研发，生产这2各过程2各团队需要更多的交流。但如果2各团队同时做不同产品的研发，要交流各自的心得可能更合适在每次公司聚会上，私下的交流纯属个人交流。

做为项目经理的确应该关注项目团队间的交流，不论从纵向（比如研发团队和生产团队）还是横向（比如2各研发团队之间）发展都有利项目日后的顺利完成。公司领导应该给予支持，这是个好的公司文化