HR《研发人员的选拔和绩效管理》

徐老师

研发人员的选拔和绩效管理

今天非常高兴能和各位同仁沟通一个话题，就是研发人员的招聘和绩效管理。

　　谈这个话题主要讲我在IT行业的背景和经历，在这个经历情况下，我们怎么针对研发人员做选拔和考核的工作，尤其重点是考核的方面，可能稍微谈的比较深一些。

　　首先，我们来看两个方面：一是研发人员的招聘问题，我们先谈两个公用的方面，我们谈所有的招聘面试都会谈这两点：一是言行。就是我们讲一个人，人力资源一个著名的冰山模型，冰山上是知识和技能，冰山下面有四个层面：1价值观、2.自我认知、3.性格特质、4.动机。我们把它综合在一起可以叫做素质。比如我们简单一个人的团队协作、责任心、一个人的主动性等等我们都称作是素质。在实践工作中我们把非知识和技能统称纳入到素质层面。素质层面是冰山层面四个方面的主体，每个素质后面都可以分展出四个层面。

　　我们很明显的一个现实的问题，怎么判断一个人的素质。所以在实践中认为所有的素质只有通过行为体现出来，我们才认为是素质，不通过行为体现出来，或者面试官无法识别和判断的我们就难以认为具有这个素质。所以，这一点我们讲行为体现素质。

　　第二，过去判断未来。什么意思呢？就是说我们在面试的时候是了解一个的人过去，了解你的经历和你做过什么事、做过什么项目、开发过什么产品，全部都是过去，实际上要的是这个人到我的企业里面业绩的情况。我们这里有一个假设在这里，就是过去到未来，很有意思，为什么说通过判断一个人的过去了解他的未来，我们有一个假设，就是一个人过去某种形态下的反映一直到未来类似倾向的反映。所以这两点的基础才可以做我们的招聘面试。

　　我们研发人员同样会从这几个角度进行，我主要讲的是“问、听、看、测”。没有过多的时间和大家沟通。包括现在面试的工具越来越发简洁和完备，就我们在企业通常用的几种方法可以跟大家沟通一下。一是，我们叫结构化的行为面试法，简单总结就是目标形式面试法。二是可计分面试，这种招聘工具的方式很简单、很方便，所有的问题只有要么对或者错，没有第三个答案，它的一个问题考察是唯一的，我要求你回答的是非常迅速的，要求你半分钟之内给出答案，有一点类似于我们看开心辞典一样，每道题设计的是非常下功夫的，但是每道题方式答案是唯一，答到就是记分，达不到就是零分，在一和零之间的这样一个选择。三就比较多了，像企业曲面模拟、比如说企业常用的LGD，可能我们用的相对比较多一点。我们在企业常用我个人认为比较有效的，可能是这三种比较不错。

　　我今天重点谈的是目标行为面试法。研发人员的通用素质，这里通过我们在实践中的摸索，以及我也给一些IT公司作过包括帮他们设计过整个招聘面试的体系，比如华为、东软等等这些企业，这些企业的研发人员通用素质基本上一样，某种意义上类似，包括百度，我也给他们作过所有中层面试官的工作。我们再看其他几家公司，基本上研发人员通用素质几乎相似，我简单拿出一个研发人员通用素质的案例，具有一定的代表性。

　　从我个人经验来看有四到五条足够，我们不是找地球上完美的人，我们通用素质大概有18-20项划分，所以这里我们只找到其中能够和这个岗位的业绩关联很密切的四五项足以。这里我们来看一下这些素质内容，怎么分析和判断的过程。首先，素质定义不再讲了，分析思维、团队协作、压力承受、主动性、学习能力。大家从字面上基本上都可以理解。我给大家举两个例子：一是团队协作。我们来看企业有两种情况，一种情况是像东软做得不错，他们就有我们所谓的素质模型，对研发人员应该有什么样的一些素质，这些素质的等级划分，但是有些企业，像在做的时候就没有所谓的素质模型。其实我觉得在做招聘面试的时候，你有没有素质模型都不是原则问题，只要理解，理解成这个素质什么叫优秀，什么叫好，什么叫一般，什么叫不好就够了。所以这里我们把团队协作从经验上的一个判断就可以判断出来。比如我们在看团队协作，最差的可能不和别人配合，这种情况是招聘面试的时候很难问出来。比如讲一件你和别人共同协作完成的事情，除非一种情况，你问他若干个问题，如果他说没有，我记不起，我想不到，这里就无法对他的团结协作做出一个相对准确的判断。

