CIO的管理经

 

要作一个项目负责人，首先要作一个好人。对本身负责，对领导负责，对组员负责，而若是想造成一个好的团队对组员负责是一个关键的问题。93年我第一次带团队的时候，咱们在江苏开发一个项目，有一次，个人领导找到我谈工做，在谈到一个组员的时候，我问他为何本身花钱给那我的买皮鞋。领导对我说，你难道没有看到他的手和脚都长冻疮了吗？你做为项目负责人，你的组员才大学毕业，就和咱们一块儿出差，第一次独身在外，你难道不能更加关心他吗？这件事情给我感触很大。做为一个项目负责人，不但要在专业上关心你的组员，在平时的生活中也要关心他们，这样才能造成一个好的团队。

关心组员，有几个方面，其中一个是注意组员可能的发展方向，好比我原来的领导建议我作测试或者QA，说我比较适合作个工做，开始的时候我的认为测试并无什么重要的，仍是喜欢作开发，后来由于一些偶然的缘由做测试和QA工做，的确很爽(不过要没有那些年的开发经验会这么爽吗?)。在我本身的项目组里也出现这种状况，好比我原来的一个开发人员就是不肯意作开发，搞得我很难受，后来和他交流发现他想作网络管理，在项目结束后，给他找了一个单位，作网络系统管理员，他又自学了CCNP什么的，干得不错，因此,做为一个项目负责人,在关心你的组员的时候,要注意他们的特长和潜质,若是个人组员愿意作开发工做,我会为他们订制一个培养计划,而后给他们提一些要求,这样能够帮他们快速提升开发水平，而若是他们不肯意作开发工做，就要及时得到他们的真实想法，并帮助他们去实现他们的目标，这样开发组的内的气氛会很好。

对新参加工做的同志的关心要细致

新参加工做的同志和老同志的差异很大，咱们这里的新同志都是刚毕业的大学生或者研究生，社会经验都比较少，对他们的关心就须要格外细致，好比在他们刚来的时候，机器设备的配置，软件的安装，各部门状况的介绍，都要和他们讲得比较细，这样比较容易消除他们的陌生感，很快的融合到集体中来；另一个要注意的是，对他们的工做的安排和检查要细致，通常来讲，我对他们工做的安排通常一个阶段不会超过两天，也就是说，两天必须检查他们工做一次，在检查工做的时候，首先要表扬他们的成绩，而后告诉他们存在的问题，以及问题的解决方法。再让他们去试验(不可包办代替，让他们本身去作，这样才能够积累他们的工做经验)，并且在检查的过程当中尽可能保持谈话环境的轻松愉快(能够讲一些咱们原来的臭事，避免单纯的说教式的检查方法)，这样新同志通常都会接受咱们建议，同时为之后的工做打下一个好的工做氛围；工做要细致的另一个体现是要根据不一样的人安排工做，好比咱们今年招的测试人员，其中一个是计算机专业的本科，又在单位实习了3个月，我安排他的工做就是学习TD和QTP进行测试，缘由很简单，他在单位作过测试，对测试理论的认识也比较到位，并且有必定的开发经验，那么如何早日将他培养成一个优秀的测试人员就是个人目标。而测试工做的使用实施对他的我的发展就显得很重要了，另一个是本科非计算机专业，他的主要工做就是不断重复的做一个系统的测试，每测试一次，我都要给他讲解一次，没有办法，他累我也累，但他没有开发经验也没有测试经验，若是一下上太复杂的东西，他不但不能掌握所学的知识，并且对工做会产生一种畏惧心理，这对他之后的发展是很不利的，因此我对他的安排就是在3个月内不断的进行实际的测试，而且不断总结经验，这样三个月的时间内，他基本就能够掌握测试的基本方法和理论，而在三个月以后，他也要开始测试工具的学习，而那时个人第一个测试人员已经记基本掌握了QTP，能够帮助他了。对不一样开发人员和测试人员的具体状况进行分析，让他们作适合他们作的工做，而且在每一次工做中都让他们不断加强自信心，并且提升本身的技术水平，你的组员怎么会不听你的指挥。

做为一个项目负责人要敢于决断

做为一个项目负责人要敢于决断，项目负责人是最了解项目的管理人员，不管是用户、组员仍是测试人员和质量保证人员以及客户都是以项目负责人为中心的，这个地位决定了项目负责人应该是对项目最了解的人，那么他在关键时刻的判断和决断就对项目起着关键的做用。而做为项目负责人若是不敢和不能决断的话，必然给项目的开发形成极大的困难，说两个故事：

