【实操技巧】部门工作量不均衡，HR要怎样合理使用人才资源？

有人忙，有人闲，一定是工作量不均衡？有没有可能是能力大小问题，或是效率问题……如果看到有人闲着，就让去别的部门帮忙，后果会怎样？

研发的工作量，不可能均匀分布，而是结合开发阶段，呈现不规则分布。如研发前期，测试人员无法参与，研发后期，测试人员又特别忙。

公司虽然有好几个研发部，但每个研发部都有自己的研究方向，互相之间虽然有共性，但更重要地是差异性。研发需要的不是万金油，而是长期聚焦一个方向。从这个角度看，研发都不大喜欢跨领域帮忙。

当然，如果这种闲忙是长期的，则可能反映在研发产品在市场的竞争力。没有订单的产品，自然没有多少研发量，订单多，研发的需求相对更大。

研发无法以勤补拙，如果能力不足，再努力也是做无用功。因此，闲并不等于工作量少，忙也有可能是无能的表现。

作为HR，如果老想着让闲着的程序员去别的部门帮忙，最后可能导致所有人看上去都很忙，就是不出研究成果。

为了让研发人员跨部门流动起来，很多公司都会实行矩阵式组织架构，用项目打破部门壁垒。如果你用闲忙为借口让员工帮忙，没人愿意；但用项目把各部门的人变成一个团队，很容易形成合力。

有些研发公司一直亏损，或项目利润率太低，会将项目按大小、难易等维度分类，与项目管理津贴挂钩，直接在工资中体现。

有些研发公司则把项目做为阿米巴模型，按项目利润占比进行分配。项目负责人再按照项目贡献进行二次分配。

这种闲忙不均的现象，除了工作量和能力之外，还和直接领导的管理能力有关。

很多研发部门的负责人，主要精力依然在研发，部门压根无人管理。由于缺少内部管理，没有针对性地 分配工作，常常因为个体的进度和质量耽误整体的进度和质量。

临时工作占比太大，也会显得比较忙乱。很多研发人员都反映，自己有工作计划，但临时工作能占到一半的工作量，整天忙得毫无头绪。

作为HR，不能被研发人员表面的闲忙影响了判断，而是应该找到表象背后的原因，是能力差异、效率差异、管理原因，还是临时性工作影响……

因此，工作饱和度分析、素质模型搭建、人效分析等工作，该有的还是得有；组织架构优化、项目激励、管理能力提升，该完善的软件还是得完善……策略调整，战略调整，该提建议提建议。

查看原文

      其实，像今天这个打卡话题所说的工作量分配不均问题，是在很多公司都普遍存在的现象，我们除去人为因素这类内部斗争、故意为之的情况，那这种情况我们今天在这里不予讨论。所以，这种现象大概率是因为该企业在工作分析这块的工作做得不好，所以才会出现这样的现象。

      我们可能会经常看到，企业里面有员工忙闲不均，忙的忙死、闲的闲死，但是这是否就意味着不公平呢？这也不一定。所以，为了搞清楚真实情况，我们需要对工作进行分析，就是对不同岗位、不同员工的工作内容和工作产出进行分析、进行量化，之后我们还要去检查、验证这个结果是否正确。

      首先，我们要了解什么是工作分析？工作分析能帮我们做什么？否则，对这项比较枯燥的技术，我想你也是没有兴趣去学习的吧。我们先来看看下面这张图。

      这张图是我对工作分析进行的简化说明，也就是简单来说，工作分析就是帮助我们解决做什么、谁来做、做成什么样子的问题，也就是我们各个岗位的工作内容是什么，哪些人能做这些岗位，就是要从事这些岗位的任职资格条件有哪些，要将这些岗位的工作做到什么样的标准才算合格。搞清楚了基础的原理，这样我们才能找到问题的真正原因，才能真正帮助我们找到处理问题的方法途径。

      那么，工作分析都有哪些作用和价值呢？大家可以看下我在下面画的这张简图，我给大家标明了几种主要的作用，在这里就不展开和和大家详细阐述了，大家可以从图上自行查看，以后有机会再和大家详细介绍这方面的知识，让大家更详细地了解对内、对外、对上、对下都有哪些价值。

      所谓：工欲善其事必先利其器，所以说，了解基础知识是很必要的，学习是最不能急功近利的事情，在此基础之上，再来学习如何进行工作分析的技术，就更加有效了。

      这个时候，我们就能分清楚，到底是否是真的工作分配不均，还是只是你表面看起来是这样；你就能搞清楚是不是因为某些员工因为效率很高，所以才会出现有更多空闲的现象；才能分清工作忙的部门员工是否是薪酬也拿得多？是因为他们的经验多么？还是工作鞥力不足导致显得忙？他们是团队的主力成员么？工作不忙的部门员工是否是薪酬也拿得少？是工作能力强，完成工作快呢？还是经验不足，而导致公司不愿给他们多分配工作呢？如果是这样，还可以或者值得培养么？等等。

      等你把这些问题都搞清楚之后，你就可以和员工们及他们的领导谈心了，了解工作忙的员工对现有的工作分配和工作状态是否不满意，是否对自己的产出和回报不满意？工作不忙的员工，是因为什么原因导致的工作不忙？是因为工作能力不足呢？还是因为态度不端正呢？还是没有适当的激励措施呢？等等。毕竟工作最需要的就是沟通，如果员工觉得工作不合理，就就要及时去和领导和同事沟通。

      所以，我觉得你既然要着手处理这个问题，除了专业的工作分析技能之外，你还需要重点关注两个维度，一个是沟通的主动度和共享度，另一个是对其他员工的响应度。而能否做好这个，也正是你能否有效处理工作分配不均这个问题的关键，可以说，这比你那些专业的技能更加重要。

      最后，我想再说一次以前曾经说过的话，作为一名团队的领导干部，或者作为企业的HR管理者，最容易犯的一个错误就是过早的对你企业的团队和成员下结论，这种先入为主的偏见经常会掩盖真正的问题。俗话说，世界上甚至都没有两个一样的鸡蛋，更何况人的区别呢，就更加千差万别了，我们每一个人都是独一无二的，对于企业的HR人员或者团队的领导干部，如果不花时间去了解每个岗位的真实情况，不去了解每一个人的特质，就没有办法制定出恰当的目标，就没有办法有效地诱发、引导和激励员工的行为，调动员工的积极性，就没有办法很好地带领好这支团队。