　　二是愿意和他人协作。我用了几个字来概括这个成绩，就是分享和交流，就是愿意和别人协作。

　　三是抱着对团队成员积极的评价，对他人协作这块还是一个积极的心态去看待和对待。

　　四是鼓励，形成一个团队的合作氛围。这是一个简单的素质模型，我们要团队合作什么叫好、什么叫一般、什么叫优秀，大家闭上眼睛可以想想。比如最简单的团队协作是什么啊？就是跟别人配合，什么叫配合的一般，什么叫配合得很好，什么叫配合得更好。这里有一个大概的考虑。围绕这个层级，一旦我们有一个大概的划分，问题的设计就比较简单。为什么说我的提问题的设计比较简单呢？比如我们来看一下，随便拿简单的几个问题和大家沟通一下。

　　一种问题，我们没有任何指向的问题，这种问题我只指向我要你谈团队协作，但是我不指向在那个层级，比如我们第一个可能相对指向不是那么清晰，请介绍一下你和别人共同完成的事情，这种指向我打的点只是打团队协作，但是打团队协作的哪个层级不是那么清晰。还有一种提问方式，我们打点打的更加清晰，比如说请评价一下你目前所在的团队情况，你为什么这样认为？或者是请评价一下你目前所在团队的工作相互配合情况？加上这几个词更精确一些。这些问题打点打的比较清晰，打哪个点、打哪个层级？我们来看一下。当然这里写出来是打的层级二，我们来看一下这个题。层级二是什么呢？层级二是对团队成员抱有积极的评价。后面还追问为什么这样认为？你让他谈其中的原因。

　　学习能力：一个的人学习能力强，一个人的学习能力一般，一个人学习能力差，我们会从几个方面体现，这里我们有一个大概的划分。

　　接下来我来说一下绩效的问题。我重点会围绕第二点来讲“二级考核体系”。我们会采用两种方式考核，一是对研发项目的考核。这里有一个蛮强的通用的基于项目对研发人员的考核。所以，在这里我们采取两个，一个是公司对项目，另外是项目对工程师。思路上不难，关键在一些细节点上的把握和我们如何区分的问题。对项目的考核，无外乎我们认为是周期、预算、质量这三个方面。这里我们稍微的区分一下，像周期和预算没有什么说的。三是功能和性能，这是很重要一点。第二是客户需求度的满足情况，第三是规范化执行情况。什么叫规范化执行情况？比如说很多企业通过了CMM什么的，本身就是一个质量管理的流程。那么这些规范化执行情况包括有的企业，可能软件企业做的可能比较多一些。这都是一些软件控制方面的，所以对这些软件控制流程或者质量管理流程它需要一些文档、需要一些规范性的东西。