一个是个人哥们，有一次他去客户那里没有参加技术讨论会，回来的时候，他的开发人员的讨论会还在激烈的争吵着，见他回来了，分红两派的开发人员就让他来判断哪一个算法更好，个人哥们听了一会说，我来告诉大家如何取舍，因而从兜里掏出一个硬币，正面用A方案，背面用B方案，而后一扔，因而结果出来了，当时我听了这个故事直笑，问他为何这么作，他说，我不搞技术不少年了，但听他们说得，两个方案差异很少，不过是A+B=C仍是B+A=C的问题，这个时候若是你去参加参加讨论，不管采用A仍是B都要费不少的口舌，而有那个时间早开发出来了，因而就想了这个方法，固然采用这个方案的时候，开发人员都看傻了，别忘了给你的开发人员讲解一下你为何采用这样的选择方法。

另一个项目就颇有意思了，表面上这个项目负责人很尊重开发人员，每周都要开一次周会，并且开会的时间还不短，可很快开发人员就不在会议上发言了，有一次和他们组的开发人员闲谈的时候，问他们为何不在会上发言了，那个开发人员告诉我，每一次提出问题，项目负责人都是侃侃而谈一番，没有任何实质内容，最好的状况是说这个问题下面让某某来谈，因而坐在一边不说话了，更多的状况是说这个问题很重要，咱们先放一放，下回讨论，但是问题既没有记录，也没有安排人去作专门的研究，每每是不了了之，一次两次，慢慢的开发人员都认为提的问题不可能获得解决，因而每次的周会就成了项目负责人的独角戏，而其余人员的手机发短信的水平，以及图画水平倒提升了不少。

不少项目负责人每每感受本身的权威性不够，常常会说给我这个权力那个权力，我就能够怎么怎么样，其实，项目负责人的权威不是创建在对开发人员的工资或者其余的控制上，而是创建在你的作事方法，开发能力等这些软件水平上的，若是在你的组员遇到问题的时候，你能够为他们解决，提出可行的解决方法，什么和他们一块儿患难与共的去完成那些最艰难的问题，你的组员怎么会不信服你，你又怎么会没有威信呢。

对不一样的人员采用不一样工做的方法

做为项目负责人最重要的一个特色是要细致，在安排和检查工做的时候尤为要细致。对待刚参加工做的工做人员和老工做人员也要区别对待，通常来讲，刚参加工做的人员工做热情都比较高，但工做方法的掌握都会有一些这样或者那样的缺陷，如何作到既不打击他们的工做热情，又防止他们的工做走偏是一个很重要的事情，我带项目组的时候，有一次给了我四个刚毕业的工做人员。我给本身定了几个原则，1要大胆使用他们，2要帮助他们解决主要的开发问题，3检查工做要仔细，防止工做出现大的误差，4分层次，区别使用，尽可能做到用对他们。

一、大胆使用他们，新同志通常工做都会存在这样或那样的问题，并且有时候问题比较明显，我原来也以为使用他们不如本身开发快，因此老是越俎代庖，这样的结果就是我本身累得够呛，开发人员闲得要命，并且工做情绪不高。为了防止这个问题的发生。这回我努力克制本身开发的欲望，将全部的设计、编码的任务都安排给他们，本身只负责整体设计、关键技术问题的解决和工做的检查。事实证实，只要你控制得好，开发人员都会比较好的完成开发任务，并且在开发过程当中进步也是很明显的。个人这几个开发人员因为我勇于放权，不但开发完成的比较好，并且经验的积累也比同时间来的开发人员要快，很快成为了单位的开发骨干。

二、放权不是无论，而是该管的管，不应管的无论。对于新同志他们都有必定的开发能力的欠缺，但主要问题体如今两个地方，一个是设计能力，一个是开发的规范性。整体设计是我来作的，而后给他们逐步讲解，使他们了解我这么设计的目的和方法。再让他们作本身部分的设计，开始这是很困难的事情。由于咱们的系统须要很强的可扩充性和维护性，因此不少方面的设计方法和他们原来的开发有很大的区别。而他们在学校作的设计根本不用考虑系统的可扩充性和维护性，因此在不少设计思路上彼此差异很大，我不但要完成设计，讲解给他们听，并且要让他们接受个人观点，说实在的真是很困难的，我采用了和实际相结合的方法，告诉他们每个设计的目的和实现的方法，若是他们有不一样的设计也能够，你们一块儿讨论，若是他们的设计能够知足系统的需求那么我也很乐意接受。另一个是开发的规范性，咱们的同志在学校的时候基本上都没有接受过规范性开发的培训，而这是在实际工做中必须特别强调的东西，好比代码的规范性、文档格式的规范性等，我就做为强制执行。固然若是一味的强调这是规范必须执行仍是不够的（容易产生逆反心理），在具体执行过程，还要和他们去交流。好比如何写文档效果会比较好，如何避免有话说不出来的问题，通常来讲，我都采用他们先写文档（或代码），我来检查，而后讲解，他们再修改。再检查、讲解，（编码也是同样），通常来讲，第一次的文档他们会写4-6次，但通过一次这种训练，他们的文档撰写水平和编写代码的规范性就能够过关了。

