本文系属原创，著作权归本人所有，任何形式的转载都请联系本人，抄袭者必究!
【实操技巧：部门工作量不均衡，HR要怎样合理使用人才资源？
我们公司有几个研发部门，每个部门都有程序员，但有的部门很忙，有的部门有点闲，这样程序员的人才资源就得不到合理的配置。有时候让空闲的程序员去帮忙，员工会觉得部门业务不饱和也不是我的问题，为什么要去别的部门或项目干活。
请问牛人老师，要怎么样设计制度让程序员可以灵活分配，合理使用人才资源呢？
部门工作量不均衡，HR要怎样合理使用人才资源？】
【摘要：本文第一部分分享了组织架构微调方案，为挖掘用人效能打下组织方面的基础；本文第二部分分享了组织调整之后如何从制度机制层面挖掘用人效能的思路。】
一、组织架构微调整：
题主遇到的问题跟我之前所供职的一家老雇主几年前遇到的问题十分相像，彼时我的老雇主也是做私募股权基金的，当时每个业务部门都有分析师，因为业务部门跟进的项目不同，所以出现了不同团队分析师的资源调配不畅的问题。
遇到的问题除了题主题干中提到类似跨部门分析师调配不当的现象之外，还有就是原有团队担心如果放人去支持其他团队，分析师出现“真空”——派出去分析师之后，项目突然有大进展，调不回来，耽误项目进程，这更加给分析师的跨部门调配增加了困难。
我们人力资源部采取了一个办法，让所有的问题迎刃而解——这究竟是一种什么办法呢？
当时我们面对出现的问题，分析了为什么产生这个问题的原因，我们认为随着公司战略的调整，原有的组织架构已经不适合公司新战略——分析师无法灵活分配就是明证，为了解决这个问题，我们想到了一个组织架构微调方案，让分析师无法灵活分配的问题迎刃而解。
方案是这样的：公司把所有的分析师抽调出来，成立了在前台部门里的后台部门——投研部，由公司的一位董事总经理作为部门负责人，根据项目的轻重缓急来调配分析师来支持前台投资部门的工作进展，每个分析师可以跟进不同部门的2-3个项目，3个项目是同时跟进项目的上限。这样，每个分析师会不属于特定的哪个业务部门，但是会跟着项目走。分析师的收益跟自己在项目组里的表现直接相关。
投研部的董事总经理是分析师的行政领导，项目的项目经理或项目总监是业务领导，也就是说对于我们公司的分析师来说，他们就存在于一个庞大的矩阵中——横向行政领导是投研部，纵向跨部门合作支持某业务部门的某项目推进。
仿照我们的这个思路，建议题主也可以把自己公司所有研发部门的程序员抽调出来，成立一个新部门——开发部，开发部盛产各种Level的程序员，程序员的派遣要根据业务部门的项目难易、规模庞大来判定，派往不同的业务部门，跟进不同周期的项目开发，一个程序员最多跟3个项目。这样就既可以打破程序员组织内流动的“藩篱”，又可以充分利用程序开发类的人力资源。
二、挖掘用人的潜能：
那进行了组织结构的微调整、成立新部门、打破部门之间人才流动的藩篱之外，还有什么挖掘用人潜能的妙招吗？
当然有了，以下妙招亲证有效，供题主参考。
第一，程序员的部分考核指标可以由研发部门设计、打分，个人晋升与在项目中的表现直接挂钩。
程序员的绩效考核的部分指标可以由研发部门设计、打分，当然具体“游戏规则”可以由题主所在人力资源部根据贵司既有的绩效考核制度或方案根据组织架构的微调来进行改动。
第二，建议程序员的奖金来源为项目奖金，体现多劳多得的原则。
在我前雇主分析师跨部门调配难题中，分析师跟人力资源部反馈了值得注意的一点就是分析师就是拿死工资的，干多干少一个样，所以调配起来员工个人层面也没有动力。
这说明前雇主的分配机制是有问题的，于是我给前雇主总裁建议，组织架构微调之后，在业务部门进行项目分成之时，要以项目组为单位来进行分成计算——也就是说，虽然分析师是投研部派来支持项目的，但是如果所跟进的项目有收益，那在年终分配上如果要发项目奖金，也要把分析师考虑在内。只不过分析师不同的贡献，所对应的系数也不同。
这个设计，极大地激发了前雇主分析师的积极性，到后来，有的分析师甚至突破了当初我们预估的同时跟进3个项目的上限——同时跟进4-5个项目，再没有出现过调不动人的现象，按他们的话来说，这就是新形势下的“多劳多得”。
当然，我并不知道题主所在公司的奖金分配机制如何，但是，以上的分配机制是我亲证有效的，思路供题主借鉴。
第三，培训机制要跟上，通过适当培训课程赋能程序员。
程序员为什么水平有高有低，原因主要是因为程序员的既有项目经验、掌握的相关知识，为了提升程序员的能力，赋能程序员个人，建议题主所在人力资源部通过组织适当培训赋能程序员，帮助程序员个体从专业走向专家，对于程序员来说，这就是最好的福利。
Tips：关于解决题主面临的程序员资源未能充分利用的组织、制度规则方面的设计建议如上，希望题主能够根据自己所在公司的情况，找到适合自己公司情况切实可行的方案，达到赋能组织提升绩效的目的。