查看原文

工作不均，考验研发总监的规划能力

工作任务不均，在企业里面经常会遇到，但是这种任务不均，一般体现在行政、后勤、财务、客服等大后勤类岗位。如果说研发岗位的工作任务会产生不均衡的状态，那么就是研发总监设定的项目任务出现了问题，或者是这个项目的负责人出现了问题。

一般情况下，一个项目经理要懂得任务快慢的调整，项目经理要对这个项目的整体节奏负责。如果几个研发团队，某些项目的任务紧、时间紧，那么作为研发总监或研发副总裁这个级别的人，就要对下面的工作任务作出适当地调整。

前面说的内容，我们只是通过表面现象去衡量和判断，因为工作忙和工作闲，体现了两种工作节奏，一个是这个项目复杂，对于这个团队的人员来说，研发这个项目就有些吃力？

就像今年江苏的高考数学试卷，很多人说难，数学试卷的确非常难，很多平时能考120分左右的人呢，此次高考可能很多人数学都考了90多分，甚至80几分。但是数学试卷再难，还是有很多学生考了140几分，130几分，120几分。

一个项目的难易程度肯定是有区别的，那么忙的团队，可能就是在不断地在做优化，程序优化一遍、两遍，甚至是三遍。如果程序需要不断地优化的话，那么程序员就忙坏了。

像这种不断地再做程序优化的工作，就涉及到软件初步架构的问题，也就是规划出问题了，程序员只能按照这个框架开发程序，程序开发完了，又发现软件太“臃肿”，软件总的容量太大，离预期的目标又太远，所以就出现了工作很忙的现象。

那么这种工作忙，其实就是表象，其本质还是工作能力、软件架构方面的能力欠缺，说白了，就是软件开发的工作经验是缺乏的。

各位HR伙伴，现在知道为何企业在招聘的时候，宁愿招聘有项目经验、有软件开发经验的人开展工作了吧？

因为，没有经验的人聚集在一起，再没有一个“顶梁柱”挑起大梁，那么这个项目开发，就可想而知结果如何了。

我们作为HR来讲，要和研发总监沟通好，可以通过项目奖金的形式进行调配开发工作。

这里面，其实我们HR要清楚，到底是真的忙，还是工作效率低下，或者是工作方向出错？

如果工作方向没有问题、程序员开发程序也没有问题，软件架构也没有问题，那么我们就请研发总监将其它团队的工程师调配到这个项目中来。

我们HR再和研发总监沟通后，的确发现是因为程序开发的人手不够，那么我们可以从其它团队里面抽调几个程序开发能力强的人，过来协助帮忙，抽调过来的人，除了可以获取原来团队的项目奖金外，还可以额外获得这个团队的“协助”奖金。

总之，HR要想合理调配人力资源，就必须搞清楚，这个“病”的“病根”是什么？如果你HR自己都搞不清楚人家项目团队的人，为何有的快，有的蛮，有的忙，有的闲，仅仅是你HR凭借表象去理解，那么就大错特错了了。

研发团队的人员工作量是相对固定的，相对好分配的，也是相对好考核的。鉴于这个前提，我们HR和研发总监沟通后，要求研发总监对工作忙闲作出调整， 如果研发总监认为无需调整，那么笔者个人认为工作不均导致的忙闲不均，就直接考验研发总监的规划能力。

故，我们HR要透过现象去分析本质，而不是仅仅看问题的表面，只要研发总监愿意重新规划下属团队的工作内容，本期话题内容就迎刃而解。作为HR来说，我们就是要考虑如何适当地给予一些团队奖金？如果没有任何奖金的情况下，闲的团队的工作人员，为何心甘情愿地去帮助忙的团队呢？

