要做一个项目负责人，首先要做一个好人。最自己负责，对领导负责，对组员负责，而如果想形成一个好的团队对组员负责是一个关键的问题。93年我第一次带团队的时候，我们在江苏开发一个项目，有一次，我的领导找到我谈工作，在谈到一个组员的时候，我问他为什么自己花钱给那个人买皮鞋。领导对我说，你难道没有看到他的手和脚都长冻疮了吗？你作为项目组长，你的组员才大学毕业，就和我们一起出差，第一次独身在外，你难道不能更加关心他吗？这件事情给我感触很大。作为一个项目负责人，不但要在专业上关心你的组员，在平时的生活中也要关心他们。这样才能形成一个好的团队。
关心组员,有几个方面,其中一个是注意组员可能的发展方向,比如我原来的领导建议我做测试或者QA,说我比较适合做个工作.开始的时候个人认为测试并没有什么重要的,还是喜欢做开发,后来因为一些偶然的原因作测试和QA工作,的确很爽.(不过要没有那些年的开发经验会这么爽吗?),在我自己的项目组里也出现这种情况,比如我原来的一个开发人员就是不愿意做开发,搞锝我很难受,后来和他交流发现他想做网络管理,在项目结束后,给他找了一个会做单位的网络系统管理员,他又自学了CCNP什么,干得不错.所以,作为一个项目组长,在关心你的组员的时候,要注意他们的特长和潜质,如果我的组员愿意做开发工作,我会为他们订制一个培养计划,然后给他们提一些要求,这样可以帮他们快速提高开发水平.而如果他们他们不愿意做开发工作,就要及时获得他们的真实想法,并帮助他们去实现他们的目标.这样开发组的内的气氛会很好。
对新参加工作的同志的关心要细致
新参加工作的同志和老同志的差别很大,我们这里的新同志都是刚毕业的大学生或者研究生.社会经验都比较少,对他们的关心就需要格外细致,比如在他们刚来的时候,机器设备的配置,软件的安装,各部门情况的介绍,都要和他们讲得比较细,这样比较容易消除他们的陌生感,很快的融合到集体中来,另外一个要注意的是,对他们的工作的安排和检查要细致.一般来说,我对他们工作的安排一般一个阶段不会超过两天,也就是说,两天比检查他们工作一次,在检查工作的时候,首先要表扬他们的成绩,然后告诉他们存在的问题,以及问题的解决方法.在让他们去试验(不可包办代替,让他们自己去做,这样才可以积累他们的工作经验).而且在检查的过程中尽量保持谈话环境的轻松愉快,(可以讲一些我们原来的臭事,避免单纯的说教式的检查方法),这样新同志一般都会接受我们建议,同时为以后的工作打下一个好的工作氛围,工作要细致的另外一个体现是要根据不同的人安排工作.比如我们今年招的测试人员,其中一个是计算机专业的本科,又在单位实习了3个月,我安排他的工作就是学习TD和QTP进行测试,原因很简单.他在单位做过测试,对测试理论的认识也比较到位,而且有一定的开发经验,那么如何早日将他培养成一个优秀的测试人员就是我的目标。
而测试工作的使用实施对他的个人发展就显得很重要了.另外一个是本科非计算机专业,他的主要工作就是不断重复的作一个系统的测试.每测试一次,我都要给他讲解一次,没有办法,他累我也累.但他没有开发经验也没有测试经验,如果一下上太复杂的东西,他不但不能掌握所学的知识,而且对工作会产生一种畏惧心理,这对他以后的发展是很不利的.所以我对他的安排就是在3个月内不断的进行实际的测试,并且不断总结经验,这样三个月的时间内,他基本就可以掌握测试的基本方法和理论,而在三个月之后,他也要开始测试工具的学习,而那时我的第一个测试人员已经记基本掌握了QTP,可以帮助他了.对不同开发人员测试人员的具体情况进行分析,让他们做适合他们做的工作,并且在每一次工作中都让他们不断增强自信心,而且提高自己的技术水平,你的组员怎么会不听你的指挥。
作为一个项目要勇于决断
作为一个项目组长要勇于决断,项目组长是最了解项目的管理人员,无论是用户,组员还是测试人员和质量保证人员以及客户都是以项目组长为中心的,这个地位决定了项目组长应该是对项目最了解的人,那么他在关键时刻的判断和决断就对项目起着关键的作用.而作为项目组长如果不敢和不能决断的话,必然给项目的开发造成极大的困难,说两个故事。
一个是我的哥们,有一次他去客户那里没有参加技术讨论会,回来的时候,他的开发人员的讨论会还在激烈的争吵着,见他回来了,分成两派的开发人员就让他来判断那个算法更好,我的哥们听了一会说,我来告诉你们如何取舍,于是从兜里掏出一个硬币,正面用A方案,背面用B方案,然后一扔,于是结果出来了.当时我听了这个故事直笑.问他为什么这么做.他说,我不搞技术很多年了,但听他们说得,两个方案差别不多,不过是A+B=C还是B+A=C的问题,这个时候如果你去参加参加讨论,无论采用A还是B都要费很多的口舌,而有那个时间早开发出来了,于是就想了这个方法.当然采用这个方案的时候,开发人员都看傻了,别忘了给你的开发人员讲解一下你为什么采用这样的选择方法 。
另外一个项目就很有意思了,表面上这个项目组长很尊重开发人员,每周都要开一次周会,而且开会的时间还不短,可很快开发人员就不在会议上发言了,有一次和他们组的开发人员闲谈的时候,问他们为什么不在会上发言了,那个开发人员告诉我,每一次提出问题,组长都是侃侃而谈一番,没有任何实质内容,最好的情况是说这个问题下面让某某,于是坐在一边不说话了,更多的情况是说这个问题很重要,我们先放一放.下回讨论.可是问题既没有记录,也没有安排人去做专门的研究,往往是不了了之.一次两次,慢慢的开发人员都认为提的问题不可能得到解决,于是每次的周会就成了项目组长的独角戏,而其他人员的手机发短信的水平,以及图画水平倒提高了很多。
很多项目组长往往感觉自己的权威性不够,经常会说给我这个权力那个权力,我就可以怎么怎么样,其实,项目组长的权威不是建立在对开发人员的工资或者其他的控制上,而是建立在你的做事方法,开发能力等这些软件水平上的,如果在你的组员遇到问题的时候,你可以为他们解决,提出可行的解决方法,什么和他们一起同甘共苦的去完成那些最艰难的问题,你的组员怎么会不信服你,你又怎么会没有威信呢。
对不同的人员采用不同工作的方法
作为项目组长最重要的一个特点是要细致，在安排和检查工作的时候尤其要细致。对待刚参加工作的工作人员和老工作人员也要区别对待，一般来说刚参加工作的人员工作热情都比较高，但工作方法的掌握都会有一些这样或者那样的缺陷，如何做到既不打击他们的工作热情，又防止他们的工作走偏是一个很重要的事情，我带项目组的时候，有一次给了我四个刚毕业的工作人员。我给自己定了几个原则，1要大胆使用他们，要帮助他们解决主要的开发问题，3检查工作要仔细，防止工作出现大的偏差，4分层次，区别使用，尽量作到用对他们。
先说1大胆使用他们，新同志一般工作都会存在这样或那样的问题，而且有时候问题比较明显，我原来也觉得使用他们不如自己开发快，所以总是越俎代庖，这样的结果就是我自己累得够呛，开发人员闲得要命，而且工作情绪不高i。为了防止这个问题的发生。这回我努力克制自己开发的欲望，将所有的设计、编码的任务都安排给他们，自己只负责总体设计、关键技术问题的解决和工作的检查。事实证明，只要你控制得好，开发人员都会比较好的完成开发任务，而且在开发过程中进步也是很明显的。我的这几个开发人员由于我敢于放权，不但开发完成的比较好，而且经验的积累也比同时间来的开发人员要快，很快成为了单位的开发骨干。
放权不是不管，而是该管的管，不该管的不管。对于新同志他们都有一定的开发能力的欠缺，但主要问题体现在两个地方，一个是设计能力，一个是开发的规范性。总体设计是我来做的，然后给他们逐步讲解，使他们了解我这么设计的目的和方法。再让他们做自己部分的设计，开始这是很困难的事情。因为我们的系统需要很强的可扩充性和维护性，所以很多方面的设计方法和他们原来的开发有很大的区别。而他们在学校做的设计根本不用考虑系统的可扩充性和维护性，所以在很多设计思路上彼此差别很大，我不但要完成设计，讲解给他们听，而且要让他们接受我的观点，说实在的真是很困难的，我采用了和实际相结合的方法，告诉他们每一个设计的目的和实现的方法，如果他们有不同的设计也可以，大家一起讨论，如果他们的设计可以满足系统的需求那么我也很乐意接受。
另外一个是开发的规范性，我们的同志在学校的时候基本上都没有接受过规范性开发的培训，而这是在实际工作中必须特别强调的东西，比如代码的规范性、文档格式的规范性等，我就作为强制执行。当然如果一味的强调这是规范必须执行还是不够的（容易产生逆反心理），在具体执行过程，还要和他们去交流。比如如何写文档效果会比较好，如何避免有话说不出来的问题，一般来说，我都采用他们先写文档（或代码），我来检查，然后讲解，他们再修改。再检查、讲解，（编码也是一样），一般来说，第一次的文档他们会写4-6次，但经过一次这种训练，他们的文档撰写水平和编写代码的规范性就可以过关了。
新同志的工作周期我一般安排是1.5---2天的时间。一般来说。新同志的工作我都安排得比较细，他们的工作都在一天之内可以完成，这样主要是防止工作出现比较大的偏差。而且即使出现了问题，我也可以及时发现和调整，不至于对工作造成太大的危害。工作检查不是一个简单的评判过程，更是对他们的一个培养过程。一些工作方法，工作技巧都是在这个时候教授的。在这个环节要特别注意简单粗暴地对待开发人员，一定要将问题讲透讲清楚，最后还要让开发人员再讲一遍你的讲解内容和后面的工作安排（很重要的，在你听他们叙述的时候，往往会发现他们的理解和你的想法有很大的差别），防止交流的无效性发生，一般来说新参加工作的人员如果真接受了你的观点，使会主动改正他自己的问题的（虽然会有反复） 。
即使是新工作人员，也会有很大的差别，作为项目负责人，要善于发现发现这些差别。比如在这个项目中，有一个工作人员作过OA项目（毕业设计），对OA的理解比较多，那我就让他负责系统最重要部分的设计，有的人比较细心，就让他负责配置管理，有的人比较善于钻研，就让他负责权限管理部分的设计（那部分比较难），总之，没有不可用的人，关键是看你是否用的对地方。只要用对地方，便可以达到事半功倍的效果。
学会向用户汇报工作
当然了，也包括领导汇报工作。道理基本一样。说一个在科委项目的课题的故事吧，那个课题是一个做的不太好的项目。用户对我们很不满意。项目组长被撤了，开发人员也都走了，让我接手这个项目，我的目标是完善项目，我到项目经费（还有40%），其中的开发工作就不多说了，只说说向用户汇报的事情，用户的领导是一个50多岁的大妈(大妈是很聪明的，否则也不会在那里做到这个职位)，对我们很不满意，开始的时候，我坚决承认错误，绝不隐瞒（获得对方的认可），其次在后来的时候每次去用户那里，我都会琢磨一下是否要去向她汇报，如果没有太重要的事情，就想想最近在做什么事情，这样在见到大妈的时候，可以汇报，如果真是需要汇报，就要特别考虑一下几个问题，1我现在的工作进展，2我遇到的问题，3问题那些是我可以解决的，什么时候会有答复，4什么问题需要用户配合。（比如硬件设备的改善等）具体配合的内容是什么。在汇报的时候，我会私下掰手指头，一个问题一个问题说，防止遗漏，同时要记住对方的回答。这样几回之后，大妈对我的感觉很好，后边的工作就好做了，后来项目顺利完成。经费自然也回来了，所以在和用户汇报工作的时候要特别注意几点：
1项目是最重要的，无论你采用什么作客户关系的方法，项目或产品必须过关，否则一切都是无用功（国家项目不一定）
2在汇报的时候，态度要认真。特别是出现问题的时候不要一味推卸责任，讲理由，这是没有效果的（在单位汇报工作的时候也一样，没有人会理会你的理由）
3汇报之前一定要准备，这样条例清楚，事情完整。防止因为一点小事情连续打扰客户。要让客户在每一次交流时都有很大的成果。
4汇报的时候要掰手指头，主要是防止问题的遗忘，特别是大家在就具体问题讨论的时候容易干扰你的思路，使你遗忘事情 。
5在汇报之后要将所有问题都过一遍，是否所有的问题都有解决方法了，如果什么事情不清楚，马上问，这样总比再次来好，在说出来，和用户一起确认问题的解决方法 。
6实在怕遗忘，最好带一个录音笔，但千万不要让用户看到，也不要用这个东西作为以后争执的证据用（没有好处的），只是作为资料整理的一个备份，否则用户会反感而不配合你以后的工作。
from：http://news.csdn.net/n/20080804/117869.html