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

新升经理人要警惕的事情
服务器君一共花费了152.780 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

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

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

1、不明确自身的职责

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

2、关注点偏低

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

3、不懂得团队建设

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

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

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

4、自命不凡、顽固不化

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

5、批评多多,吝啬鼓励

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

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

有的甚至比这还惨,

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

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

6、会议太多太长

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

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

7、领导太多,管理混乱

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

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

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

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

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

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

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2235

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《编程珠玑(第2版)》 Jon Bentley (作者), 黄倩 (译者), 钱丽艳 (译者)

《编程珠玑(第2版)》是计算机科学方面的经典名著。书的内容围绕程序设计人员面对的一系列实际问题展开。作者Jon Bentley 以其独有的洞察力和创造力,引导读者理解这些问题并学会解决方法,而这些正是程序员实际编程生涯中至关重要的。

更多计算机宝库...