本文有感而发，大家如果有不同意见，可以留言点评！

查看原文

共享归口派件与保底，解决共享业务的调配执行

学习思维：

1、部门工作不均衡，要找出业务中的共通部分形成统一解决路径，以资源资源的浪费。

2、在共享管理中，工注意的是以工作量和时间要求，来作为衡量派工与结算的依据，要注意避免人情管理。

本文内容：

在大部分的制造企业都会有一块业务叫搬运，而大部分整车企业也会有一块送车业务，而几乎所有的企业都会有一引起基础的勤杂共享业务。这些业务有一个共同点，那就是都是属于基层，面向多个部门或者整体企业服务。而其管理皆为归口管理。

何谓归口管理？

归口管理，是因某些业务的共通性，造成多块业务所共需的服务，将此业务统一交由某个部门进行的管理。以此避免出现多头管理，最终因纠结造成多方推托而无人管理的现象。

在这种管理模式下，当其他业务部门需要这部分业务服务将向该归口部门提出申请，再由归口部门以派工的模式让员工到该部门去服务。

而本话题中的程序员的情况，显然也基本适合同样的归口管理模式。

要知道写程序、做程序管理，具有计算机、AI等项目业务中的基础属性。也就是程序员在专业服务上具有很大一部分的共通性。

那么对于以项目制进行管理的互联网、计算机等IT类企业，在对程序员需求上则类似于企业中的一般共享服务。

那么将程序员归口于技术中心的服务科室进行统一调配，就是完全可行的了。

在企业各部门形成自己所需的编程需求，然后汇总到技研服务室，由服务室进行统一调配程序员进行完成。就可以有效的形成程序员工作的分配。哪项业务量大多派些程序员，是否因为工期要求需要加班，由程序员组长进行分析，报由服务室核定。

将整体的程序写进控制在手中，保证程序编写的资源不浪费。

那么在程序员的管理中要注意些什么呢？

一是必须要注意工作总量的评估核定。工作总量是我们核定程序员数量的前提。因此，要在年度工作规划中，即要要求各程序编写维护的管理需求量。因此，要在此体现年度规划与预算的重要性。

二是必须要立制锁定与业务部门之间服务与派驻的程序。既然是归口管理，就不要私自喊人做事，以为你我熟悉点，就随意喊人帮忙。这会造成共享服务室对人员的管理难度。因此，要明文确定工作支持与人员派驻的简易程序，申报的是工作量与交期时间等工作负荷，申请的是人员数量与工作机制（通告与时间）。

三是必须要将薪酬待遇的结算。既然是归口管理，那么薪酬也同样是归口管理。

在共享归口管理的薪酬管理中，需要明确两个方面的内容：

一个是与业务之间的工作报酬核定。这个由公司统一核定正常的业务量与薪酬之间的交换核算。但在要求缩短工期、加人加量加时的情况下，形成的超量价格核定、员工加班薪酬等都需要形成统一的明文规定。在形成派工事实时按交期进行核算，将成本计入业务部门。

另一个是程序员的薪酬管理。作为管理中心，也许本身并不对程序员产生业务需求，只是以一个共享平台的身份出现。那么平时的程序员管理服务费及基本薪酬的来源必须要思考。此管理服务中心毕竟不是脱离业务的共享。因此，也必须要依据各业务部门提出的年度工作规划，形成一定的程序员数量需求基数。以此形成的对应人数的保健需求薪酬（保底部分）将计入该业务部门的人工成本。如果需要计入共享管理部门成本，那就需要与业务部门形成保底业务需求派工量。以此保证业务共享中心的收入来源。

因此，部门工作量不均衡的情况下，要形成以整体业务需求总量为基准的劳动力需求数据。以此确定建立劳动者共享服务管理中心。再以业务需求量为申请，以管理中心派工的形式形成劳动力的调剂服务。形成统一管理，共同享用的平台中心。

小结：

做管理不能机械的以业务数量进行管理，而是要以业务需求与资源的配置情况进行实地管理。

在做共享管理中心的管理中，主要明确的是业务来源与报酬管理的结算其实还是为一体的核算体制——重在预算与规划。

查看原文

         在实践生活中，你会发现，有些企业制度完整，流程顺畅，各岗位说明书清晰，也有相应的绩效考核，但仍然出现员工只管自己的一亩三分地，在其他岗位需要帮忙时，员工不会主动过去帮忙，而有些企业，尽管一年只考核一次，但是员工都自动自发的工作，在自己的工作任务忙完时，主动帮忙部门其他同事工作，为什么会出现这种情况呢？其实核心点就两个字“利益”，当公司的利益与员工的利益相关，个人利益与部门利益相关时，就算公司不进行监督，员工也会自动自发的工作。

  有些人说，这不可能做到，笔者告诉你，就有公司做到了。

         其实想要解决楼主企业的问题，不是一两句话就能说清楚的，要对企业进行详细了解，才能找到相应的解决方案。

      那么针对今天的案例话题，笔者来聊聊，给楼主一些思路，仅供参考

