团队建设的总结

　　展开说团队建设之前,先说下我们之前的工作模式。我们这个开发小组的人数不多,前几年一直维持在五六个人的样子,人员组成是一个组长,剩下全是程序员,由于项目也不多,基本上是哪个项目急先做哪个,大家一块上,组长负责需求,一个程序员搭项目的架子,然后分模块,需求分析由程序员自己做,完了把项目凑一块去,项目就成了,很作坊式,这中间的问题想必搞过开发的都知道.这样的情况持续了四年的时间,后来部门进入到一个高速发展的阶段,项目越来越多,人员也越来越多.在这样的情况下,原来的作坊式开发就成为了一个发展瓶颈.在痛苦的挣扎了半年多后我们痛下决心要改变,整个改变是逐步进行的，因为一切都是在摸索中进行，中间有一些反复，最终好的东西保留了下来，虚的或者不适合我们团队的东西被放弃或被改进。

• 明确分工，各司其职，扁平化管理向层级管理过渡

　　之前的工作模式以模块为划分单位，大家做的工作都类似，整个流程所有人都要过一遍，这样的问题是有一些软件过程很容易被忽略，像详细设计、单元测试这样的工作，基本上没人会做。最终的软件质量也只能凭借程序员的个人能力和责任感来保证，而项目的管理者在这中间的监控能力是很弱的，除非你深入到每个人的工作中去，否则在过程中，你很难控制风险，一旦出现问题管理者只能祈祷相关的人员赶快搞定它，因为没有其它人能帮上忙。这种工作模式把程序员都煅炼成了全能手，这是好的地方，也是不好的地方，每个人的性格都不一样，擅长和感兴趣的地方也不相同，让合适的人做最适合的事，从效率上来说是最高的。另外一点，从个人的发展来说没人想当一辈子程序员，管理者必须照顾团队成员这种要成长的心理，也必须留下这么一个空间，让大家看到希望。

　　于是团队中开始有了分工，最初的分工是项目管理（兼测试管理）、系统分析师、开发管理、开发人员这四大类。项目管理是项目经理工作中偏管理那部分工作，具体说开就是进度控制、风险控制、质量控制等工作。系统分析师主导需求分析工作，工作的成果是详细设计。开发管理负责软件技术相关的工作，像技术选型、开发、部署相关的工作等。这样的分工明确了岗位，让人尽其用，同时也形成了一个开发流程，每个环节的时间预先都有计划，拖的久了自然会有压力，扯皮的事也少了，你这个环节做的好不好，所有人都看的很清楚。

　　这样的分工多少还有些教条化，项目分工要以人为本，最终的分工协作模式还是要根据团队成员的特点及项目特点来对细节进行调整。经过一年多时间的逐步细化完善，上面的分工其实有了一些改变，主要是因为有多个项目需要穿插进行，解决办法是增加了系统分析师的人数，项目负责人的指定更加灵活，不是只有项目管理岗位的人担当，系统分析师和开发人员很容易从一个项目出来转向另一个项目，增加了人员的灵活性。

• 制度保证，让团队敏捷起来

　　因为我们选择了ruby on rails，所以敏捷开发模式也就顺理成章，如何保证团队敏捷起来，在前期一些明确的制度是少不了的，例如每日早会、周例会、即时讨论、详细设计审查等等，每日早会可以让团队中的问题及早暴露，让项目的进度管理和风险控制在早会中完成，周例会召集客户，展示一周工作成果，讨论需求。避免需求分析存在误差，更快的项目迭代。即时讨论是在需求分析阶段要求项目管理人员和系统分析人员随时就问题展开讨论，必要时客户也要参加。详细设计审查故名思义。

• 核心人员带头，培养良好的团队文化

　　团队文化的建立是一个长期的持续的工作，需要小组的负责人明确指导思想，核心人员带头才能完成，我们团队的文化用几个字总结就是：无私、分享、互助、协作。如何把团队文化一代代传递下去靠的不是喊口号，而是行动，用实际行动影响下边的人，使这些思想常态化，新人进来会被影响而自然溶入这个集体，成为这些思想的宣扬者。团队文化的形成是团队成为一个自冶、自律团队的基础，是团队建设的最终成果。

转载于:https://www.cnblogs.com/dever/archive/2010/06/16/1759224.html