现在的位置: 首页 > 综合 > 正文

研发人员为什么留不住?

2013年08月17日 ⁄ 综合 ⁄ 共 3905字 ⁄ 字号 评论关闭

研发团队做为公司的核心,承担了完成项目为公司赚钱的目的。研发人员在公司倍受重视的同时,并没有降低流失率。

问题与现象
以下问题相信您会在朋友口中,甚至自己的公司听到。

老板说:“为什么找不到合适的人?找到了又不好、留不住呢?”

HR说:“招聘和考核机制已经很完善了,为什么研发人员还是不好招,招到了又不愿意被考核?”

研发总监说:“现在有人都零薪水求职了,我们还是找不到人?留不下人?”

研发经理说:“为什么便宜的人不好用,贵的又不符合我们的企业文化呢?”

开发人员说:“谁真正关心过我的发展?再不涨工资,下月开始找工作了!”

求职者说:“我期望薪水都跌破成本价儿了,还是找不到工作?”

与上面问题相对应的,是我们在经常看到的若干现象。

现象一 招聘难
在初级研发人员方面,招聘不到有非常潜力、能成为公司未来支柱的新手;中级研发人员方面,招聘不到有经验、愿意为公司付出且价格合理的老手;高级研发人员方面,即使通过猎头也很难找到能解决核心技术问题、高度忠诚的高手。

现象二 考核难
对公司现有研发人员的考核如果不是形同虚设,那么基本就是三不满意的状态。公司高层不满意考核之后大家的工作状态;研发不满意考核的结果,多数是只扣钱不加薪;HR不满意研发人员针对考核的态度。

现象三 留人难
从表像上看,很多研发人员一不顺心就拍拍屁股走人,之前没有任何征兆。这不但给招聘造成了很大的压力,同时还严重影响了项目进度和公司的利润。

现象四 没赢家
如果研发人员离职,那么这就是场没有赢家的博弈。公司因为人员离职耽误了进度,影响利润;HR要花费更的的精力去招聘新人、让新人熟悉;研发管理者还要给新员工从头传授相关项目信息;研发人员本身要承接新环境所带来的种种风险。

产生这些问题的原因是什么?详见下周更新的文章。

问题产生的原因
导致以上现象发生的原因不外乎以下几个:

人的原因——永远不要考验人性
可以肯定地说,所有项目和公司中产生的问题,无论是管理层面、销售层面还是开发层面,最终都可以归因于人的问题。这里我们把讨论限定在项目开发上面。

研发人员自身的特点导致了替代成本高。

任何研发岗位上,要招聘到从能力、经验至潜力都合适的新员工,平均失败3次左右,即,招聘到合适新员工的代价都要3倍于保留1位老员工。公司损失的不只是工资这么简单,损失的是收益,老员工离开会带走项目经验、知识和团队凝聚力。

老板难道不清楚这些吗?这样还要放走老员工?

请永远相信,能做到老板的位置上,很多事情是相当清楚的。从公司总裁级别、研发总监直到项目经理,每个人都能看清楚,人员流失带来的巨大问题和潜在危害。了解重要性是一回事,能把人留下是另一回事。更多企业做的是:招聘到新的开发人员,等新的开发人才成长之后变成老员工,然后就跳槽去其它公司,再然后再招聘新的研发人员,还没走的是因为没找到更适合的地方——培训学校成为了公司不愿意看到,但是又找不到有效决方案的事情。

制定考核方案的人不了解被考核者。

一般公司的考核机会是谁制定的呢?多为HR出台框架,再与研发管理者沟通,继而出台。因为这只是HR工作的一部分,甚至很小的一部分,HR关心的是尽快把这项任务完成,好去干别的;研发管理者则关心项目能如期完成,基本要素,外加按事件考核成了研发考核的基本思路。

机制出台后,很快变成每月领导给下属下次分,按分扣或者拿绩效工资。周而复始。

但是,要考核的又不是冰冷的机器,此类考核方法是否考虑到人的因素呢?有没有考核到人的成长呢?很少。在大机器化生产线上可以这么干,你每月出多少次口就扣多少工资。在脑力密集型的开发领域,此类考核方案效果之差,应该说有目共睹。

 

 

建立从人的角度出发的,有效的考核机制才有可能能留住人,之后才能招聘到企业真正需要的人。

 

——没人坏人,只有让人变坏的制度
很多不从研发人员其实出发的“考核制度”,执行起来直接导致了如下后果:想留的留不住,考核的目的看起来像是在考核研发人员的心理承受极限,逼着人离开,要么就是逼着大家全面拿出“混”的态度来对待工作;应该有的没有,没讲怎么晋升,公司研发人员也看不出层次,加上薪水背靠背,从制度上鼓励大家混;只以目标为标准,毫无人性可言,研发人员成了生产线上的螺丝。

这世上从来没有坏人,只有让人变坏的考核制度。

就拿销售举例,有些公司新来的消息多诚实肯干,但过了一些时日,就变成了与老销售类似,虚报费用、吹吹拍拍。与其说是人性导致,不如说是制度使然。

请不要片面理解“考核制度”这个词,写在纸上的东西,比如:不能迟到早退,再比如每个月经理给属下打的考核分数,只是制度显性的部分,也是很小的一部分,还有很多隐性的部分和做事风格是体现在工作中而未写在纸上的——这些没写在纸上的做事风格和方法叫“企业文化”。