首先、学会对研发类人员绩效考核的分析

      研发人员属于典型的高智力投入知识型员工，具备专门的知识和技能，更注重工作自主性、个性化和多样化，更重视自我尊严和自我价值的实现。由于研发人员拥有高技术、高教育的背景，其在工作方面表现出来的特征与传统类型的员工有着明显不同，这些特征主要表现在对专业领域的忠诚度、对工作环境的要求等。

其次、研发人员的劳动过程大多依靠大脑的思维而进行，他们的工作产物属于智力成果，需要许多时间来思考、计划、搜寻信息及灵感，甚至和其他专家谈天，许多事情无法被观察，其工作绩效往往需要时间检验才能见分晓，有的时候阶段创造性的成果难以测量。他们从事的工作极大程度上依赖于自身智力的投入，产品无形，难以准确度量。

所以、研发部门常见考核指标：包括：项目研发计划实施进度、质量和成本控制，对于高度重视创新的企业，还要将科研创新指标作为引导指标。

项目进度的考核：要依据客观外部环境和内部人力资源条件作出相对公平的评价。

项目研发成本：对于公司有历史基线的，可依据历史基线进行考核，这样的考核更有针对性和可量化性。

研发人员工作成果的考评标准：通常通过对研发任务进行层层的分配与目标确认，要求每个人根据其所承接的任务，给出自己的工作计划。考核工作是审核其工作计划的合理性，并且根据其工作计划来评估研发进度、研发规范和研发质量等关键指标，而对其工作业绩进行考核。此外如果公司研发产品实行战略领先的策略，需要考核研发创新指标。

企业的研发不是独立的，需求来自市场，同时要和财务对成本控制相关联，对于研发人员的考核，要逐步引导被考核人保证按时高质量完成任务，不断提升企业产品质量，同时要控制研发成本投入，确保研发产品快速投入市场产生效益。

其次、需要了解技术人员的薪酬结构

技术人员常用的薪酬结构主要有以上四种

其中，除了岗位技能工资制，其他三种是为了加强技术人员结果为导向的考核机制，激励技术人员将个人技能与项目、部门、企业的效益挂钩，在岗位技能工资制的基础上扩展出来的。

岗位技能工资制

是指：技术员一般采取岗位技能工资制度，可以整合为岗位技能工资，也可以将技术人员工资分为岗位工资和技能工资两种。

岗位工资，根据技术人员所从事的职务或岗位而确定。

方法，通过工作分析、工作评价将技术人员的工作根据其技术要求、责任大小、劳动强度、工作条件、决策范围等因素来评定，并依此形成技术岗位等级。

依据技术岗位及等级确定的工资成为技术人员工资的一个内容，它激励技术人员努力提高自身技能、尽力完成岗位工作要求。

技能工资：根据技术人员个人的技能/能力而确定。

方法，评定技术人员所具备的技能或能力，并依据此对技术人员给付薪资。

技能工资鼓励技术人员不断提升个人技能，企业也投入成本培养开发技术人员的工作技能。

有的企业将技术人员的岗位工资和技能工资合并为岗位技能工资，即将以上两方面综合评定后确定企业技术人员的工资额。

虽然评定时需要考虑权重，并且专业性较强，但从另外一个角度讲，岗位技能与技术人员个人技能是可以结合考虑的，这样有利于将技术人员所任的岗位和其个人实际技能相结合。

岗位技能工资+绩效工资制

     指企业技术人员的工资由岗位技能工资收入和绩效工资两部分构成。

一般情况下，岗位技能工资仍主要考虑技术人员的个人技术能力和岗位技术要求两方面来综合确定，而且，在大多数企业中，岗位技能工资仍是技术人员薪资的主要组成部分。

       多数企业中，技术人员采取这种薪酬结构的，岗位技能工资占技术人员工资总额的70%以上。

这种制度下的绩效工资可以根据岗位技能工资的一定比例核定，例如：岗位技能工资占80%，绩效工资占20%。

   技术人员的绩效工资可以根据技术人员工作的完成情况考核，也可以根据部门业绩、企业整体业绩情况挂钩考核，还可以结合两者的因素，或者再加入其他考核要素。

岗位技能工资+项目奖金制

    是指企业技术人员的工资由岗位技能工资收入和项目奖金两部分构成。

项目奖金的考核标准可以从两个角度考虑，一个角度是项目完成情况，包括：项目进度、项目成本控制、客户满意度等；另外一个角度是项目收益，主要是项目毛利润或项目净利润。当然，也可以结合两者进行考核，来决定技术人员项目奖金的额度，这样相对考核指标就更加复杂。

岗位技能工资+绩效工资+项目奖金制

    是指企业技术人员的工资收入由岗位技能工资收入、绩效工资收入和项目奖金三部分组成。