　　一是周期不难，主要是时间的问题。这里会有几个问题，一是我们考虑延期率。比如项目实际执行天数减去项目计划执行的天数，除以项目计划执行天数。我们知道，项目有的时候总是在变化，有变化是正常的，不变才是不正常的，所以原则上我们最终确定项目周期为准。原则上是这样。延期率，这里周期天数指的日历天数，不是工作天数，就是当对这个企业的特点，研发人员加班很多，也不分周六周日，我只希望往前赶，能够做完。当然有的企业人性化一些，比如说我可能周六周日你来了，我额外再算，各个企业情况不一样。延期率有一个过程，比如提前了怎么做，可能会有一个考核平分。提前不同日可能会有一个考核评分，如果提高工期，因为各个企业不一样，跟各个企业对周期的控制和预测的严和松都有关系。如果提前30%的时间，我们会认为这个出问题了，项目周期把控是有问题的，有的企业认为30%是很正常，可能到50%，那你就设50%.第二费用超支率。在这里有两个，一个是项目实际发生费用和项目预算。我们会用项目预算和超支，这里预算这块，我们邀请财务系统一定能够支持我们项目独立预算，这个不难。我在企业经历当中，曾经搞过将近两年的财务，是做财务和资本，还做过企业内部的控制。这块难就难在指标，这里有一系列的指标。对项目的考核基本上全部量化。一是性能和功能，这里有三个指标：千行代码Bug数，我们衡量代码的质量会有这样一个参数。这里我们会有两个很重要的一点，就是可能会提起来，首先开发的这段代码和开发的一部分的产品或者子功能，首先通过测试。这里确定一个前提，就是必须通过测试，测试通过了，再来看这个指标，如果不通过，整个打回去返工，工期影响了，预算影响了，所以我们根本就不会再考虑。所以，我们的前提就是首先通过测试，测试之后，测试合格了，我们得70分，这个得70分和80分也是各企业把握，有的企业把握比较严，可能控制的严一些，有的把控比较松，这个没有关系。

　　通过测试之后，我们再看这个指标。再看这个指标，比如举一个例子，这些指标完全是根据统计过来的，这家公司比如测试部有针对每一个软件甚至每个功能的相应的数据，这些测试部的测试管理，这些没有问题，只要有相对的稍微规范一些的企业，都没有问题。我举这家企业的例子，应该是通过了CMM2，之后一年过了CMM3，大概这样的过程。所以它对质量管理流程有一些要求，当然我知道谷歌要求的更高了。所以，其实CMM2中国企业很多过了，不是一个难的方面，越高级可能越难一些。我们会有千行代码Bug数。

　　在整个质量过程当中测试部起到很重要的作用，包括提供的信息和数据。大家会说了，刘老师这些信息和数据不准怎么办？不准没有关系，第一次不准，我知道哪些数字有问题，第二次不准也没有关系，我围绕前面试验的东西去调整，第一次可以拍，在没有数据的情况下你可以拍，根据实际情况试运行，或者试运行或者运行一段时间，我根据实际情况做一个调整。

　　第二，来看最后一次通过测试衡量为主，我们叫遗留Bug率，我们知道软件Bug越少越好，但是企业要减少成本和投入，包括微软他们不会解决所有的Bug，所以不断看到微软的这个补丁那个补丁出来，但是这个产品公司着急要。所以它可以容忍遗留一些Bug情况的，但是有的项目遗留的多，有的项目遗留的少，我们就叫遗留Bug率。如果项目产品通过了，这个项目的遗留Bug是什么情况，那么总体的Bug数是有的。说白了，总的Bug是我认为测试出来这么多Bug，比如测试100个Bug，你解决了50个Bug，那就是50%，还留了50%.当然我们不会留那么多。比如这家企业容忍度在于20%，这也是各个企业的测量的数据相应做调整。因为Bug越少，质量越高，所以质量方面还有一个遗留Bug的情况考虑。

　　第三是现场通过。因为这家公司是一个原来做电信系统集成的，需要到现场通过客户的测试。所以，这里我们要来看最终这个软件产品在现场的客户测试，这个测试前面讲了两个都是企业自己测试，测试部自己来做。现在到现场是用户测，包括一些交付用户的产品用户也要测。这里我们看现场用户测你能否通过？一样的，我们还有一个千行代码Bug数，我内部测完到现场测，现场测通过，说明这个产品质量没有问题。自己内部测，我们知道内部关系纷繁复杂，我这个项目经理跟测试项目经理不错，或者跟具体的测试人员关系不错，就差不多可以了。这里本身一个拿刀的，一个做事的，这两个本来就是一个矛盾。中国内部关系大家时间一长，低头不见抬头见，谁谁关系不错，会有这个情况产生，为什么设置这个指标，就是从这个角度考虑的。

