当项目组长的一些体会.doc

究生.社会经验都比较少,对他们的关心就需要格外细致,比如在他们刚来的时候,机器设备的配置,软件的安装,各部门情况的介绍,都要和他们讲得比较细,这样比较容易消除他们的陌生感,很快的融合到集体中来,另外一个要注意的是,对他们的工作的安排和检查要细致.一般来说,我对他们工作的安排一般一个阶段不会超过两天,也就是说,两天比检查他们工作一次,在检查工作的时候,首先要表扬他们的成绩,然后告诉他们存在的问题,以及问题的解决方法.在让他们去试验(不可包办代替,让他们自己去做,这样才可以积累他们的工作经验).而且在检查的过程中尽量保持谈话环境的轻松愉快,(可以讲一些我们原来的臭事,避免单纯的说教式的检查方法),这样新同志一般都会接受我们建议, 　 同时为以后的工作打下一个好的工作氛围,工作要细致的另外一个体现是要根据不同的人安排工作.比如我们今年招的测试人员,其中一个是计算机专业的本科,又在单位实习了3个月,我安排他的工作就是学习TD和QTP进行测试,原因很简单.他在单位做过测试,对测试理论的认识也比较到位,而且有一定的开发经验,那么如何早日将他培养成一个优秀的测试人员就是我的目标.而测试工作的使用实施对他的个人发展就显得很重要了.另外一个是本科非计算机专业,他的主要工作就是不断重复的作一个系统的测试.每测试一次,我都要给他讲解一次,没有办法,他累我也累.但他没有开发经验也没有测试经验,如果一下上太复杂的东西,他不但不能掌握所学的知识,而且对工作会产生一种畏惧心理,这对他以后的发展是很不利的.所以我对他的安排就是在3个月内不断的进行实际的测试,并且不断总结经验,这样三个月的时间内,他基本就可以掌握测试的基本方法和理论,而在三个月之后,他也要开始测试工具的学习,而那时我的第一个测试人员已经记基本掌握了QTP,可以帮助他了.对不同开发人员测试人员的具体情况进行分析,让他们做适合他们做的工作,并且在每一次工作中都让他们不断增强自信心,而且提高自己的技术水平,你的组员怎么会不听你的指挥 ? 作为一个项目要勇于决断 作为一个项目组长要勇于决断,项目组长是最了解项目的管理人员,无论是用户,组员还是测试人员和质量保证人员以及客户都是以项目组长为中心的,这个地位决定了项目组长应该是对项目最了解的人,那么他在关键时刻的判断和决断就对项目起着关键的作用.而作为项目组长如果不敢和不能决断的话,必然给项目的开发造成极大的困难,说两个故事. 一个是我的哥们,有一次他去客户那里没有参加技术讨论会,回来的时候,他的开发人员的讨论会还在激烈的争吵着,见他回来了,分成两派的开发人员就让他来判断那个算法更好,我的哥们听了一会说,我来告诉你们如何取舍,于是从兜里掏出一个硬币,正面用A方案,背面用B方案,然后一扔,于是结果出来了.当时我听了这个故事直笑.问他为什么这么做.他说,我不搞技术很多年了,但听他们说得,两个方案差别不多,不过是A+B=C还是B+A=C的问题,这个时候如果你去参加参加讨论,无论采用A还是B都要费很多的口舌,而有那个时间早开发出来了,于是就想了这个方法.当然采用这个方案的时候,开发人员都看傻了,别忘了给你的开发人员讲解一下你为什么采用这样的选择方法 另外一个项目就很有意思了,表面上这个项目组长很尊重开发人员,每周都要开一次周会,而且开会的时间还不短,可很快开发人员就不在会议上发言了,有一次和他们组的开发人员闲谈的时候,问他们为什么不在会上发言了,那个开发人员告诉我,每一次提出问题,组长都是侃侃而谈一番,没有任何实质内容,最好的情况是说这个问题下面让某某,于是坐在一边不说话了,更多的情况是说这个问题很重要,我们先放一放.下回讨论.可是问题既没有记录,也没有安排人去做专门的研究,往往是不了了之.一次两次,慢慢的开发人员都认为提的问题不可能得到解决,于是每次的周会就成了项目组长的独角戏,而其他人员的手机发短信的水平,以及图画水平倒提高了很多. 很多项目组长往往感觉自己的权威性不够,经常会说给我这个权力那个权力,我就可以怎么怎么样,其实,项目组长的权威不是建立在对开发人员的工资或者其他的控制上,而是建立在你的做事方法,开发能力等这些软件水平上的,如果在你的组员遇到问题的时候,你可以为他们解决,提出可行的解决方法,什么和他们一起同甘共苦的去完成那些最艰难的问题,你的组员怎么会不信服你,你又怎么会没有威信呢. ? 对不同的人员采用不同工作的方法 作为项目组长最重要的一个特点是要细致，在安排和检查工作的时候尤其要细致。对待刚参加工作的工作人员和老工作人员也要区别对待，一般来说刚参加工作的人员工作热情都比较高，但工作方法的掌握都会有一些这样或者那样的缺陷，如何做到既不打击他们的工作热情，又防止他们的工作走偏是一个很重要的事情，我带项目组的时候，有一次给了我四个刚毕业的工