在这种薪酬考核模式下，企业期望技术人员既关于个人岗位技能的提升，又关注项目收益、部门业绩及企业整体业绩。

最后、了解各种绩效考核方法

    当你对研发部门进行绩效考核分析以后，又了解到研发部门人员的薪资结构，结合公司实际情况，挑选出一种适合企业的绩效考核方法，其实实践中，很多企业已经采用 了阿米巴管理模式，楼主也可以把研发部门以及与研发部门工作直接相关的岗位纳入进来，形成一个阿米巴，然后在针对这个团队进行相应的绩效考核，团队做出成绩，大家都有肉吃，做不出来，大家都跟着遭殃，这样一来，还担心会出现案例中这种情况吗？

好了，今天的文章就写到这里了，如觉得对你有所帮助，记得点赞加关注哟，谢谢，祝您工作愉快！ 

查看原文

一、案例摘要

1、公司有多个研发部门，忙闲不均；

2、空闲的程序员帮忙，员工不乐意；

3、希望合理地设计制度，确保程序员灵活分配。

二、分析&建议

1、研发部总负责人什么想法？部门划分目的何在？

首先，我们务必要分清楚权责，业务上的事情，业务老大说了算。面对这种情况，研发部总监什么态度？部门划分的目的又是为何？

在职场里面，往往存在既合理。

如果说研发部总监对此不想要有改变，那么理论上只有比他更高一级的人才能有权说要改变（譬如老板）。否则，不仅不能讨到好，说不定还会赔了夫人又折兵，遭人记恨。

如果说研发部总监想要改变现状，并且需要人力资源部门介入的情况下，我们才师出有名（其实在很多管理比较完善的企业，研发部总监若真看到了这种情况，自己早坐不住了）。

2、绩效的指挥棒作用

现在整体来说公司的管理大多已经比之前几年好很多了，大多公司都有绩效考核思路，要知道，工作分析+绩效管理就是解决工作不均衡的。

工作分析，就需要从研发部门找人对接，通过访谈法、要素分析法、要素积分法等方式，将各个程序开发岗位的工作情况盘点清楚。

工作分析相对清晰了，那么绩效管理制度就比较容易制度了，无论MBO、KPI、BSC，还是现在比较流行的OKR，目的都是抓住核心关键工作，根据完成情况来进行激励。甚至，对于一些程序开发的岗位，如果工作有一定的可行性的话，甚至可以根据工作包进行一些类计件考核的方式（前提是结合业务特点将工作包及其颗粒定义清楚）。

绩效管理推进的流程，基本上遵循：调研——初稿——与部门讨论——模型测算——试运行——正式运行。

在制定绩效管理制度的过程中，我们要注意几点：

（1）我们出建议，研发总监拿主意，不要搞错身份；

（2）绩效管理是以激励为主的，因此，重点核心工作如果可以，上限允许超过100%（但要防止员工钻空子）；

（3）重点核心工作要少而精，且所占权重要大，这样才能起到指挥作用；

（4）绩效制度形成后，如有必要，需对薪酬结构和制度同步进行对应调整，若可与其他制度关联（培训制度、员工淘汰制度等），也可进行相应调整；

（5）绩效制度初步框架成形后，要根据现状进行模拟测试，尽量保障符合正常工作要求的员工收入不低于现状；

（6）注意流程合法性：根据《劳动合同法》第四条，与员工切身利益相关的重要制度修订调整的，要经职代会等程序，并且要公示确保员工知晓（留证），以免产生劳动争议时吃瘪。

3、将指挥棒交给研发部总监/老板

切记切记，HR部门只是绩效管理的支持部门和绩效制度的第三方执行部门，除非老板有特别的要求，指挥棒一定是为实际部门的指挥人服务的。

所以，绩效管理制度一旦成形，在执行的过程中，HR部门一定要与研发部总监保持高度同步，在指标解释和一些口径的把握上，在不突破原则的基础上，要充分尊重管理者意图，并且不断完善制度本身。

三、总结

1、发现问题了，在介入之前，一定要弄清楚状况，团队是研发部总负责人的团队，他是第一责任人，所以一定要与他沟通并达成一致；

2、绩效管理制度的建立，要考虑实际因素，也要起到指挥棒的作用，现在关于绩效管理的理论体系很多，找到公司/部门适用的作为参考，要多沟通、做模型测算，甚至可以留一段试运行时间来做缓冲；

3、指挥棒是为指挥人服务的，HR部门要及时交给指挥人，清楚自己支持和监督的职责，不要越俎代庖。

以上，个人观点，欢迎大家一起来讨论。

查看原文

谢谢你的提问，这个问题很常见，源于人才资源是按照部门来组织的，而大部分的工作是按照以项目为单位来进行的。 在迈入信息时代的今天，这是必须要克服的一个课题。 

我自己曾经工作过的四大会计师事务所和咨询公司都面临这样的情况，现在以几个老东家的做法为借鉴，希望给你一点启发。 

