关于团队成员互相交流的思考

      软件产品的生产，是团队共同努力的结果。
      而要提高生产力，必然就要有一个良好的团队间交流方式来促进。

      （一）当一个软件项目下来了，每个程序员对需求都有自己的理解。如何让大家不会走弯路，这个时候就需要项目经理来帮助统一大家的思想了。
      只有当目标一致才能快速正确的开发出产品。
      大学里的软件工程教材里说，需求分析和设计占用一个项目的百分之六七十的时间。但我工作后发现大多数中小软件公司并不是这样，大部分时间都被后期修改BUG修改需求等等的修修补补占用掉。可能很多人觉得按照正规的流程来做软件，是在浪费时间。所以项目下来了，经理立马带着小弟们操家伙就开始了编码。在这里，暂且不说经理对项目的理解是不是符合客户的需求，就说说团队成员之间，应该如何来更好的理解这个项目。

      （二）编码之前，加入对项目的正确理解，是不是在浪费时间呢？
      我觉得这个是大家的惯性在作祟，只要仔细的思考一下，都能得出正确答案。
      我们往往在编码的时候才发现，因为理解错误而修改程序，花费的时间远远多于去理解需求，写设计文档的时间。这么修修补补下来，最后的软件质量，还让人担心。那就有必要，在项目经理确定了需求之后，跟团队的成员进行一个交流，让每个成员都能更好的理解自己的任务。而项目经理的职责，就是引导大家往一个目标使劲。每个程序员可以根据自己的任务进行设计，这也是在表达自己对项目的理解。当发现偏离了目标时，经理可以尽早的给予引导，免得误入歧途。

      （三）软件是一个复杂的东西，各个模块功能之间关系互相纠结。所以每个成员做的事情也是互相关联的。
      当自己某个功能高歌猛进时，需要跟这个功能有关联的另外一个功能来协作，但自己的战友却没有理解到而在做别的事情，程序卡在了半空中，不得不咬牙切齿的等待。一鼓作气，再而衰，三而竭，拖慢了速度不要紧，还影响了情绪。
      所以团队间的互相交流也就非常有必要，根据功能模块，可以时不时开一些小会议，互相交流各自的完成情况，接下来将要进行的任务，以及自己的任务所涉及到别的成员需要先完成的任务等等，理顺了流程，和谐了气氛，增加了感情，何乐而不为～