【IT168 技术文章】
hjhza:
我的一个数据，在概要设计中，因为交流不够充分，在评审中发现了大量的问题。修改和评审用去的时间是概要设计的1/3左右。而且这并不能保证所有的问题都被发现了，可能还有些问题需要深入探讨才能发现。
项目组如何做好交流？
goldeagle:
关键作用
fondtiger:
交流是很容易的，不就说话吗，关键是有些开发设计人员从心底里不愿意交流，或者说不积极，这才是关键。
hjhza:
我的一些看法，
在项目组中经常出现一种情况，就是PM对各个组员的工作检查太多，导致很多工作不能及时执行。
在项目组中也有很多这样的情况，就是PM不知道如何去做一份可行的计划，不清楚如何去分工。
当然以上工作主要看PM的能力，但是也要看方法。就拿第一种情况来说。交流会起多大的作用？这首先要分析一下，PM为什么增加检查力度，细致且繁琐。PM担心组员不能把任务保质保量的完成，所以就不断的检查。这种
担心是有必要的，但也在很大的程度上说明组员没有理解你的意思，没有理解你分配的任务，不清楚你到底要什么？而这个问题主要是PM的问题。
在分配工作的时候，经常出现不知如何下手的情况。任务分解不了，时间也不能确定......，这些只是PM自己的想法，为什么不问问你的组员呢？你去问会让你的感到似乎是技不如人，感觉有些别扭。那就开会好了，大
家来讨论如何解决（这针对与大的分工）。可以确信一点，到大家讨论的时候，肯定考虑的比PM一个人考虑的全面，而且可能更科学。
我们现在的PM一般在分工的时候，都会说一句话，就是“你先做着看吧”，为什么是这样的？当这句话说出口的时候，组员可能有多种理解：
1、PM是不是认为这个部分不重要？
2、是不是完成不完成都没有什么区别？
3、既然没有要求，那做好做坏都一个样了？
如果有了这些想法，那你这个任务分配是失败的。在PM分配了一个“模糊”的任务后，一般不会得到好的效果，总是存在这样或那样的问题。而且自己在检查工作的时候也不知道该检查什么，也不清晰什么状况下才是完成了。
在这种情况下，PM不加大力度去监控，不花更多的时间是检查，那肯定不行！
当PM不能将任务分配的时候，最好先不要将任务分配下去！磨刀不误砍柴工吗，最好先把工作理顺了，可以讨论，然后再将PM的要求清晰的传达给组员，当组员了解自己要做什么，知道要达到的要求后，PM也就知道了，至
少在检查的时候，就可以有的放矢了！
交流的顺畅与否，其实可以明确一点，就是大家的相互关系的好坏！要是你的组员总是感觉被你训斥，你想让他来跟你交流？那不是“找骂”吗！交流应该随时随地的进行。
我们的一些交流其实都很不到位。有很多两人交流中，谈着谈着声音就变大了，感觉像是在吵架。这种情况尤其容易出现在一个给另一个讲解的时候。
交流如果充分的话，可以让你发现许多问题，在工作检查的时候，当两个人在激烈辩论后，其他人都会发现，原来还有这么我没有思考到的地方。
zydzyr:
项目组成员的组成、搭配是否合理以及性格、技术是否互补对交流是否顺畅也有很大影响。
dvmrp:
谁声大，谁有理，这是中国人在进行技术讨论时的普遍现象。
fondtiger:
错了，谁官大，谁有理
hjhza:
有理不在声高，有理不在官大！
fondtiger:
概要设计通常是系分或项目经理领导组织设计，加上部分高程或程序员的参与，对其他人员的疑问基本上做冷处理（不理），在这样的情况下，官大就有理。
实际上交流应该是在平等的基础上进行的，离开了这个基础，就别提交流。
hjhza:
Fondtiger说得对。
所以交流（项目组的）出问题的话，肯定是PM的责任，有些PM总是希望组员能够主动和他交流，不是主动出击，所以造成后来项目组的人“冷冷清清”。
交流首先应该主动，不但提倡PM主动，更提倡组员主动。
fondtiger:
有些人喜欢把整个事情想得比较清楚以后，才跟别人一起讨论，这种方式通常花得时间较多，一旦有问题，就是对时间的巨大浪费，优点是讨论的时候已经有一个比较清楚的模型。
有些人喜欢先讨论确认一个大概得方向后，再一个人细化问题，最后即可以参加评审。
我比较喜欢第二种方式。
goldeagle:
请参考《商务管理与沟通》
hjhza:
我觉得在很多时候，需要一种交流的气氛，这种气氛必须有管理者去营造。有了这种氛围后，大家就会有一种交流的欲望。
管理者就是带头的，在交流这个问题上，同样需要带头。
在一个项目里，最好有一定的交流制度保证，保证最少的交流次数。
goldeagle:
大家都可以看，现在最新的应该是第五版
我觉得不错