坏的考核制度有如下特点:

ü  不能让研发人员了解自己在组织中的位置,自己的薪水在行业或者公司里处在什么水平,是否与自己的能力相吻合。加薪从此变成没有依据的事情;

ü  不能说明开发人员的晋升路径。开发人员并不知道自己的职业之路应该怎么走,多少年之后会达到什么级别,不明白自己应该如何努力。升职变成了不可能的事情;

ü  奖惩不分,让人只看到惩看不到奖。本应是萝卜加大棒的研发人员绩效考核,在被考核人看来只剩下大棒的情况并不少见,甚至连大棒都看不见的也是屡见不鲜,考核有时都变成了政治斗争的砝码——用来收拾不顺眼的人,而非留住有用的人。有效考核变成了梦。

如此考核制度的存在,不但激化了HR与研发的矛盾,还会导致人员的不稳定,君不见公司人力资源部最重要的任务就是不断的招聘,不合适了就再招聘。多数人人打工时想“要不是看在钱的面子上,我才不在这儿干呢!”,员工与企业的关系沦落到这般田地,就成了赤裸的金钱关系。但是钱能有多大面子呢?而且,肯定会出现更有面子的企业,可以给出更高的待遇,某种程度上的内外夹击导致了人员的流失。

上次,我们谈到了留不住研发人员的制度的原因,今天说说方法的原则并介绍我们的接下来的打算。

方法的原因——解决了方法的人问题,可能也解决了人的问题
研发人员的管理方面,有人迷信关系,比如:老板跟客户关系铁,开发的不好没关系,可以再来,我们再招人;有人迷信制度,比如:我们过了CMMI几级,开发一定成,我们用了KPI、平衡记分卡,考核没问题(有多少人知道科学制定KPI的方法,又有多少人知道平衡记分卡真正想表达的意义?);有人迷信人,比如:我们的研发总监曾在500强任职,领导的一定好。

不同的观念导致了不同的管理方法,不同的管理方法导致了不同的结果。迷信关系的会因开发效果不理想,伤害关系拿不到下一单。拿研发人员不当人的公司,研发人员也从没考虑过把公司当归宿;迷信制度的会因贯彻难度大而使制度最终形同废纸,研发人员还是用的自己那套。你有千条计,我有过墙梯。大家都只用自己顺手的;迷信领导能力的会因个别人的离开导致项目崩盘,一发不可收拾。这年头儿,除了亲戚关系能保持一辈子,合作创业都有散的。

找到适用于企业的方法才是最重要的。

“研发人员价值最大化”培训与咨询服务介绍
 

最近,朋友介绍了某家公司的研发项目经理Tom给我认识,我希望这家公司能请我做培训或者咨询。对我们之前的培训和咨询成功案例介绍后,Tom与我进行了沟通。

 

Tom:“我们研发有套KPI考核体系了,对你的培训和咨询应该不需要。”

Leo:“挺好的,目标考核。我的培训是讲如何从人的角度考核,程序员又不是机器。”

Tom:“人的角度?如果人连目标都没有能制定考核指标吗?是不是有点可笑?”

Leo:“你用的是KPI的角度,没什么错。我也没打算包打天下,只尽量解决研发中‘人’的管理问题。KPI考核并没有说你手下的研发人员处在什么级别,更主要的是,这些研发人员并不清楚自己下一步怎么发展。研发人员完成的是一个目标+下一个目标,他们自己没有明确的晋升之路,至少KPI考核没提供。当然了,KPI有自己的长项。”

Tom:“那你的意思是研发人员的职业规划角度?”

Leo:“是的,研发人员的发展。我想知道贵公司研发人员在什么状态下可以加薪、什么时候可以升职、考核是什么标准?”

没想到Tom突然骂了起来。

Tom:“NNGX的,加薪、升职没标准。老板也不谈,我们部门领导也不谈,除了每年固定加的那点之外。”

Leo:“嗯,我的培训就是解决这个问题的。人人都高兴不敢说,人人都能服气是真的。”

Tom:“公司最近没这方面的预算啊!”

Leo:“没事。我们的原则如下:

情况一:公司在“研发人员价值最大化方面”完全没预算(说白了就是没钱),只要关注我的博客就可以了(http://blog.csdn.net/jobchanceleo),我们会持续更新这个系列,会写地很清楚、并完全提供相关方法和模板,清楚到看明白之后可以自己动手实施;

情况二:公司在“研发人员价值最大化方面”有预算且在5000元左右,我们建议采用我们的培训服务。我们会相关培训课程,包括:

1、研发转岗管理应具备的素质

2、研发人员的绩效考核与激励

3、员工归属感与职业生涯规划

4、非HR经理的人力资源管理

5、有效招聘流程的建议与保持

情况三:公司在“研发人员价值最大化方面”有预算且超过3万元,我们建议采用我们的咨询服务。我们会提供从前期情况调研、培训、研发人员评审指导的系列服务,同时还赠送:研发人员职业生涯规划评测与建议、辅助招聘、校园宣读会”

Tom:“我们会持续关注你的博客的。”

Leo:“好的。我也会持续更新。”

 

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/jobchanceleo/archive/2009/06/23/4290428.aspx

抱歉!评论已关闭.