摘要:研发部门之间工作“忙闲不均”,主管部门或人员是研发老大,HR发现或听到、观察到的问题或现象,不一定是全貌或真实的东西,一亩三分地,还是找“主人”为好,手不要“伸太长”了。
公司几个研发部门的程序员忙闲不均,怎样合理使用他们,站在HR角度,建议如下:
1、不要看表面
题主描述中提到几个现象,略分析如下:
1)忙闲不均
提到“有的部门很忙,有的部门有点闲”“人员得不到合理配置”,就难道说明:
人力资源当初招聘或者用人部门当初提出招聘申请时就不准确、失误或没有认真进行工作量与人员之间的平衡,可谁能以当初的情况来预料未来啊,毕竟变化比计划大太多了;他们的“忙与闲”是现在、过去还是一直甚至会持续保持现状下去,或者说他们之间的忙与闲会“相对轮流坐桩”;或者说因为“忙闲不均”就可以将这些程序员重新打乱来配置。
题主讲的“忙闲不均”与“配置不合理”,想改变,都是不现实的,或者说并没有找到合适的办法。
2)帮忙有意见
让空闲人员去帮忙,会认为不饱和不是他的问题,为何要去别的部门或项目干活。
其实啊,这样的理解是没有问题的。看看职责、岗位说明书以及招聘时讲的工作内容,人家基本照办,而公司想改变,很明显错在公司啊。
况且,你让他去帮忙,专业、产品、知识/熟悉领域对得上吗?不帮倒忙就不错了,而且,人家还不一定愿意你来帮忙,你来,既打乱他们的工作节奏,还要抽时间来教你,最关键的是,人家的某些操作/技术或者潜规则做法,被你知道的话,那肯定是不行的啊,换成是你,会不会同意嘛。
3)已经闹到HR部门了吗
这样的“忙闲”不均,是不是达到比较严重的程度,比如:有的项目拖延非常长的时间也完成不了,而有的项目提前N多就完成了,导致公司整体研发进度严重脱节,所谓的木桶效应就明显呈现出来了。
或者说,某些程序员、研发管理人员向HR部门多次反映这样的情况影响了他们的工作,希望公司想办法改善。而且HR经过实际调查,不但找关键人员了解,还实际查看某些项目计划的完成情况,也听到部分领导的看法。
如果有以上几种情况之一出现,HR想办法改善是必要的,否则,我认为没必要“管太多”,手伸太长未必是好事儿,人家还不一定领情。况且,HR对研发能懂几何,不要到时自己深陷其中,进退两难就非常尴尬了。
2、研发老大,怎么看?
虽然是几个研发部门,按正常讲,它们中任何一个部门的层级,应当在HR部门之下,不可能与HR部门平级。也就是说,几个研发部门,要么是研发小组,要么是研发中心之下的某某部门,一般是以产品不同来分类的,这在稍大一点的公司里,这样的设置是非常正常的。
毕竟产品多、项目多,程序员或研发人员又不可能是万金油,要求他们在各自领域专、精、深,不然,产品或服务怎么可能在同行中有竞争力。
具体来说,要让其中任何一个员工去帮助或支援其他不同产品或项目的工作,都是不太容易的,毕竟跨领域、跨产品,所用到的知识、研发工具、软件、所涉及研发合作商区别也很大,除非刚好重合度较大,或者是一些基础性的研发工作内容。
但是,不管它们有多少个部门,但一定有一个共同的领导,要么是研发中心老总,要么是公司副总,但绝不是HR部门的老大。
它们的老大,对这几个部门以及所有人员的了解熟悉程度,包括他们的性格、平时表现、研发所擅长的领域等,一定比HR熟悉;同时,对这些人员的管理、拿捏甚至恩威并举,一定比HR更管用;最最关键的是,这一亩三分地,是这个老大的地盘,于公于私,都是他最有发言权,说难听点,岂容HR在这里来指手画脚。
所以啊,HR了解、调查到的情况,包括HR的考虑和担心,一定不要首先给老板讲,要与这位老大商量,看看他是怎么考虑的,按照他的想法、步骤来进行,如果需要HR协助,HR才作为,毕竟,这是他主管的部门、人员和事情,出了任何问题,公司首先追责应当是他,即使HR有责任,也一定是次要的。
3、“忙闲不均”是常态
一家企业,研发有多个产品、项目,而这些产品或项目的研发难易程度、进度计划、费用等都是不同的,就某个具体的时间段来说,如果此时来横向比较它们,多半是“忙闲不均”的。
大到国家,有研发火车、飞机、轮船、农业种子甚至军工的,如果就本周来看他们的“忙闲”程度,无疑也是“不均”,然而,如果非要抽调某人去支援、帮助其他不同的产品、项目,确实是强人所难了。
相反,不管是企业还是国家,多个产品、多个项目的研发人员“忙闲不均”就显得非常正常,这与产品周期是相一致的,而且还显得“错落有致、各有特色”,这不正是一件好事吗?管理人员或领导也才有时间和精力来对不同项目的统盘监管,为什么一定要强制性的“均衡”吗?
4、研发老大,有统一调配权限
不管是各个研发部门的负责人,还是统管几个研发部门的研发老大,对各研发部门的产品、项目以及人员一定是有管理、调配权限的,而且没有特别的理由,都必须服从这种安排,否则,就是违反公司制度,部门和公司都可以做出相应处理。
不管是“忙闲不均”,还是“人员使用不合理”,还是“产品、项目”在安排、费用控制、进度等各方面都有管理、调控的权限,这既是他们的职责,也是出现问题时他们必须处理的义务。
5、HR,怎么知道他们没处理呢?
在这些研发管理人员的权限内,可以完全处理好题主所描述的问题,甚至不用“惊动”HR部门,也无需HR插手。甚至说,他们已经或正在处理这些事情了,只是没有告诉HR部门罢了,因为他们认为这是他们自己的事情,而且也可能在处理中,没必要告诉HR或公司领导。
或者即使没处理,在他们看来,这是非常正常的事,没必要大惊小怪,比这种事情更大更重要的多得是,他们要忙那些,对这种小事儿没必要看重。
16楼 oocvbhx
老师说到点子上了
15楼 toutlense
除非HR对研发的工作特别清楚,不然最好不要插手,最好的方式是“放手”
14楼 长流水
每个项目的周期不一样,开发时和改bug时的工作量不可同日而语~
13楼 木木槟
学习了
12楼 烟格
明白
11楼 gsliqifen
很清晰
9楼 傲雪无双
老师多产,著作等身..
8楼 dffee
HR贸然行动,等于打脸研发老大的管理水平,不会有好果子吃
7楼 HRM叶
打卡
6楼 埃阿斯99022
......
5楼 郑卓文
打卡
4楼 阳光透过窗台
通过绩效激励机制,提高这些程序员的工作主动性~
3楼 大卡
秉骏哥李志勇老师——
本篇文章来自秉骏哥李志勇老师的分享。秉骏哥是三茅资历最久的老师之一,今年已是老师在三茅分享的第10个年头,发布文章近2000篇,大家可以点击老师头像订阅,也可以在评论区留言和老师多多交流哦~
2楼 小肥狼同学
打卡学习
1楼 开疆扩土丶丶
老师的意见和观点始终都是接地气和具备实操价值的,但问题是往往研发部门的老大也无计可施,或者懒得去处理这些烂芝麻事,而HR毕竟又限于经验、能力以及权力等方面的局限,同样处理不了。更甚者,老板会认为这就是HR的工作。反正我们奇葩公司就是这样。