三、新同志的工做周期我通常安排是1.5---2天的时间。通常来讲。新同志的工做我都安排得比较细，他们的工做都在一天以内能够完成，这样主要是防止工做出现比较大的误差。并且即便出现了问题，我也能够及时发现和调整，不至于对工做形成太大的危害。工做检查不是一个简单的评判过程，更是对他们的一个培养过程。一些工做方法，工做技巧都是在这个时候教授的。在这个环节要特别注意简单粗暴地对待开发人员，必定要将问题讲透讲清楚，最后还要让开发人员再讲一遍你的讲解内容和后面的工做安排（很重要的，在你听他们叙述的时候，每每会发现他们的理解和你的想法有很大的差异），防止交流的无效性发生，通常来讲新参加工做的人员若是真接受了你的观点，使会主动改正他本身的问题的（虽然会有反复）

四、即便是新工做人员，也会有很大的差异，做为项目负责人，要善于发现发现这些差异。好比在这个项目中，有一个工做人员做过OA项目（毕业设计），对OA的理解比较多，那我就让他负责系统最重要部分的设计，有的人比较细心，就让他负责配置管理，有的人比较善于钻研，就让他负责权限管理部分的设计（那部分比较难），总之，没有不可用的人，关键是看你是否用的对地方。只要用对地方，即可以达到事半功倍的效果。

学会向用户汇报工做

固然了，也包括领导汇报工做。道理基本同样。说一个在科委项目的课题的故事吧，那个课题是一个作的不太好的项目，用户对咱们很不满意，项目负责人被撤了，开发人员也都走了，让我接手这个项目，个人目标是完善项目，个人项目经费（还有40%），其中的开发工做就很少说了，只说说向用户汇报的事情，用户的领导是一个50多岁的大妈(大妈是很聪明的，不然也不会在那里作到这个职位)，对咱们很不满意，开始的时候，我坚定认可错误，毫不隐瞒（得到对方的承认），其次在后来的时候每次去用户那里，我都会琢磨一下是否要去向她汇报，若是没有过重要的事情，就想一想最近在作什么事情，这样在见到大妈的时候，能够汇报，若是真是须要汇报，就要特别考虑一下几个问题，一是我如今的工做进展，二是我遇到的问题，三是问题那些是我能够解决的，何时会有答复，四是什么问题须要用户配合。（好比硬件设备的改善等）具体配合的内容是什么。在汇报的时候，我会私下掰手指头，一个问题一个问题说，防止遗漏，同时要记住对方的回答。这样几次以后，大妈对个人感受很好，后边的工做就好作了，后来项目顺利完成。经费天然也回来了，因此在和用户汇报工做的时候要特别注意几点：

一、项目是最重要的，不管你采用什么做客户关系的方法，项目或产品必须过关，不然一切都是无用功（国家项目不必定）

二、在汇报的时候，态度要认真。特别是出现问题的时候不要一味推卸责任，讲理由，这是没有效果的（在单位汇报工做的时候也同样，没有人会理会你的理由）

三、汇报以前必定要准备，这样条理清楚，事情完整。防止由于一点小事情连续打扰客户。要让客户在每一次交流时都有很大的成果。

四、汇报的时候要掰手指头，主要是防止问题的遗忘，特别是你们在就具体问题讨论的时候容易干扰你的思路，使你遗忘事情。

五、在汇报以后要将全部问题都过一遍，是否全部的问题都有解决方法了，若是什么事情不清楚，立刻问，这样总比再次来好，在说出来，和用户一块儿确认问题的解决方法。

六、实在怕遗忘，最好带一个录音笔，但千万不要让用户看到，也不要用这个东西做为之后争执的证据用（没有好处的），只是做为资料整理的一个备份，不然用户会反感而不配合你之后的工做。

(李超 IT商业新闻网)