- 会计师事务所的人才基本上都是按照部门来管理的，根据个人的专业背景，员工会被录用到审计部、税务部、咨询部等；HR咨询公司也是一样，典型的部门会有组织与人才、薪酬、福利等部门。 

- 但是咨询行业的业务是按照项目来的，每个客户项目都可能包括各方面的内容，例如一个人力资源优化项目可能包括组织、人才、薪酬、福利等，因此大部分项目的立项虽然在某一个部门（通常是主要交付内容相关的部门），但是项目交付都需要组成跨部门的项目组。 对于员工来说，做自己部门的项目和别部门的项目都是家常便饭。

- 从绩效规划的角度，每个员工都有交付的指标，例如XX财年内完成共XX元的项目交付；高级别的员工还有项目销售的指标和管理项目的指标等。这里我们以项目交付的指标为主来说明。

- 假设员工为了完成总共一百万元的交付指标，他可以做一个百万元的大项目，也可以做五个二十万的小项目；可以做自己部门的项目，也可以做别的部门的项目。 

- 无论哪个部门的项目，项目经理都会按照各个成员的贡献程度分Billing（就是计费），例如一个总额80万的项目，组织与人才部分40万，薪酬25万，福利15万等。

- 员工从各个项目里分到的Billing积累起来只要达到一百万元，就达到了他个人的年度交付指标了。

- 由于这个机制，不仅各个员工会积极主动地争取做项目，无论哪个部门的项目; 就算是他部门的负责人，也会积极推荐自己的员工参与别的部门的项目，因为这有利于自己部门完成绩效指标。

- 项目经理自然会留意初级员工的能力，尽可能挑选最能干的进入自己的项目组。能力或者态度有问题的，自然没有哪个项目经理愿意用，达成交付指标当然就很困难。 所以员工能力和态度会自然而然地反应在绩效指标的达成上。

- 从整个公司的角度，这个机制有利于盘活各个部门的人才资源，尽可能充分地达到利用；从人才的角度，这有利于员工开发协调沟通和合作能力，并且从跨部门项目中学到其他部门的专业知识，也增加跨部门调动的可能性。 

- 当然，其中肯定也有些争抢功劳或者分配不公的事情发生，这都是成长过程中的烦恼，需要管理和克服。 其中也会碰到相对比较“甜”的项目和相对比较“苦”的项目，但是长期来说，这些偶发因素都会互相抵消的。

回到您的问题，当然贵公司不见得每个项目都收费的，所以不一定能完全适用计费的分配方式。 但是是否可以笼统参考一下，例如每个员工每年必须负责几个项目，或者几个项目模块？也可以按照项目大小难易初步分一下。 这些项目或者模块可以来自自己部门或者别的部门，只要一年内按质按量完成所要求的项目或者模块数量，就视为达成绩效指标。

对于员工和部门负责人来说，一开始肯定有个适应过程。 但是有远见的经理和员工都会明白，长期的闲置对于员工前途和公司业绩都没有好处，这样盘活资源的做法对双方都有益。

以上一家之见，供你参考。 希望你能顺利解决这个问题

查看原文

       本文系属原创，著作权归本人所有，任何形式的转载都请联系本人，抄袭者必究!

一、组织架构微调整：

        题主遇到的问题跟我之前所供职的一家老雇主几年前遇到的问题十分相像，彼时我的老雇主也是做私募股权基金的，当时每个业务部门都有分析师，因为业务部门跟进的项目不同，所以出现了不同团队分析师的资源调配不畅的问题。

       遇到的问题除了题主题干中提到类似跨部门分析师调配不当的现象之外，还有就是原有团队担心如果放人去支持其他团队，分析师出现“真空”——派出去分析师之后，项目突然有大进展，调不回来，耽误项目进程，这更加给分析师的跨部门调配增加了困难。

       我们人力资源部采取了一个办法，让所有的问题迎刃而解——这究竟是一种什么办法呢？

       当时我们面对出现的问题，分析了为什么产生这个问题的原因，我们认为随着公司战略的调整，原有的组织架构已经不适合公司新战略——分析师无法灵活分配就是明证，为了解决这个问题，我们想到了一个组织架构微调方案，让分析师无法灵活分配的问题迎刃而解。

      方案是这样的：公司把所有的分析师抽调出来，成立了在前台部门里的后台部门——投研部，由公司的一位董事总经理作为部门负责人，根据项目的轻重缓急来调配分析师来支持前台投资部门的工作进展，每个分析师可以跟进不同部门的2-3个项目，3个项目是同时跟进项目的上限。这样，每个分析师会不属于特定的哪个业务部门，但是会跟着项目走。分析师的收益跟自己在项目组里的表现直接相关。

       投研部的董事总经理是分析师的行政领导，项目的项目经理或项目总监是业务领导，也就是说对于我们公司的分析师来说，他们就存在于一个庞大的矩阵中——横向行政领导是投研部，纵向跨部门合作支持某业务部门的某项目推进。

       仿照我们的这个思路，建议题主也可以把自己公司所有研发部门的程序员抽调出来，成立一个新部门——开发部，开发部盛产各种Level的程序员，程序员的派遣要根据业务部门的项目难易、规模庞大来判定，派往不同的业务部门，跟进不同周期的项目开发，一个程序员最多跟3个项目。这样就既可以打破程序员组织内流动的“藩篱”，又可以充分利用程序开发类的人力资源。