　　这里对于Bug分类，我不跟大家具体讲，简单来说我们叫致命、严重、一般、轻微。作为企业来讲，前面两个一定不能要，致命Bug大家一听就不喜欢，出现一个就死机，甚至内存丢失或者重要功能损失，这个根本没戏。严重Bug也必须没有，我们企业可以容忍的就是后面两个，就是一般Bug，这块概念测试部比我们清楚，比如这个全是他们给我的一个定义。比如不影响工作模范错误、功能正常实现，但是伴随一些小问题。轻微Bug比较简单，比如一些文档中的问题等等。测试人员的能力不一样。有的测试人员水平高，可能Bug就多，有的测试水平不高，可能出的Bug就少，我们有一个解决的方法，不同版本每一次都有保存，包括源代码进行验证。比如测了没有问题，没有Bug，假如别人又测出Bug，那就有问题了，或者现场出现问题了，等等，这些方面就有一些新的问题，这个比较专业一些。

　　还有一些具体的问题，就是说Bug的管理，就是已知Bug，就是你知道了测试出来了，怎么管理。第二是现场可能出现，或者偶尔出现，就是现场出现了问题，企业内部要测试现场的情况，把问题暴露出来，但是有些情况很偶然的因素，比如几百万分之一，或者几亿分之一，这种情况下，可能很小，我们怎么处理，都有一些解决方法。第三就是漏测，这是很重要的一个方式。对于漏测问题，我们对测试人员直接扣分，测试文档当中很明确有测试的内容。这里简单一些，主要涉及一些稍微专业一些的方面。为什么我们要测试Bug，因为软件方面最重要的一个衡量指标就是Bug的情况。

　　我们再来看一下指标，比如在研发人员开发的模块给别人公用，这种情况我们要奖励，为什么呢？因为是这个项目开发的，按理说我可以不给别的项目，企业不能这么引导，应该引导在这个项目做的时候，我们叫事半功倍，这种情况下效果比较好的。所以，在这里可能会考虑这个比较多一些。我们对于能够复的情况下我们考虑质量加分。还有一个情况就是质量进行情况我们叫“第X次通过验收”。这就是一个双刃剑，为什么是一个双刃剑？比如有的项目经理部设这个指标会麻烦，会三天两头找你测试员测试，这种情况下，浪费的什么人力？浪费了测试员的人力。但是浪费这个人力，对项目来说怎么样呢？反正也不纳入我的考核里，所以这里测试部要把测试和项目分开了，我们原来想过划到项目里，但是我们想划到项目里没有戏，因为我是项目经理，你是开发人员，你是测试人员，我让你测试他，我也是项目经理，我来决定这个项目通不通过，所以这个我又是球员，又是裁判员，这样情况就没有办法进行了。你可以说对不起，这个产品通不了，我就会说这个产品什么时候上市，要赶快想办法解决。像中国很多的机构，像法院、检察院等等不独立分开是很麻烦的事情。

