一哥们混了5年，今年终于开始做项目经理了，一上任就是带开发团队，对于一直以来都是做实施的他来讲，开发团队的项目经理还真是有不小的挑战，但也许这将成为他职业生涯的一次重要的转折点。虽然我们关系不错，但一般我们都是QQ，难得的是，今天居然给我致电了，所谓无事不登三宝殿，原来他是知道我之前也带过几个开发人员的小团队，所以想走走捷径，取取经，而我其实也就带过两个做开发的哥们，一个java高手，一个java、c#的新秀，不过由于工作变更，现在都离职了，所以这方面也没办法给到他什么丰富的经验和帮助。
不过毕竟自己也学过开发，并且与程序开发工作也有过1年多的照面，所以就简单了同他分享了一些我的个人心得：
[@more@]Q：程序员应该怎么管理？
A：这哥们问题问的好宽啊，实际上程序员说好管也好管，说不好管，还真是比其他岗位不好管理。因为程序员大多比较沉迷于技术，不善于表达，而逻辑思维能较强，我感觉大多程序员还带着点闷骚，他们喜欢游戏，喜欢看美眉图片，喜欢逛论坛，不喜欢别人对自己的代码指指点点，即便你是他的项目经理。他们不喜欢自己的成果被大家反复的修改，不喜欢业务需求不断的变，他们有时讨厌测试人员，因为测试到最后，他们又要修改，有时又很喜欢测试人员，因为有一大群人来帮他验证自己的代码是多么的牛B。所以说，好不好管理，完全看管理者的度，处理问题要适度，对人对事要大度。程序员并不是一个特殊的行业或工种，开发这些事也不是那么深不可测，所以当作为项目经理，应该更体谅开发人员的工作量及情绪，更了解他们的诉求，更关心他们的成果，多做有用的沟通，少写无用的代码。要把他们当做自己的左右手，而不是下手。
Q：技术好的人好像都挺牛？
A：呵呵，要不然怎么叫“大牛”呢，有实力才有底气，这种应该是正常现象，而也有很多技术大牛依然保持谦虚，当一个技术好的人很牛的时候，无疑会有以下几种可能：1、别人提的意见或领导的安排不合理，或不符合技术规范，在他们的经验里，就不应该这么搞；2、对自己有绝对的信心，或者是在向他人证明自己的实力；3、有点自负，这样的人不会走得太远，因为他不懂得一山还比一山高。当然，不排除有的哥们就是直来直去的性格。所以，作为项目经理，我们不应该过分在意性格、态度，而应该更在意他们的成效。做技术还是要以成果为最佳评判标准，开发工作也是比较好量化的。
Q：程序员怎么考核？
A：不知道别的项目经理是怎么考核的，我一般都是采用ASK三个维度考核。A：态度（attitude），这个态度指的是他对这项工作的热情度和认可程度，对自己工作的认真努力程度，这项当然是定性的，也就是说主观色彩会影响可观判断，同时，也是项目经理做强制绩效排序时最好、最灵活的评价标准；S：技能（skill），这个标准是考核技术人员最重要的标准，归根结底，他的绩效还是要通过个人技术能力来体现，代码写的严谨且优化、效率高，是否能按照计划完成，异常处理快等等，都可以作为这一类考核标准；K：知识（knowledge），除了技能和对工作的态度外，还要观察一个人知识积淀，比如对于版本控制，权限安全控制，代码书写规范等是否是很严谨和标准，是不是能为自己团队问题库、知识库的积累做出贡献，是不是较宽的知识面，同时也可以让他们不断做技术分享来考察。
Q：如何判断一项工作要安排多少开发人员？
A：这个目前还没听说有这种量化的指标，每个人的工作效率又快又慢，不过我听过这样一则笑话：“项目经理: 如果我再给你一个人,那可以什么时候可以完工？程序员: 3个月吧！项目经理: 那给两个呢？程序员: 1个月吧！项目经理: 那100呢？程序员: 1年吧！项目经理: 那10000呢？程序员: 那我将永远无法完成任务。”所以说，不是人手越多越好，开发和搞革命不同，不是人多力量大，人多了反而很难把控，比如大家写的模块分工太细或不清晰，版本控制不规范，源代码安全问题，每个人手法不同，程序异常增加等等。只能说做项目经理，要根据时间、成本、工作量、人员做最合适的规划，项目管理没有对错，只有合适与不合适，不要忘记，项目管理还有一个“渐进明细”的法则。不行就变更嘛。风险控制好了就成。
Q：项目经理要做什么？
A：看多大的项目了，小项目的话，可能什么都要做，甚至写代码，大项目的话，理论上来讲只需要启动项目、编写项目章程和计划，然后就是做项目监控和变更管理就行了，具体执行可以交给团队成员，最后风险控制，人员遣散，项目验收。管理需要很高的情商，尤其是项目经理，往往团队成员只有在项目期间归你管，项目结束后就各回各家，管你狗屁项目经理。高情商的项目经理会觉得项目管理非常简单，闲半个身子，动动手指就行了，情商不高的项目经理就寸步难行了，他发现什么事情都不顺利，开发人员和他对着干，业务部门不配合，每天在项目要不要满足业务需求和怎么满足这些事情上发愁，授权少了，自己累得够呛，授权多了，又把控不住。做好项目经理，首先要懂人、懂管理，而不是先学PMP。
Q：需求经常变怎么办？
A：需求变更是项目经理遇到的最频繁的问题了，刚开发好的程序，业务又要改，还记得我们刚开发CRM的时候，开发那哥们每天忙的都吃不上饭了，每当遇到需求的时候，也是开发人员最头疼的时候，他们多么希望自己的领导能英明神武的把这些需求给干掉。但是既然我们是吃这口饭的，就只能认命了。作为项目经理先考虑的不应该是如何满足业务需求，而是要先规划好这项工作的难度及意义，同时考虑开发人员的承受能力。不应该一味的接需求，由于怕客户投诉就120%的答应客户，要想着还有一般兄弟跟你混呢。需求是无限的，服务是有限的。要会适当规避不合理的需求，把合理的需求做的更合理，以至于让客户下次再提到这个问题时都感到无理。减少无用功，不能用试着看的想法，“试着看”在很多领域都能获得成功，但在项目管理中很多时候会造成太多的无用劳动，带来太多的抱怨。
不知不觉，和这哥们竟聊了2个多小时，真是3年不通话，通话说3年啊！我也没有什么好的资源和经验来帮助他，只能以一个朋友和同行的身份为他加油！
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17254424/viewspace-1059805/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/17254424/viewspace-1059805/
扫一扫
3083
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