二、挖掘用人的潜能：

        那进行了组织结构的微调整、成立新部门、打破部门之间人才流动的藩篱之外，还有什么挖掘用人潜能的妙招吗？

        当然有了，以下妙招亲证有效，供题主参考。

        第一，程序员的部分考核指标可以由研发部门设计、打分，个人晋升与在项目中的表现直接挂钩。

        程序员的绩效考核的部分指标可以由研发部门设计、打分，当然具体“游戏规则”可以由题主所在人力资源部根据贵司既有的绩效考核制度或方案根据组织架构的微调来进行改动。

        第二，建议程序员的奖金来源为项目奖金，体现多劳多得的原则。

        在我前雇主分析师跨部门调配难题中，分析师跟人力资源部反馈了值得注意的一点就是分析师就是拿死工资的，干多干少一个样，所以调配起来员工个人层面也没有动力。

        这说明前雇主的分配机制是有问题的，于是我给前雇主总裁建议，组织架构微调之后，在业务部门进行项目分成之时，要以项目组为单位来进行分成计算——也就是说，虽然分析师是投研部派来支持项目的，但是如果所跟进的项目有收益，那在年终分配上如果要发项目奖金，也要把分析师考虑在内。只不过分析师不同的贡献，所对应的系数也不同。

       这个设计，极大地激发了前雇主分析师的积极性，到后来，有的分析师甚至突破了当初我们预估的同时跟进3个项目的上限——同时跟进4-5个项目，再没有出现过调不动人的现象，按他们的话来说，这就是新形势下的“多劳多得”。

       当然，我并不知道题主所在公司的奖金分配机制如何，但是，以上的分配机制是我亲证有效的，思路供题主借鉴。

       第三，培训机制要跟上，通过适当培训课程赋能程序员。

       程序员为什么水平有高有低，原因主要是因为程序员的既有项目经验、掌握的相关知识，为了提升程序员的能力，赋能程序员个人，建议题主所在人力资源部通过组织适当培训赋能程序员，帮助程序员个体从专业走向专家，对于程序员来说，这就是最好的福利。

       Tips：关于解决题主面临的程序员资源未能充分利用的组织、制度规则方面的设计建议如上，希望题主能够根据自己所在公司的情况，找到适合自己公司情况切实可行的方案，达到赋能组织提升绩效的目的。

查看原文

改变员工行为的2个抓手

文／黄兰兰，专业提升、职场成长，为HR及管理者赋能！

（文章一律原创，抄袭必究） 

大家好，我是爱写爱分享，愿意带着HR共同学习与成长的黄老师，咱们又见面了。

关于案例中的这个问题，如何改变员工行为，激励员工往企业想要的方向去走。

可从组织层面、领导层面、个人认知三个方面来设计。

1、组织层面：

人力资源合理配置首先得从组织架构、顶层设计上来安排，而不是靠HR在遇到问题时临时通过设计新的制度来补救。

因为涉及到个人利益的事情，员工都会跟你较劲。

大多数员工都会认为，是我职责内的是我应该做得，不是我职责内的，公司给额外奖赏也是公司应该做得的。

遇到问题拿制度来解决，员工会觉得这个制度是用来对付他们的，也就是只起到了惩罚的作用，而没有起到激励的作用。

拿案例来说，研发部门可能会因为业务板块的不同、工作性质的不同而分成了几个不同部门。

但在组织架构设计上，是不是需要考虑几个问题：

第一，设置合理架构，让员工对岗位、部门有从属认知

几个研发部门的上层是不是可以设置一个统管部门，如研发中心，中心下面不管设置几个研发部门，研发中心应该有一个总负责人，每个研发部门有一个负责人。

从架构上就得让员工认为大家是一个团队，资源要共享，工作要协作。

第二，进行利益分配，让各部门既竞争又协作

当几个研发部门隶属于一个部门后，接下来如何让各部门既能形成竞争关系，又能形成合作关系呢？

像腾讯的产品部就有好多个，并且当公司需要研发一个产品时，不是分配给其中一个部门来做，而是同时发包给所有产品部门。

让这些部门同时竞争，最后以市场的反馈来检验哪个部门的产品才是符合市场需要的。

这样的设置好的地方在于让大家形成竞争关系，最终胜出的部门不仅能获得极大的收益，也能获得权威性地位。

不好的地方在于公司需要投入更多资源进行运营管理。

还可以通过绩效来管理，每个部门由于业务性质可以有自己的部门绩效考核方式，但在这个基础上还可以有一个大池子绩效的管理。

