项目-团队-技术-个人(提拔篇)

简介:

是团队,就需要领导。领导从哪里来呢?途径可以有多种:

1、从团队提拔

2、从内部找

3、从外面找

。。。。。可能还有其他方式

其实不论是从团队提拔还是去找现成的,这个人都是从一个团队脱颖而出的,都可能是从基础做起,在团队中表现出色之后被提拔起来的,只不过可能是在来公司之前,在其他公司的团队被提拔起来的。

本文就和大家说一点关于“提拔”的个人想法。

提拔一个人,通常做法是找那些能干的,肯加班的,任劳任怨的,工作能力在团队中是突出的。叫过来“小张,明天开始你就是项目经理了,加油,努力,要负起责任来。”,然后在团队中宣布一下“从明天开始,小张就是大家的项目经理,以后有什么事情先和他沟通一下,请假之类的先找他批一下。”

从第二天开始,小张就更加努力了,回家比以前还晚,干活比以前还卖力,但是过了一大段时间,发现这个团队整体没有什么提高,反而小张也不如以前能干了,怎么回事呢?这次提拔怎么了?这种提拔合理吗?是小张不行,还是提拔有问题,还是????

今天,给大家分析一下我个人关于类似问题的看法。

首先,我认为提拔一个人,看这个人的表现是没有问题的,表现和能力肯定都是考量的一项,也应该从这两方面入手。但是是不是这样就行了呢?需要其他的吗?我觉得还是需要的,有重要的一点好像忘记了,能否承担责任,对于责任的理解也是很重要的,以及愿意承担责任之后,需要做哪些改变,从哪个角度做,如何做,都会决定本次提拔的结果。

经过我的思考,我觉得有以下几个需要注意的地方,或者说有以下几个程度可以参考。

1、首先要看一个人是否愿意承担责任。

这里的责任是指为团队负责,为项目负责,为整体负责,而不是为具体的工作负责。身为基层领导,不是给你权利,让你风光的,也不是给你一个头衔,想要累死你的,是让你承担团队的责任,让你担当的。

如果一个人愿意承担责任,我认为具备了提拔的基础条件,他的具体技术能力都不如这个重要。一个人不愿意承担责任,千万不要提拔,不要因为他能干就提拔,不要因为想要留住他就提吧,留住一个人可以有很多种方法,提拔一个不愿意承担责任的人,后果不堪设想,超级失败吧!!!

2、其次要看这个人在愿意承担责任的基础上,是否愿意改变自己来适应新角色。

愿意承担责任就行了吗?就可以适应新角色,进而做好新角色了吗?提拔就成功了吗?不。

因为新的角色需要新的技能,需要新的思考方式,需要新的做事方式。因为面对的下级和上级都发生了变化,以前面对具体的难题,没有下级,上级也只是关心的代码是否完成,具体的工作是否做好。现在不一样了,你是个小领导了,你的上级是更高层的领导,他们关心的不再是具体的功能是否完成,你的下级是具体的人,你需要关心他们在解决问题的时候遇到了什么问题,而不是让你解决具体的问题。

很常见的现象是,在提拔了一个工作能手之后,他还是疯狂的编写代码,做自己的工作,上面呢,也还是习惯把最难得,最重的,最繁琐的事情交给他去完成,就因为他过去完成的好。这样从自身和外界都没有转变角色,可是同时又需要他抽时间关心团队成员,团队成员的心态是否有波动,技能是否需要提高,能否适应当前项目的发展,成员对于自己发展有何诉求,项目的进展,在哪里卡壳了,等等。。。。。。。。。。。

当然了,还有可能就是他这个人就不愿意做出改变,就是愿意深入研究技术。

上面两种情况,可以说这次提拔是失败的。而且是浪费人才,浪费了一个能干的家伙,提拔了一个不称职的领导,相当的失败,双重失败。

我认为,发生上面的情况,坚决下放,将提拔的人下放会原来的岗位,或者找新的适合他的岗位给他,这样对他自身也是提高,鼓励一个人、想留住一个人不见得非得给他一个官职当当。这是我们中国人做事的问题。

3、再次,要看他的改变的结果

一个人,愿意承担,也愿意做出改变,是否就可以了呢?提拔就成功了吗?不。

经过前面的两次,这次提拔已经成功了70%了。最后的30%要看这个人的改变结果,才能决定本次提拔的最终结果。

就是说,这个人在改变的过程中是否顺利,他是否适应了性的岗位,改变的结果如何?他再新的岗位是否发挥了作用,没有发挥是因为自身没有学习到,没有理解到,还是因为相关资源配合的不好,还是人际处理有问题,要及时的观察到,及时的给于解决,而不是任由他自己发展。

如果改变成功,说明本次提拔很成功,人选对了,岗位合适了,而且还有下一次提拔的基础,这个人的发展也就越来越顺利了,公司自然因为选对了人,后续工作都好做了很多。

如果改变不成功,或者一般,这个人还是付出了很多,就是因为学习能力,接受能力,理解能力确实很难提高了,也没有办法,人和人是有差距的,这个不能不承认。没有关系,就让他在这个新的岗位上继续干吧,反正差也不会差到哪里去得,一个人自己愿意承担,愿意改变,也作出了改变的努力,我认为肯定会有成果的,可能成果较小,总比提拔一个不愿意承担,不愿意改变的好多了。

总之,提拔合适的人到合适的岗位。而且,提拔不是一次性工作,是一个持续的工作,需要后续的配合。




在路上




本文转自 virusswb 51CTO博客,原文链接:http://blog.51cto.com/virusswb/745328,如需转载请自行联系原作者

目录
相关文章
|
11月前
|
运维 NoSQL 关系型数据库
带团队后的日常思考(十)
带团队后的日常思考(十)
|
敏捷开发 机器学习/深度学习 搜索推荐
如何做好创业公司研发团队的项目管理?
探讨创业公司中的软件研发项目管理问题: 大部创业公司的软件研发管理处于什么阶段? 如何改善软件研发过程和提高效率? 软件研发过程会涉及哪些工程理论和方法?
285 0
如何做好创业公司研发团队的项目管理?
|
存储 数据采集 SQL
为什么你成为不了团队核心成员
为什么你成为不了团队核心成员
88 0
|
运维 监控 NoSQL
带团队后的日常思考(一)
  由于公司规模并不大,因此一有事情就会拉个会议,例如需要大会、技术评审、汇报周会、突发会议等。一周中大概有20%~30%的时间会花在大大小小的会议上。
带团队后的日常思考(一)
|
SQL 小程序 测试技术
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
|
缓存 运维 前端开发
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
|
缓存 监控 前端开发
带团队后的日常思考(二)
  经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。
带团队后的日常思考(二)
以人为本--创建最好的开发团队
以人为本--创建最好的开发团队
528 0

热门文章

最新文章