摘要：研发部门之间工作“忙闲不均”，主管部门或人员是研发老大，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的工作。反正我们奇葩公司就是这样。