关于软件行业的绩效考核.docx
《关于软件行业的绩效考核.docx》由会员分享，可在线阅读，更多相关《关于软件行业的绩效考核.docx（16页珍藏版）》请在冰豆网上搜索。
关于软件行业的绩效考核
关于软件行业的绩效考核
一、研发人员绩效考核的原那么 研发人员是企业技术创新的主体，他们的工作功效直接阻碍着企业的效益和竞争力。
关于研发人员的绩效考核应遵循以下原那么：
%. 结果考核与行为考核相结合，以结果考核为主%. 关于研发人员来讲，在考核中若是过于强调对行为的考核，会带来一系列的错误导向。
因为若是过于强调行为，员工会更关切做事的方式，而不是做事的结果。
在现实中，咱们常常碰着如此的情形：
一个不准时开会、从不加班加点、不注意弄好人际关系的研发人员却能够为企业设计新的工艺，为企业节省巨额资金、取得数项专利、在很有声望的杂志上发表论文、被特邀做学术报告等；另一个研发人员与他相反，行为上安分守纪，完全符合考核的要求，但没有什么实际的奉献。
假设过于重视行为评判，后者的得分会高于前者，你感觉合理吗？
固然，行为指标也是需要考虑的考核指标，但关于研发的整体业绩来讲就不那么重要了。
%.
（二）外评与内评相结合，之外评为主%. 内部评判，包括进度、预算等评估是必要的，但过度强调内部评判是很危险的，因为内评极可能不太关切研发对企业的实际价值。
内部评判作为企业内部的质量操纵工具是很重要的。
可是，评判的目的应该强调外评。
外评超级重要，作用比较大，比如说用新工艺设计带来的收益来衡量研发的成效。
%. （三）价值评估与产出评估相结合，以价值评估为主%. 只对研发产出进行评估是不够的，必需对研发为企业带来的价值进行评估，即研发成效的评判。
获利性是企业的本质特点，企业可不能允许研发领导只用如下指标进行考核：
拟订了多少研究方案、发表了多少论文、做了多少设计、设计出了多少产品、做了多少次展现、取得了多少专利、完成了多少项目……研发的成效更重腹地体此刻新产品的开发、本钱降低、销售量上升、产品改良、市场占有率等方面。
%. （四）评判系统要尽可能客观%. 在评判研发业绩时，数量是超级客观的指标，可是，质量和本钱数据往往是十分主观的。
尽管不可能用十分客观的方式测评质量，但在设计评判进程时能够尽可能减少主观性。
一个比较简单的方式是尽可能用外在的数据来评判研发业绩的质量。
比如说，若是你想估量产品改良的价值，你能够请工程和制造人员来估量，而不是让研发部门领导来估量他们成绩的价值。
%. 二、研发人员绩效考核的流程%. 考核的流程通常包括绩效目标设定、绩效评判、绩效反馈与沟通、绩效改良等环节，循环进行。
%.
（一）设定绩效目标%. 1．目标设定原那么%. 设立绩效目标着重贯彻三个原那么。
其一，导向原那么。
依据企业整体目标和部门目标，层层分解，设立个人目标。
其二，SMART原那么。
即目标要具体（Specific）、可衡量（Measurable）、可达到（Attainable）、相关的（Relevant）、有时刻限定（Time-based）。
其三，目标数量适中原那么。
目标不要太多，最多6～8个%. 2．目标的设定%. 对研发人员来讲，一样要设定业绩目标和能力进展目标，业绩目标由项目团队目标分解到个人，能力进展目标那么要研发人员依照高绩效研发人员的能力要求，结合个人爱好来制订个人的能力进展目标，在把握的技术、完成工作效率、解决客户问题能力等方面制定相应目标，并制定达到该目标应采取的行动打算。
然后由上级依照企业目标进行认可。
%.
（二）绩效考核指标体系的设计%. 1．设计的原那么%. 考核研发人员的首要原那么是考核指标必需紧密结合企业战略，若是企业的竞争策略是先于竞争对手推出新产品，就能够够把上市时刻（timetomarket）或产品开发周期作为首要的考核指标；若是企业的竞争策略在于低本钱，那么把产品本钱作为首要要素。
第二个原那么是研发部门、研发小组和研发个人的考核指标必需息息相关，是由上而下的指标分解进程而形成的体系。
第三是依照研发策略，平稳好长期性与短时间性指标、绩效指标与行为指标之间的关系。
%. 2．指标体系%.
（1）业绩指标%. 企业的研发人员要紧分为项目领导、开发人员、测试人员等，对不同的研发人员，业绩考核的指标有所区别。
项目领导的业绩指标要紧有：
新产品开发周期、技术评审合格率、项目打算完成率、项目费用操纵、客户中意度、团队士气指数等；开发人员的业绩指标要紧有：
项目打算完成率、项目流程、标准符合度、设计的可生产性、设计本钱降低率等；测试人员的业绩指标要紧有：
测试问题解决率、运行质量、打算完成率、开发进程标准符合度等。
%.
（2）行为指标%. 关于研发人员工作行为的评估，能够从主动性、服从性、责任心、协作精神、工作合理性、纪律性等方面进行考评。
%. （3）能力指标%. 可细分为业务知识、业务技术、打算能力、判定能力、解决问题能力、应变能力、人际技术、明白得能力、学习能力、创新能力和领导操纵能力（这项能力及以下能力适用于部门领导以上的治理人员）、决策能力、指导帮忙下属能力、组织能力、员工治理能力等。
%. 考核的目的不同，考核所采纳的指标体系也有所区别。
若是要考评研发人员过去特定一段时刻的工作表现，且考核结果将用于加薪、发放奖金、盈利等奖励，考评指标体系要紧为业绩指标和行为指标；若是考核目的为员工前程进展，且考核结果将用于教育培训、能力开发、升迁、调动等人力资源计划与配置，考核指标体系应包括业绩指标、能力指标和行为指标。
各指标之间的权重也因考评重点不同而相应转变。
%.四）持续沟通与绩效反馈%. 研发人员能够说是企业的核心员工，对企业的生存与进展具有极为重要的作用。
常常与研发人员进行沟通，了解他们的心理动态十分必要。
如一家软件企业的研发副总去检查项目工作时，看了一名测试工程师的报告后，严肃地批评：
“你的测试报告不合格。
”两个月后该测试工程师离职了。
后来该工程师给企业写了一封信，透露了他离职的缘故——仅是研发副总的一句批评。
研发副总很是后悔地说：
“我对他的批评只是道出了实情，但如果是事后我对他的进步予以夸奖、鼓舞，情形完全会是另外的样子。
”可见，绩效的沟通、辅导及反馈十分重要。
%. 沟通贯穿整个绩效考核的全进程，而不只是在某个时点、某个环节上互换信息，如绩效考核流程示用意中所示。
第一，在绩效目标的设定进程中，研发部门主管要与研发人员进行沟通，让员工明确部门目标，帮忙他们依照部门目标确立自身目标。
第二，对研发人员的考核指标和标准的确信，应该和研发部门的主管和研发人员进行一起讨论，获取考评人与被考评人的认同。
然后，在绩效评估终止后，上级要把考核结果及时反馈给下级，并与下级进行沟通，以幸免黑箱操作，同时有利于下级改良工作。
%. （五）绩效改良指导%. 绩效评判结果反馈给员工后，若是不进行绩效改良和提高的指导，这种反馈就失去了意义。
绩效改良指导要紧帮忙员工分析绩效不足的缘故或改良提高的机遇，帮忙员工寻求解决的方法，并制定绩效改良的目标、个人进展目标和相应的行动打算，纳入下一时期的绩效目标中，从而进入下一轮的绩效考核循环。
每一个测试领导都面临如此的问题，如何对测试人员进行绩效考核。
因为测试人员参与的工作不单一，需要的技术也各类各样，考核测试人员的绩效似乎不是很容易的事，除一样需要考核的对工作的态度，工作的责任心，踊跃性这些方面之外，还有一些其它方面的内容。
要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。
测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。
如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。
如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。
对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。
测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。
还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。
或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。
而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。
测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。
另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。
首先我们不能单纯的以测试人员提交的bug数量进行考核，那样的结果可能会导致测试人员为了bug数量而互相攀比，导致bug质量的下降。
所以我觉得下面这几点可能会更合理一些（仅供讨论）：
1：
有效bug率用来衡量测试人员发现的，被确认为缺陷的有效缺陷比率，比率越高则测试质量越高。
这个比率剔除被开发人员拒绝修改和删除，以及重复的bug之后，剩余缺陷数占缺陷总数的一个比率。
测试人员不能只重视bug的数量，为了让领导感觉测试人员每天都在工作而随意的提交bug，从而导致bug数量很高，但质量很低。
造成很多bug都被拒绝修复或者bug不能重现以及bug重复报告等问题。
2：
测试覆盖率主要用来衡量测试人员对功能点遗漏测试的情况。
我觉得这适合测试组人员较少的公司，每个测试人员要单独负责一个完整的项目，在这种情况下，进行这样的衡量是有必要的。
3：
bug描述质量主要衡量测试人员对于bug报告的描述情况。
bug报告的描述是否清晰、简洁。
开发人员是否能很容易的理解并依据报告描述重现bug。
很多情况下开发人员拒绝修改bug是因为bug报告的描述很难理解，并且依据描述不能重现bug等。
4：
严重bug率主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷。
这有助于让测试人员将注意力集中在关键问题上，减少产品的致命缺陷。
5：
市场反馈缺陷率产品正是发布推向市场后，客户在使用产品的过程中发现的缺陷数占缺陷总数的比率。
用来总体衡量测试组整体的工作情况。
长期以来，如何考核测试人员的工作是富有争辩的话题，一个理想化的方式是搜集测试时期以后项目时期的缺点来确信系统测试的质量。
可是，这种方式的不可操作性在于：
一是保护和实施时期的缺点难于搜集；二是缺点贯穿产品的整个利用周期，无法穷尽，难于将时刻段分割开来比较；三是本钱过于庞大，时刻跨度太长，起不到有效鼓励的作用。
能不能就在项目进程中寻觅能够评判测试人员工作的方式呢？
就这那个思路，本人试探出一套有效的方法。
第一声明的是，第一，这套考核方发在一个功能点估算超过10000个的项目中通过实践，可是关于小项目而言，可能缺少足够的数据和必要性；第二，项目组内考核的成功不能意味着在测试部门内能够采纳类似的考核方式，仅提供一种参考方式，部门考核可能更多考虑投入工程的工作量大小和任务分派重要性；第三，除量化指标外，测试人员工作态度、工作能动性和技术学习意愿要通过定性分析来取得。
项目组测试人员考核要紧包括工作效率和工作质量两大块，工作效率用于考察活动，而工作质量用于考察产出物质量。
由于考核基于测试进程进行，因此必需在进程终止以后才能进行。
固然，由于工程是散布提交测试的，每一个月能够依如实际情形进行月考核，工程终止后或任务终止后在统一考核。
依照传统测试周期，测试进程分为：
测试打算、测试设计和测试执行三个方面进行。
测试打算属于测试领导的范围，在最后讨论。
测试人员主若是测试设计和测试执行，测试领导的考核可包括在测试人员的考核内，固然，这部份考核也能够纳入项目组中进行。
考核指标如下：
一测试设计
工作效率相关指标
文档产出率这项指标值要紧为测试用例文档页数除于编写文档的有效时刻取得。
用于考察测试人员测试用例文档的生产率大小。
公式：
∑测试用例文档页数（页）/∑编写测试用例文档有效时刻（小时）
参考指标：
依照项目汇总得出平均在页/小时左右，高于此值为优，低于此值为差。
用例产出率这项指标值要紧为上述指标值的补充，用于考察测试人员测试用例产出率大小。
测试文档页数可能包括的冗余信息较多，因此要查看文档中测试用例的多少。
方式是测试用例文档中测试用例编号总和数除于编写文档的有效时刻。
公式：
∑测试用例数（个）/∑编写测试用例文档有效时刻（小时）
参考指标：
平均个用例/小时
工作质量相关指标
需求覆盖率计算测试用例总数之和除于与之一一对应的功能点数之和，要紧查看是不是有功能点遗漏测试的情形。
公式：
∑测试用例数（个）/∑功能点（个）
参考指标：
100％。
若是连功能指标都不能知足100％覆盖，最少说明测试不充分。
那个指标搜集起来相当困难，若是存在需求跟踪矩阵或测试治理工具能把用例与需求一一对应就容易患多。
注意：
有的功能是难于测试的，那么未能覆盖到的需求要综合分析，明确是测试人员遗漏？
仍是无法测试？
这需要放入问题跟踪表中进行后续跟踪；另外，有的功能点包括的信息较多或有的用例包括几个功能点，这时只能把重复的功能点或重复用例按一个计，难于区分的要做说明。
文档质量测试用例进行评审和同行评审发觉的缺点数，或将此缺点数除于文档页数算出比率。
此指标考察测试人员文档编写的质量如何。
公式：
∑缺点数（评审和同行评审）（个）
∑缺点数（评审和同行评审）（个）/∑测试用例文档页数（页） 参考指标：
由于评审是发觉的缺点数是不固定的，因此，那个指标没有可供参考的数值。
若是缺点数大小不能直接用于比较就利用缺点/页方式进行横向对照。
文档有效率利用测试用例文档进行测试时发觉的系统测试缺点数除于此文档页数。
用于考察文档是由有效的指导了测试工作。
公式：
∑缺点数（系统测试）（个）/∑测试用例文档页数（页）
参考指标：
平均个缺点/页
注意：
若是存在测试人员在测试时创建新文档用于辅助测试时应包括这一部份。
用例有效率利用测试用例发觉的全数缺点除于测试用例数总和。
这一指标是上一指标的补充指标，用于考察用例质量是不是较高
公式：
∑缺点数（系统测试）（个）/∑测试用例数（个）
参考指标：
平均个缺点/用例，也确实是说，每执行两个用例才取得1个缺点，各工程有所不同，能够自己实践一下
二测试执行
工作效率相关指标
执行效率利用测试用例文档页数除于这次系统测试执行的时刻总和（不包括用例文档编写时刻）。
补充指标方式是用例的个数除于这次系统测试的时刻总和。
用于取得工作中测试人员每小时执行测试的速度。
公式：
∑测试用例文档页数（页）/∑执行系统测试的有效时刻（小时）
∑测试用例数（个）/∑执行系统测试的有效时刻（小时）
参考指标：
平均页/小时，个用例/小时。
即测试人员每小时执行半页测试用例或每小时执行2个测试用例。
通过横向比较，容易明白那位成员的执行效率较高。
注意：
执行效率高的不代表测试质量也高，乃至执行效率和测试质量成反比，因尔后面工作质量的指标会补充这一部份的偏离。
实际结果说明，用例执行效率高的成员，其缺点发觉率往往偏低，考核若是不将此纳入进来也能够将其作为测试改良的一项重要数据进行搜集。
进度偏离度检查打算时刻和实际时刻的进度，方式是打算时刻差额减去实际时刻差额除于实际工时总和，用于考察测试人员进度情形，监控测试是不是依照日程进行，是不是知足了工程的进度要求。
公式：
∑（打算开始时刻-实际开始时刻）＋∑（打算终止时刻-实际终止时刻）/总工时
参考指标：
15％进度偏离是个相对的指标，可能偏离了20个工作日，可是关于一个长达半年时刻的测试而言偏离天数比上整体测试所需天数不足15％，可能偏离了3个工作日，可是关于一个只有1礼拜时刻的测试已经超过了整个测试时期所需天数的60％。
注意：
计算时分子分母要维持一致，即开始或终止时刻已经去除非工作日时刻，那么总工时也要去除非工作日时刻。
因为制定打算时是依照每一个公司的工作日来制定的，也确实是说，考虑了非正常工作日的日程。
测试进度也是考核很重要的一步，若是没有进度保证，所有的测试都存在风险，第一种方式是测试人员能够采纳自下而上的方式向测试领导报告打算历时，这种方式风险比较少，个人依照自己能力大小确信，可是缺点是存在测试人员虚报可能性。
另一种方式是测试领导进行估算后分派工作日程，这时估算是很重要的前提，除依托于测试领导的体会外，对评估结果进行同行评审是很客观可取的方式。
缺点发觉率测试人员各自发觉的缺点数总和除于各自所花费的测试时刻总和。
由于执行效率不能足够代表测试人员是不是定真工作，那么，每小时发觉的缺点数确实是重要的考核指标，你的工作能够通过这项指标取得反馈。
公式：
∑缺点数（系统测试）（个）/∑执行系统测试的有效时刻（小时）
参考指标：
平均个缺点/小时假使有位测试人员没有达到1小时发觉1个缺点，那么，除非产品质量高、模块较小，不然，确实是他的缺点发觉能力不如其他测试人员。
固然，详细分类中能够依照发觉重要缺点的多少来概念缺点发觉能力。
工作质量相关指标
有效缺点数/率被拒绝和删除的缺点数总和，或被拒绝和删除的缺点数总和除于缺点总数。
这项指标用于考察测试人员发觉的、被确以为缺点的缺点数高低或百分比，数和比率越低测试质量越高。
公式：
∑缺点数（系统测试中被拒绝和删除的）（个）
∑缺点数（系统测试中被拒绝和删除的）（个）/∑缺点数（系统测试）（个）
参考指标：
平均％（测试人员发觉的每100个缺点中平均有22个缺点不被开发组确认、以为不是“缺点”或错误录入缺点）。
有效缺点比率容易给出，可是有效缺点数具体数据要依照项目情形，无法给出可参考的数值。
注意：
这项指标可能有不正确的情形，假使缺点被拒绝和被删除的缘故不是因为测试人员误操作和需求明白得等自身错误引发，而是系统本身不能实现或数据错误引发的，那么就要考虑剔除这部份。
关于测试人员发觉系统框架全然性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、能够通过改变环境而无需修改程序、从头导入数据、再次发布从而拒绝或删除的缺点，应给予此测试人员奖励。
严峻缺点率那个比例用于弥补缺点发觉率的不足。
主若是依照严峻程度分类的缺点数比全数缺点或有效缺点数。
一样而言，每一个公司大体把缺点严峻程度分为严峻、一样和微小，或更细（通常品级数为奇数）。
另外，能够对缺点严峻程度进行折算（严峻：
一样：
微小=1：
3：
5）通过折算能够得出权重，然后在计算测试人员分值，在此不冗述
公式：
∑严峻/一样/微小/∑缺点数
∑严峻/一样/微小/∑有效缺点数
参考指标：
严峻~10%一样~70%微小~20%。
当测试人员发觉的缺点中严峻错误比率越高，说明测试质量相对就好，通常严峻程度缺点数的散布呈正态散布。
模块缺点率那个指标主若是依照一个单独测试模块的缺点数除于模块本身功能点数得出来的。
假使一个模块是单独测试的话，很容易能够和其他模块进行指标横向对照，参照对应的测试人员，得出所测试模块的缺点数，能够考察测试人员测试水平，也为开发考核提供数据。
公式：
∑缺点数（系统测试（个）/功能点（个）
∑缺点数（系统测试（个）/子功能点（个）
参考指标平均个缺点/功能点1个缺点/子功能点
注意：
有些功能点没有子功能点，计算子功能点时要进行说明。
三测试治理
开头提到对测试领导的考核就复杂一些，除测试领导参与测试设计和执行外，还要考察他的测试治理能力，即测试打算时期工作，其中
打算质量测试打算的评审缺点数或比率，能够与其他同类型项目或数据库平均指标进行对照。
公式：
∑缺点数（评审和同行评审）（个）
∑缺点数（评审和同行评审）（个）/∑测试打算文档页数（页）
参考指标：
无
本钱质量本钱气宇要紧放在工作量这块。
因为不管涉及工资仍是奖金，都要和工作量挂上关系。
本钱质量主若是对测试活动的打算工作量总和比上实际的工作量数值总和。
对测试人员考核的进度偏离已经考虑了进度因素，而工作量涉及的是本钱因素。
公式：
∑测试活动打算工作量（估算人日）/∑测试活动的实际工作量（人日）
参考指标：
原那么上不能偏离打算的±15％～±20％。
事实上，那个指标是对本钱的一种气宇。
关于一个大的项目来讲，估算值往往差距超级大，时期统计时可能有±500％！
！
这时调整打算是很必要的，在最终时期取考虑计算平均估算值。
一个测试领导必需对完成任务的本钱进行有效操纵。
这两项指标是相对容易量化的部份，而需要添加其他量化指标需要综合考虑由项目领导和测试部部门领导给出标准，例如治理历时比率（整个项目测试期间治理时刻占整个项目测试总时刻）、系统整体缺点数与其他同类型项目或数据库平均指标进行对照等等。
考核具体方式：
1．将各项指标进行汇总分析，得出总和表格，依照测试人员各项指标大小进行排行榜制作，如列出1、2、3、4名。
2．肯按时期涉及的权重。
例如将测试设计和测试执行权重各为50％。
其中，工作效率占40％（即占所在时期20％），工作质量占60％（即占所在时期30％）。
3．确信每类指标的分值，然后每类指标达到平均标准给100％，达不到或超过依照80％~120％比率给分
4．将比分统计出来后进行综合评定，必要的话增加一些调整系数。
5．最好将定性分析纳入进来，采纳问卷调查和项目领导评分制度给出定性指标分数，建议这部份权重不要超过10％～15％以保证测试考核的可气宇性。
当所有考核分数给出以后，提示一点的是，既然做了考核，就必需公布这些结果，而且考核具有导向型，不要让考核误导了对证量工作的追求才是最重要的。
考核注意事项：
1．项目并非是一个月就能够完成的，如每一个月进行，要考虑“可考核部份”为那些，挑选那些指标能够横向对照，然后分时期、分任务评定。
2．参与测试的时刻长短也要给予重视，除上述量化指标外，测试人员整体投入时刻长短也是很重要的，加班也要作为特殊考虑因素，或许某个测试人员只参加了测试执行3小时，各项指标都是良好的，可是不可能给他比其他参与时刻更长的人员更多的分数。
这部份确实是增加调整系数的缘故。
3．测试领导的测试设计和执行部份和项目测试人员一路考核，可是测试治理工作要单独考核，作为另外的加分，或如文章前面所述纳入项目组给予考核。
因为测试领导在项目测试中起着治理者和质量保证负责人的角色，不
升级会员 