　　所以我们会设立“第X次通过验收”，这里最节省人力和成本。为了避免出现刚才讲的项目经理多次找测试人员，浪费测试人员的情况。比如这家公司有四次，他认为已经可以容忍了，四次以上，对不起我就要开始处理。包括四次前面的一二三，都会有不同的评分。当然这里有一个权重的问题。围绕刚才我们讲的这些内容，还有一个规范性的执行情况，这相当于我们的一些立项报告的蚊帐文档是否是完备或者不错。我们分为ABCD，我们对规格说明书，我们质量部门都有明确的模板，你是否按照这个模板去做，这个模板相应的质量怎么样，这主要是由质量人员判断。这是我们对项目的考核，我们对项目的考核最终有一个总体的考核表。大概有两页纸，把所有的项目纳入进去考虑不同的权重。我们这个考核表出来之后。我们可以分为两个层级的考核，第二层级是对工程师的考核，通用的一种方式就是任务单，我们基本基于任务单的考核模式。任务单要注意几点：目标任务内容没有问题，对于项目经理一定可以填出来，比如要求某一个模块或者某一个功能，要求在什么时间开发完，检验和完成会有一个说明，这都是纯技术上的话。这里有几点是需要注意的，管理上的问题，第一个是任务类别，什么叫任务类别，这里为什么设计这样的一个参数？主要基于这样的考虑，就是我们在企业里工程师分成若干的等级，比如我们有资深工程师、高级工程师、工程师、初级工程师，基本上会有这样不同的层级。比如你把一件活，对工程师很难的活，对高级工程师一般的活，对资深工程师就是小菜一碟，你要面对的对象不一样，作为项目经理会判断，项目经理对下面这些人的技术水平把握还是比较清晰的，所以这块能够判断出来这个活，张三干、李四干、王五干的难易程度。这就是对难易程度的划分。这是在管理上，我们认为最理想的状态是这个活儿适合高级工程师来做我们就让高级工程师来做、这个活适合初级工程师我们就让初级工程来做。但是我们在企业里边实际上很难做到。比如一个模块让一个人独立开发，不会把这个模块再拆分，这样反而不利于我们的人力和中间的协作和沟通，所以一个模块就完整交给某一个人，但是我们会判断某一个人对这个工作的难易程度。所以我们任务类别主要从这个方面考虑。因为对于一个企业来说，我付给你高级工程师的钱，我理想当中你就要干高级工程师的工作，如果是初级工程师工作给高级工程师干的话，这是一种浪费。

　　我们重点谈任务类别，这是我们设计的一个参数。当我们设计完之后，比如这个项目给张三工程师发了20个任务单，最后他做的每一个任务单都有刚才类似这样的情况，这个任务单出来之后，这个项目结束，我要给他考核，实际上把20个任务单汇总，汇总出来之后，进行判断。这里20个任务单最后我们有一个权重的问题，权重就是说给他派20个任务单和20个活儿，是不是20个活儿的性质都一样，有难有易，有重要和相对非重要的。所以我会把权重从这里考虑。我们设了一个任务类别，还有一个时间系数，什么意思呢？就是为了体现一个公平，什么公平呢？比如一个项目是6个月的时间，有一个工程师任务单很多，拿了20个任务单，有一个工程师只拿了2个任务单，其中一个任务单就4个月，另外一个任务单可能就一个半月，还有半个月不一定完全派活儿。那么，我们来看一下如果对于2个任务单和20个任务单是有明显区别的，如果4个月和一个半月，如果4个月的任务单做得不好，做的一般，比如我们才给他70分。还有一个就是一个半月的任务单做得很好，我们给他95分，一个70分、一个95分，如果没有时间系数，我们就会得到70+95除2，因为六个月当中最重要的任务，干的差，人家4个月的活儿干个差，只有一个半月的活儿干的好，最后平均下来是80多分，你觉得成绩还不错，这个时候评分就出现问题了。我再举一个极端的例子，比如6月的活儿，5个半月的放在这里，还有半个月的放在这里，5个半月的任务但得了60分钟，然后半个月的任务单得了100分，最后一平均80分，感觉80分还不错，但是实际上5个半月做砸了，这个任务糟糕。

　　还有一点我们会强调工程师表现考核，什么叫表现？实际上跟企业的文化和研发人员的胜任素质有一定的关系。比如我们希望引导研发人员是引导团队协作，比如吃苦耐劳等等，我们会把这些素质和体现的行为列出来，然后根据这些行为来引导他们，这是一个表现考核。这个表现考核企业有两个考核方法，比如我们叫它上180度，就是上级和同级评分，有的企业这样做，有的企业只是上级评分，这是各个企业把握的方法，没有说哪个好或者不好。业绩考核占80%，表现考核占20%.当然要看各个企业的不同情况。