当几个部门同时努力，完成整个研发中心的任务时，各部门有额外奖金。

这个任务可以按照梯度形式设计，分为保底任务、达标任务和挑战任务。

保底任务达成才能分各部门的部门额外奖金，达标任务完成可以拿整个研发中心利润的几个点，挑战任务达成可以拿几个点类似这种。

既不影响各部门的绩效又能形成利益绑定，如华为的绩效核心理念-力出一孔，利出一孔。

2、领导层面

组织层面的顶层设计、绩效管理做好，基本是80%的问题可以解决，这是基础。

再看领导层面，即各部门负责人的部门管理情况。

因为一定有的部门领导会更在乎部门利益，有的部门领导会考虑大局。

有的部门领导擅长部门管理、团队凝聚，有的部门领导业务能力强但管理不行。

再好的规则制度也需要有好的管理者去做宣导、引导。光靠HR是不行的，部门领导需要承担起这个职责。

你会发现，我们HR去和部门沟通时，好的部门管理者会耐心倾听你的需求，积极配合你，而有的部门管理者会认为你在给他们找事情，配合度不高。

这是管理者认知和胜任力的问题，很难改变，而应从前端-即招聘环节，研发部门的负责人需要一个什么样的领导。

什么样的领导更适合管理团队绩效呢？

团队绩效是未来的趋势，因篇幅关系，关于如何构建适合本企业的“团队绩效”，如何选拔适合的管理者，欢迎大家关注我的主题文章《如何构建团队绩效》。

更多此类内容欢迎大家关注我的个人主页和我深入探讨这个话题。

招聘课程：《从小白到招聘高手的4步修炼》

求职面试课程：《HR求职面试全攻略》

向上管理课程：《HR向上管理的5大技法》

心理学课程：《心理学在HR工作的实战场景运用》

企业文化课程：《选育用留：企业文化在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或公司领导。

或者即使没处理，在他们看来，这是非常正常的事，没必要大惊小怪，比这种事情更大更重要的多得是，他们要忙那些，对这种小事儿没必要看重。

查看原文

首先，忙和闲一定就是工作量的问题吗？是否有工作效率的原因。这点需要界定清楚，对各程序员需要进行一个盘点，了解他们的真实能力水平，以便后期根据项目难易程度进行合理的人员分配。

其次，既然有多个研发部门，而要实现程序员的合理调配，从组织架构上来说，可以建立矩阵式组织架构。

即将各个研发部门合并为一个部门或中心，然后横向设立项目1、2、3部，每个项目部设置一名项目经理，由项目经理以单个项目从前期立项到最后交付为周期，进行整体统筹协调市场、研发及其他职能部门，进行整体人员的调配。

在此过程中，如果各项目哪个环节提前完成，或人员出现空闲，则服从整体调配，兼做其他项目。由此涉及到的项目成员评估，则涉及到相关项目经理及部门负责人的综合评估，需要同步调整。

进行组织架构的调整，有个好处就是各岗位的职责及工作范围会进行相应调整，不再限定为完成部门承接的项目，而是扩大到所有项目，以此减少员工的心理不平衡感、减少部门墙。

当然，矩阵式组织架构，也有其缺点，特别是下面员工多头汇报，公司需要做好项目经理与部门经理权责利的平衡，以及各项目事项先后顺序的平衡。

如果不调整组织架构是否有解决办法呢？

也有，可以通过激励型方式，即我们的每个项目都设置个奖金包，那么参与项目的人都能分到。这样其他部门闲下来的员工，自然就愿意过来帮忙。而与此同时，为了自己多分点，本部门的人员或本项目的成员就会努力提高效率，免得被更多的人来瓜分奖金。

如果不调整组织架构，项目本身没有设置奖金包，也不准备新增奖金包，是否有解决办法呢？

也有，那需要在员工整体的绩效考核指标、晋升与调薪制度上进行调整。

绩效考核指标设置加分项，即主动或服从安排帮助其他部门、项目，依据工作量大小及难易程度，给予不同额度的加分。

在晋升上，要求职级晋升必须每年主动或服从安排帮助其他部门完成X个项目或XX体量项目的工作。

在调薪上，类似绩效考核，也给予加分处理。

这里小明就要问了“调薪加分，那绩效本身就加分了，很多公司把绩效作为职级晋升、调薪依据，不是三重加分了吗？”是啊，就是为了多重加分啊，就是为了增加吸引力，解决程序员的人力资源的合理分配啊。要知道，绩效虽然加了分，但对应可获得的工资实际增加能有多少呢？吸引力小了，效果必然不佳，问题得不到改善或解决，那有啥意义呢，是不。

把努力当成一种习惯,而不是三分钟热度。坚持才是王道,每一个你羡慕的收获,都是别人努力用心拼来的。共勉！

好了，本次话题就到这里，我是专注分享干货与实战技巧的帅气大叔郑军军，我们下次再见！

（本文系个人原创，版权所有，任何形式的转载都请注明出处或联系本人，侵权必究！）

查看原文