程序员走向管理职位需要注意的地方

很多程序员写了几年程序，也会慢慢走向管理职位。没有人天生就懂管理，大家都是在工作中慢慢一点点地学的。那么刚进入管理职位，有什么地方要注意，如何顺利进行角色转换，与团队融洽并开展各种项目，等等，都是这篇文章关注的事情。

下面列出一些常见的通病，这样的经理无处不在，或许你周围就有，或许你现在的领导就是，或许你就是。多点思考，多点改进，你就能成为好领导。

1、不明确自身的职责

你不再是个码农？公司聘请你不是为了让你去写代码，而是让你去带领你的队伍干大事。别整天埋头啃代码了，这些事有其他人干就行了，正事都干不过来呢。就算是一种偏爱，那就业余时间自己研究去。计划任务执行、各组分工、与其他部门协调、团队建设等，这么多事都还没干呢？或许根本不知道有这些事。别整天忙忙忙，又不知道在瞎忙些什么。等到该干的事情时，又开始喊这个喊那个，问东问西。让人感觉你“业余”。

2、关注点偏低

在讨论设计方案时，经常会太具体，哪个逻辑怎么写，用什么算法，甚至是哪个字段如何命名。对于一个经理人来说，这些都不是你该关心的。你手下那么多小兵呢，如果总是这样，不累死你。而且手下的人更是手忙脚乱，而且极大的影响士气。代码不规范，应该建立适当的代码规范加以约束。员工素质不高，需要多进行培训，集中学习。这才是管理者应该关注的。

3、不懂得团队建设

跟你干活的这些人，不是机器人，也有累、烦的时候，如何调节这些人的心态很重要。跟你当初写代码时候不同了，并不是写完这个功能就完事了，硬活每个人都能干，可是对于沟通、团队建设这些软内容，并非每个人都能成。这个才是辨别一个领导是否能够胜任的主要因素。不懂得发展自己的团队，即使你是技术大牛，即使你经验十载，也不配做个合格经理人。

所谓众人拾柴火焰高，这些人召集在一起，要团结，然后给定一个目标，每个人共同为目标而努力，才能事半功倍，实现1+1>2，体现团队的优越性。如果这个主导人没有发挥作用，长期以往，人员变动频繁，干活的人唉声叹气，整个工作气氛死气沉沉，工作效率低下。天天被员工背地里骂（毕竟你是领导，人家得给你面子）。最后弄得人心涣散，团队散了，项目完了。

经常组织活动，丰富大家的课外生活。既能增进彼此的了解，也能增加大家的幸福感。并且，团队的凝聚力、也在潜移默化中有所提升。

4、自命不凡、顽固不化

平心而论，程序员都有点小坚持。当然不是他们的错，可能每个人都有这个性格吧。自己辛辛苦苦做的东西，当然不希望被别人指指点点。但是这种习惯不能带到经理级别。虚心听取职员的合理化意见，而不是总是顽固坚持自己的。这种自命不凡的家伙总是树敌。就是当年的皇帝还纳谏呢？何况是个底层干部？

5、批评多多，吝啬鼓励

对于一些程序员出现的问题，不能一棒打死，即使代码写得的确很烂，但是也要中肯的给予一些合理化建议，万不能

“你这是写的什么？Shit!”。

有的甚至比这还惨，

?“找个不会写代码人比你写的也好，这么多年白学了。”

现在什么都双面选择，人家给你打工，不是你的奴隶，毕竟二十好几，有的甚至年过三十，这样苛刻的语言，有几个能容忍的了。直接怕屁股走人，即使忍痛留下来，工作积极性也会大打折扣。工作本该是轻松友爱的气氛，这下成了死敌较劲。境况可想而知。你就多鼓励下，“这次没干好，下次努努力，私下下功夫夯实下基础。”“这次有进步，干得不错。”“很好很强大，大家辛苦了。”尽管是简单的几句话，在员工心理可能引起蝴蝶效应，更加努力为你卖力。

6、会议太多太长

领导的会议总是很多，特别是一些新领导。也许他们认为只有开会才能显示自己的权威，只有开会才能了解项目进度，不能说你不可以开，这是当领导的权力。但是一定要严格控制频度和时间。每天都有说不完的事，真想不到这个经理怎么当的。并非开会说的都是正事，其实大多时间都是扯皮。与其浪费在这里，还不如让你的员工多花点时间在工作上。希望员工对领导的印象不只是开会、扯皮。

现在讲究敏捷开发，这不是一门技术或者一门学问，而是一整套体系，如果领导都不带头执行，那员工如何执行？

7、领导太多，管理混乱

当然这个问题不是针对某个领导，而是说一个公司人事架构内，不要太复杂。

如果结构复杂、层级繁多，造成责任不明确，遇到问题，不知道找谁，层层往下推，最后到了程序员手中可能跟最初的要求大相径庭。

还有一种情况，有的时候遇到问题，客户直接跟上级通了电话，而上级也不了解情况，直接揽下，问了开发经理，才知道这样的修改不合理。中间也可能有更多级，开发人员拿到任务，明知道不合理，但没办法，很难驳回“上上上...级”领导的决定，只能在产品里堆垃圾。

在一个部门中，也可能有类似的情况，有多个开发经理，遇到工期比较紧张的时候，可能几个开发经理通知给一个开发人员下达任务，有时候部门经理也可能下达任务，这个人很为难，到底怎么做？先做谁的？每个都说很紧急。这就是管理混乱的表现。任务下达要责任到人，最好不要越限下达，因为你不了解每个人具体情况。一个开发人员的任务情况，只有其开发经理最熟悉。如果是部门经理下达任务，首先下达给开发经理，然后由开发经理下达给开发人员。如果其他开发小组需要其他人帮忙，则需要向部门经理申请，有部门经理协调，然后下达任务到开发经理。这样一切都清晰多了。

这些可能是“升级经理"的通病，希望大家：有则改之，无则加勉吧。

本文地址：http://www.nowamagic.net/librarys/veda/detail/2235，欢迎访问原出处。