　　把两个考核完成以后，我们对工程的考核做完了。最后有一个汇总表，这个做法优点在于考核的可衡量，我们基本上尽到最大程度的量化，基本剔除人为因素。二是有利于形成项目自我约束机制。我举一个指标，项目经理要自己想办法权衡，因为这些指标基本上都是双刃剑，你要工期可能就要考虑到测试次数等等的问题。二是与软件开发紧密结合，与管理业务形成“一张皮”，其实就是这些管理业务日常的方式方法。三是与现代项目管理做法协调一致，克服MBO考核中存在的问题。

　　MBO是业务管理，这种管理项目变化比较大的，可预见性会出现一些问题。还有就是有利于形成项目中团队合作机制。这个项目大的目标扔到那儿，如果出现问题，一定会影响到项目总的指标。另外一个是有利于企业形成双向竞争机制。首先来看工程师的利益和什么有关？跟项目有关，他们做的好就会拿得多，项目不好就会拿得少，我们在做的过程当中会形成项目经理选择工程师，工程师选择项目经理。我们要看到项目经理人缘的问题，有的项目经理不错，但是人缘不行，也没有人跟他。我们在职称方面仍然保留项目经理的利益和待遇。比如项目经理同时兼高级工程师或者资深工程师的钱，在这里我们会有一个基于项目经理的岗位津贴，包括利益分成上，在奖励分配上项目经理可能考虑的系数更多一些。

　　不足之处。对企业管理提出一定的要求，对管理软件不规范的企业需要调整一些系数。由于考核结果和利益挂钩，对企业财务核算有一定要求，就是我们刚刚提到的对项目预算的体系，我们一定要建立。项目人员变化，对项目考核提出更大的管理要求。这里有很多的具体情况，比如一个工程师同时兼两个项目甚至三个项目，尤其项目紧张的时候可能出现这样情况，这里的管理可能就会给项目经理产生一个情况，就是一个项目经理对两三个项目管理的时候会出现问题，这个在整个项目上还有一个部门，这个时候的部门经理或者部门总监会从中起到协调作用多一些。还有一个比如人员的变化，就是项目中间入职、项目中间离职等等产生一些问题，所以对管理有一定的要求。

　　奖金分配。奖金分配稍微设计的复杂一些，但是算起来非常方便。因为我们这个东西做完之后，全部把它做成公式法，只要填几个参数，项目奖金组一拉全都出来了。当然有的他们想做成软件，如果项目复杂的话，可以做成软件，因为管理上都已经标准化了，做出软件就是一个IT化的过程。我们来看具体的，项目奖金没有问题。首先我们会确定一个项目预算目标奖金额是多少？目标奖金额先确定下来，可能会考虑公司总体预算，可能会考虑项目总体情况、项目之间的互相平衡、上级和下级，目前先定一个数。我们再来看与项目完成情况挂钩，比如项目完成情况好，我们会实现一个K值，如果完成好K值肯定大于1，肯定更高，如果做得不好，K值要小于1，总盘子就要减少。确定总盘子以后就要分，把四个参数全部分到人头上，即工作负荷系数。这里会出现一个情况，对于项目中之所以谈负荷系数，因为没有负荷系数下面几个参数是确定不出来的。我们看一下超负荷、严重超负荷、正常负荷等等。第二是职位系数，就是类似于职称的概念，我在项目当中高级工程师起到的作用和工程师起到的作用不一样，我们要有所区别。所以我们会从职位系数有一个考虑。比如有的项目第七个月进去，有的人一开始进去，当然不一样。所以我们看项目一开始的情况，就是业绩加奖金额，我们会把整个项目完整的分解完。研发的项目考核稍微复杂一些，专业一些，当时我们在做的时候，一个很重要的部门就是测试部和研发部给我们提供了很多的支持和帮助，过程当中我们经过很深的探讨，大家可以看到这里很多的专业不是HR可以想出来，实际上和测试和研发部门一起做，当然HR我们在整个结构、框架、合理性的把握方面做的比较多一些，内容先讲到这里。谢谢。

0410370107

IT复杂