软件测试工程师绩效评估表
软件测试工程师职责：
1与软件产品部配合完成软件需求分析讨论，并根据需求说明书制定《项目测试（计划）方案》；编写《测试用例》；建立测试环境；
2负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改软件的模块测试和系统测试；建立、推广并维护实施软件版本管理系统；
3使用并维护软件缺陷管理系统mantis ，负责软件问题解决过程跟踪记录，提交《mantis 报告》；
4负责推广实施软件开发文档规范化工作，管理研发产品相关文档；
5负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作，并提供测试报告；
6负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。
7与开发工程师和研发部门交流报告任务进展情况，并提出最近的测试需求；
8测试部负责制订测试计划、测试用例和测试实施方案，项目主负责人安排测试与对应的开发人员交流完成测试执行工作；及时提交准确、完整的《项目测试报告》；
9项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交流掌握下周或近期可能测试任务；
10外部接口都由测试部主管负责完成，与其他项目组和产品部门协调项目进度；二．软件测试的不确定性：
1软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找
不完的；
2开始测试时，可能软件使用1 个小时就出现10 个错误；测试修正后1 个小时出现一个错误，继续修正，继续测试，直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。
3测试一些成熟的游戏或应用，测试过程中很难发现大量的缺陷；而测试一些不成熟的游戏或应用，在测试前期，会出现大量的问题；这样就导致不同的工程师发现不同数量的bug；
4软件测试的进度首先会按照测试计划逐步进行，但是在测试过程中，测试进度会随研发部门的进度而调整；所以积极的与研发部门交流、协调测试中的问题是相当必要的。
三．测试工作最低成功标准及测试工程师考核内容：
测试工作的最终目标就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了你没测试出来的错误，那测试是失败的。如果使用了很久（如几个月）才出现错误，那说明测试还是成功的。
测试工程师考核内容：
1测试工程师比开发工程师更了解产品；（产品各模块总体把握能力）
2测试工程师能从客户的角度来检测软件的功能；（用户身份）
3测试工程师获取资料，使得编制的测试用例更切合测试的重点、难点以及关
注点；
编写测试用例）
4测试工程师比开发工程师更容易发现产品的问题；（不同的思维模式）
5测试工程师总是不断的发现问题，验证问题；（提交bug 数量、bug 质量）
6测试工程师按照测试计划完成各自工作；（测试计划的执行能力）
7测试工程师以操作员的角度测试产品；（Free 测试能力）
8测试工程师及时与开发工程师沟通、交流解决问题；（部门间的工作协调能力）9测试工程师及时提交测试报告；（报告的及时性、准确性）
10测试工程师之间处理问题；（共同完成任务）
11测试工程师协助开发工程师，了解开发流程等信息；（学习能力）
四．软件测试人员工作业绩评估的误区：
1 不能仅从提交的问题数量、测试执行用例数量来判断测试人员的好坏；
模块A 很不稳定，潜在的问题数可能有100 个，由测试人员甲负责测试，他一个月执行300个用例，提交50 个问题单，发现30个有效问题，有10个严重问题；
模块B比较稳定，潜在的问题数可能有20个，由测试人员乙负责测试，他一个月执行100 个用例，提交20个问题单，发现18个有效问题，有8个严重问题；
从上述测试执行结果来看，甲提交的问题单数量和执行用例数量都要远远高于乙，但是从测试的质量来看，模块B的遗留问题显然少于模块A,甲执行测试的充分性显然不如乙，从问题单质量来看，甲提交的问题单虽然很多，但近半数
是非问题，做了无用功，还影响到开发人员对问题的定位所消耗的时间
因此，必须要走出用问题单数量、用例数量评价测试人员的误区。
2对软件人员发现的问题的价值没有进行评估；
发现一个系统架构设计方面的缺陷和隐患远比发现几个普通界面显示问题的价值大的多；
3不重视测试文档的质量；
测试文档的质量往往是测试人员测试水平的反映；只有对系统进行了统分的、深入的测试人员才能写出高质量的测试报告；
4不重视测试人员的综合能力；
责任心、积极性、创造性以及沟通和协调能力
附：软件测试工程师业绩评估模板：（满分：100分）
软件测试工程师业绩评估模板：（满分：100分）
上级主管综合评定及意见：
附：软件测试工程师业绩评估模板
测试用例
用例完整性。对于无法执行或不具备环境不能执行 用例基本做到及时沟通，并且测试结果中具体说明
基本能按照用例模版编写用例
根据需求设计有效用例，没有覆盖所有的需求点。 用例描述基本准确、简洁、清晰，通过评审可以达 到要求。
0-2分
不能按计划执行用例并且能够及时补充用例保证用 例完整性。对于无法执行或不具备环境不能执行用 例基本做到及时沟通 能够按照规定的流程提交并跟踪 BUG 的全过程。
BUG 描述语言简洁、准确。
BUG 再现步骤清晰、条理性强，易于再现。
9-10 分
依据需求提交相应 BUG 没提交错误 BUG 能够分析和定位产生的原因，并能根据
BUG 的产生
趋势做岀有效的质量和风险风析
能够按照规定的流程提交并跟踪 BUG 的全过程。
提交的BUG W 三分之一描述语言不准确。
BUG 有三分之一出现步骤不清晰、 条理性差，难于再 现。
依据需求基本能提交相应
BUG 岀现错误BUG
测试BUG 能够按照规定的流程提交并跟踪 BUG 的全过程。
BUG 描述语言较简洁、较准确。
BUG 再现步骤较清晰、条理性较强，易于再现。 依据需求提交相应 BUG 很少提交错误 BUG 能够完成基本分析和定位产生的原因，基本并能根 据BUG 的产生趋势做岀有效的质量和风险风析。 在有人员指导情况下达到以下标准或者个人独立工 作达到以下要求： 基本能够按照规定的流程提交并跟踪 BUG 的全过程
BUG 描述语言基本完整。
BUG 再现步骤基本清晰、条理性不强，可以再现。 依据需求提交相应 BUG 岀现提交错误 BUG 能够协助开发再现，定位 bug 。 对bug 进行基本总结。
6-8分
3-5分
1、 2、
3、
4、 5、
bug 规范（1、扌| bug 描述准确性 重显性 bug 有效性 bug 总结分析能 0-2
工作能力
1计划能力（项目2、执行能力（用例
3、分析、总结能力
4、沟通、交流、协
5、业务能力（需求试技能）
工作改进
1
、
2
、
3
、
4
、
5
、
共享、培训新
知识、方法学
工具学习、引进
工作效率提升
工作质量改进
说明：共5项，每项10分，共70分
备注:
1.尽量对交付物进行评估，保持相对的客观性;
2.评估以季度为单位；
3.奖励评估结果为A、B的员工；
4.人员在试用期不参与该评估；
软件开发团队 绩效考核制度 湖南XX科技发展有限公司
目录 1目的 (1) 2方法和原则 (1) 3适用范围 (1) 4绩效考核 (1) 5项目考核内容和各阶段考核所占权重 (1) 6项目目标调整 (2) 7项目考核内容 (2) 7.1、项目进度考核 (3) 7.2、项目质量考核 (3) 7.3、项目客户满意度考核 (4) 7.4、技术资料汇总考核 (4) 9项目成员考核 (4) 10考核中的沟通与绩效考核 (5)
1目的 为更好地完善公司项目管理和软件团队内部管理机制，保证项目的按期、高效、高质完成，促进团队和员工自身的发展，特制订本制度。 2方法和原则 1、绩效考核采用项目考核和个人考核相结合的方法，以项目考核为主，个人考核为辅。 （1）、项目考核是指以项目为单位，在项目过程中，对项目所涉及的团队的阶段工作成果进行评估；在项目完结后，对参与项目的人员进行绩效考核。 （2）、个人考核是指以团队为单位，项目负责人对其项目成员的工作业绩、工作态度、团队合作等方面进行评估。 2、项目考核采用主要采用定量的原则，个人考核主要采用定性的原则。 3适用范围 本制度适用于软件开发团队所有员工。 4绩效考核 1、项目考核，项目考核分为二级考核体制，即项目考核和项目成员考核。 （1）、项目考核：项目正式立项后，由项目经理拟定《项目目标任务单》（附件1），确定项目组在该项目中项目进度、项目质量、客户满意度和技术资料汇总目标，由项目经理和项目负责人签字确认。 相应项目按照需求分析、软件设计、程序编码、软件测试、运行维护五个阶段依据《项目进度考核表》（附件2）、《项目质量考核表》（附件3）、《项目客户满意度考核表》（附件4）和《项目技术资料汇总考核表》（附件5），对项目开发情况进行评分。 （2）、项目成员考核：项目负责人接到项目后，依据项目任务单，分配任务到本组相关员工。在该项目完结后，由成员直属上司依据《项目个人工作业绩考核表》（附件6），综合项目考核得分采取强制分布，对员工项目个人业绩进行评分。 （3）、年底进行个人年度绩效考核，综合《项目个人工作业绩考核表》（附件6）及《工作态度考核表》（附件7）、《工作能力考核表》（附件8）综合评分，由项目经理填写《年度绩效考核表》（附件9）。 5项目考核内容和各阶段考核所占权重 1、项目考核内容分为项目进度、项目质量、客户满意度和技术资料汇总四个方面，其
研发人员的绩效考核 作者：李子明 很多企业的绩效考核工作常常会面临这样的问题：相对其他部门，研发部门的考核指标提取、考核方式确定都有一定的难度。这也是人力资源专业人员和研发部门管理者困惑的难题。曾经有企业试图对研发人员实行完全的定量考核，甚至提出以编写软件代码的行数作为一个重要考核指标，结果员工开始将一个命令可以解决的问题，拆分为几个命令，于是“大家都很忙，疲于写程序，工作结果完全超过了预期目标，但是软件的功能却没有实现”，完全背离了绩效考核设计的初衷，考核不得不紧急叫停。虽然这种方式停止了，但如何公正客观地评价研发人员工作业绩的问题却依然摆在管理者面前。 研发人员考核难在哪里 研发人员考核的困难主要集中于以下几点： ■ 绩效指标提取困难，由于研发人员工作本身的独特性以及工作成果不易衡量，因此难以提炼直观量化的数字性指标； ■ 工作内容界定困难，特别是预研人员，一些成果仅仅是证明某种试验或测试方法可行与否，证实与证伪具有同样的价值，难以在任务下达之前予以明确； ■ 定性内容较多，影响考核的公正性； ■ 考核方式的选取问题，很多企业的研发管理者为了回避考核的难题，而采取背后打分、不沟通的方式。 面临如此多的问题，如何对研发人员进行业绩评价呢其实，考核中最为关键的是指标和评价方式，这两者是员工工作的向导和公司的价值取向，出不得偏差，否则就可能事倍功半，甚至劳而无功了。这里，我们也从这两点出发，分析研发人员的指标提炼和评价方式。 怎样提炼绩效指标 任何一项工作的展开必然是这样的思路：“正确的行为，沿着正确的道路，达成正确的结果”，提炼绩效指标也需要沿着这样的逻辑关系，从研发成果向前推出成功的路径以及正确的行为要求，具体见下图。 研发人员的考核指标可以界定为两个方面：一个是效益指标，一个是效率指标。效益指标是研发的成果在市场中产生的价值反映，如产品销售额、市场占有率等。效率指标则是指公司内部的研发效率和阶段成果完成情况，包括路径指标和行为指标，具体如产品开发周期、研发费用、产品规划符合度、批次整改率、单板/整机直通率、产品数据准确率等等。绩效指标提炼的过程实际上就是管理程序和工作流程的分析过程： 路径指标 路径指标是衡量研发过程是否符合总体研发规划的过程检测指标。 从研发的整体流程环节看，虽然研发的成果不同，但是他们所遵循的程序是一致的，明确每一环节的关键监控点，也就可以形成考核的路径指标。这些路径指标的达成保证了最终结果的实现。 产品开发周期、研发费用等指标比较易于理解，产品规划符合度指标虽然不多见，却非常重要，下面是某公司对此的界定（见表一）。
软件测试工程师绩效评估表 一．软件测试工程师职责: 1 与软件产品部配合完成软件需求分析讨论,并根据需求说明书制定《项目测试(计划) 方案》;编写《测试用例》;建立测试环境; 2 负责研发部门各开发组研发的软件产品开发过程与投入运营之前的新增软件与修改 软件的模块测试与系统测试;建立、推广并维护实施软件版本管理系统; 3 使用并维护软件缺陷管理系统mantis,负责软件问题解决过程跟踪记录,提交《mantis 报告》; 4 负责推广实施软件开发文档规范化工作,管理研发产品相关文档; 5 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作,并提供测 试报告; 6 负责监督软件开发流程的执行,并负责提出软件开发过程改进建议,提高软件产品质 量。 7 与开发工程师与研发部门交流报告任务进展情况,并提出最近的测试需求; 8 测试部负责制订测试计划、测试用例与测试实施方案,项目主负责人安排测试与对应 的开发人员交流完成测试执行工作;及时提交准确、完整的《项目测试报告》; 9 项目主负责人负责开发流程管理与人力资源、测试用软硬件资源调配,需要与研发之 外的部门定期交流掌握下周或近期可能测试任务; 10外部接口都由测试部主管负责完成,与其她项目组与产品部门协调项目进度; 二.软件测试的不确定性: 1 软件测试的目的就就是使软件的错误不断趋进于零,但软件的错误就是永远找不完 的; 2 开始测试时,可能软件使用1个小时就出现10个错误;测试修正后1个小时出现一个 错误,继续修正,继续测试,直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。 3 测试一些成熟的游戏或应用,测试过程中很难发现大量的缺陷;而测试一些不成熟的 游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发现不同数量的bug; 4 软件测试的进度首先会按照测试计划逐步进行,但就是在测试过程中,测试进度会随研 发部门的进度而调整;所以积极的与研发部门交流、协调测试中的问题就是相当必要的。 三.测试工作最低成功标准及测试工程师考核内容: 测试工作的最终目标就就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了您没测试出来的错误,那测试就是失败的。如果使用了很久(如几个月)才出现错误,那说明测试还就是成功的。 测试工程师考核内容:
测试人员绩效评价方法 版本记录： 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照支持服务中心的部门考核大纲，该标准仅作为整体考核标准中的综合考核的一部分。 2适用范围 本标准适用于软件测试人员的考核。 3 评价标准与原则 3.1提交BUG的数量和执行测试用例的数量
测试中发现的BUG数量: 1)同一个项目组内，提交bug数 2)每人日提交的bug数 3.2测试人员发现的问题的本身价值 1)Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 2)Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判。 3.3、测试文档的质量 测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量 3.4 测试技能水平 1）测试用例设计水平 2）测试工具掌握使用水平 3）测试结果分析判断水平 3.5测试技能以外的综合能力 考察一个测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次积极的工作态度是提高测试质量，和整体团队风气的关键，沟通能力直接影响测试的工作效率与不同部门间的合作分工。 1）工作态度 2）沟通能力 3）钻研能力 4）团队合作能力 4考核办法一览表
注：缺陷分类算法： A*(1+加权系统)/(A+B+C+D+E)*20 B*(1+加权系统)/(A+B+C+D+E)*20 C*(1+加权系统)/(A+B+C+D+E)*20 D*(1+加权系统)/(A+B+C+D+E)*20 E*(1+加权系统)/(A+B+C+D+E)*20
软件研发部绩效考核方案 为加强对软件研发部门员工的技术能力、所做贡献的客观准确评价，以项目实效为导向，建立良性的技术晋升激励机制，特制订本绩效考核方案，本方案适用于软件研发部软件工程师、软件测试工程师、研发助理及质量工程师人员，具体如下： 一、岗位工资结构及绩效考核基数： 薪酬分配方式：岗位工资制。岗位工资结构：基本工资（月薪标准的50%）+岗位工资（月薪标准的30%）+绩效工资（月薪标准的20%）+交通补贴+伙食补贴+奖励考核+加班费+其他福利补贴。 绩效考核方案以绩效工资即月薪标准的20%作为考核基数，考核周期为每月进行一次考核，每月根据考核评估的总分值核算绩效工资，绩效工资核算根据考核总分值进行上下浮动， 对应绩效考核总分值兑现为月度绩效工资为： 二、绩效考核指标、考评标准、权重 将所有岗位的绩效考核指标内容分为工作业绩、工作态度、工作能力三部分，分别占有相应权重。
（二）工作态度考核关键指标（100分，权重15%）
（三）工作能力考核关键指标（100分，权重15%） （四）对项目开发和部门相关工作作出特殊贡献的给予加分的项目
对于项目开发和部门相关工作作出特殊贡献的给予加分的由部门负责人和分管副总进行评定，给予加分的需对加分项目和贡献情况进行说明，加分不得超过20分。 关键绩效考核指标总分值=工作业绩考核关键指标评分*70%+工作态度考核关键指标评分*15%+工作能力考核关键指标评分*15%+对项目开发和部门相关工作作出特殊贡献的加分。 二、其他工作指标考核内容 1、部门日常工作要求的事项完成情况考评：对其上级领导安排的工作和本岗位工作职责范围内的工作、工作态度等根据完成的时间和质量要求、工作态度好坏进行考核评定，非常优秀的可给予20-100元奖励，非常差的给予20-100元考核，此项奖励考核由部门负责人和分管副总进行评定，所有奖励考核均由分管副总审核。 2、部门所要求参与的会议/活动/培训等的参与次数及学习成果考评：公司和部门安排的会议/活动/培训要求相关人员必须参加的无特殊情况而无故不参加的给予20-50元考核，对于培训后组织的定期和不定期的培训考试，考试成绩不及格者按每次考核20-50元考核，对于以上考核属于个人特殊情况需减免考核的报请减免请示部门负责人和分管副总进行审批。 3、为了提高开发效率，积极鼓励提供好的建议，产品思路或方式方法，对于采纳的建议，如根据其执行方案对产品架构及公司发展起到明显改进效应的，将给予一定的奖励，奖励金额由分管副总和总经理进行确定。 4、产品研发项目奖励：根据产品研发项目计划，在计划进度内按质按量完成研发项目的，经测试验收合格的给予研发团队500-5000元奖励，奖励分配由该项目负责人和分管副总按照项目小组成员的贡献进行分配。 5、由公司制度对应的考核项目对其进行的奖励和考核，奖罚金额由制度所对应的管理部门依据制度条款进行确定。 6、员工个人对于部门和公司管理、产品、安装、销售等提出建议、提升、创新变革措施等/为公司生产经营做出突出贡献的，公司予以认可采纳的给予员工200-2000元奖励；同时给公司造成重大影响或损失的给予50-1000元考核，奖罚金额由总经理进行审定后确定，各部门和个人可进行奖励申请报批。 7、公司评定的优秀员工奖励：按照公司相关评定标准和奖励额度政策和通知执行。 8、其他需奖励和考核的项目：其他需进行奖励和考核的项目由奖励考核人进行提请，报由部门负责人、分管副总、总经理进行审批后确定。 三、关于绩效考核结果的反馈、申诉、处理和绩效面谈
龙源期刊网 https://www.doczj.com/doc/792938703.html, 软件测试技术与测试KPI考核体系探究 作者：魏娜娣吕晓晴霍利岭边玲武新慧 来源：《中国市场》2016年第28期 [摘要] 文章依托企业主流软件测试流程及软件测试核心技术，探究IT企业软件测试团队中现有的考核标准及规范，进而构建对接一线测试工程师岗位的KPI考核体系，并结合KPI指标及关键点，进一步优化测试知识架构，提升应用型人才培养质量及软件测试行业整体技术水平。 [关键词] 软件测试流程；KPI；考核体系；教学体系 [DOI] 10.13939/https://www.doczj.com/doc/792938703.html,ki.zgsc.2016.28.101 1 软件测试重要性及KPI考核体系构建意义 软件测试是保证软件质量的一重要手段，其在软件生命周期中的重要性日益凸显。IT企 业对软件测试人才需求量不断增多，软件测试岗位迅速扩张。 基于软件测试人才需求旺盛的现状，推进基于KPI的多元化绩效考核体系的管理模式并在试点企业中试行和同步改进，将有助于最大限度地调动工程师的工作热情、提高效率。此外，高校软件测试人才的培养往往注重知识的提升、技术的锻炼，而易忽视综合素质的培养。据企业测试人才绩效考核体系的要求，映射到软件测试体系化教学中，进一步优化软件测试教学体系，改进教学知识与技能架构，从而提升高校人才培养及实习就业质量，校企对接更加紧密。 2 软件测试KPI考核现状及应对策略 2.1 科学管理技能尚有不足 IT企业管理层往往为技术出身，具有技术背景和深厚技术功底做支撑，但对于企业管 理、团队管理领域大多未经历过系统的学习，故在管理技能和技巧上较为欠缺。据了解，一些测试经理仅关注软件缺陷的发现与跟踪，在程序员提交完整系统后才开展测试工作，从而忽略了规范化的软件测试流程及需求评审、测试计划制订、测试用例设计、测试环境构建、测试实施、测试总结与评估等关键环节的管理与人员技能的考核，与一线岗位工作内容严重脱节。 2.2 不同岗位同标准导致KPI指标雷同 不同岗位工作内容及考查点存在差异，应依据软件测试工程师、自动化测试工程师、性能测试工程师、测试组长、测试经理等分岗位、分级别制定不同层次的考核标准。否则无法高效引导，指导各岗位履行岗位职责。
季度绩效 考核内容 考核指标权重标准说明与评价方法 考核者及考 核信息来源 部门自我 评分 考核者评 分 最终得分 量化业务 指标 （50％） 工程综合管理操作违规次数 （本项考核重点考察日常工作 是否符合规范） 10 0次/季度 以违反公司工程管理工作流程规范、制度 的次数为准。（包括施工现场管理、工程 安全、工程质量、成本管理等日常工作） ＝100－A*20（A为违规次数） 以总经理、部 门经理、员工 的工作记录 为准 施工、监理单位招标差错和延误 次数（建议根据项目具体进展每 个季度制定具体指标） 5 0次/季度 是否按照公司规范进行施工、监理单位的 招标工作，有无差错和延误。 ＝100－A*50（A为差错和延误次数；一 般差错和延误A＝1，重大差错A＝2） 以总经理、部 门经理、员工 的工作记录 为准 施工方案/合同评审差错及延误 次数（建议根据项目具体进展每 个季度制定具体指标） 7 0次/季度 最终签订的施工合同是否有利于工程管 理的条款，施工方案有无差错。 ＝100－A*50（A为差错和延误次数；一 般差错和延误A＝1，重大差错A＝2） 以总经理、部 门经理的工 作记录为准 设备材料、招投标与采购监督差 错及失职次数（建议根据项目具 体进展每个季度制定具体指标） 5 0次/季度 根据材料设备的采购成本、采购进度和材 料设备质量等是否出现差错和无故延误 ＝100－A*50（A为违规次数） 以总经理、部 门经理的工 作记录为准 工程款请款差错次数 3 0次/季度 ＝100－A*50（A为违规次数）（以合同为 准） 财务部 工程安全事故数 5 0次/季度 防止出现因为工程管理审核不到位而发 生重大安全事故造成人员伤亡或重大财 产损失（包括） ＝100－A*50（A为事故次数；一般事故 A＝1，重大事故A＝2） 以总经理、部 门经理的工 作记录为准
研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制，保障研发项目的按期、高效、高质完成，同时进一步促进研发部门员工自身的发展，结合研发人员的工作特点，特制定本方案。 二、适用范围 公司研发所有员工，具体包括智能硬件产品组、电商组、APP组、大数据组转正员工。（当月 15 日（含当天）前转正本月考核，15 日后转正的次月考核） 三、考核周期：月度考核 四、考核方法与原则 考核方法 采用部门考核的方法（以产品为单位，产品负责人对其下属员工的进度、质量、规范性、工作态度及能力等方面进行评估）； 考核原则 采用行为考核与结果考核相结合。 五、考核内容与评分标准（详见附件一文件《研发人员绩效考核表》） 六、考核实施 计划沟通阶段 计划实施阶段
考核阶段 考核者根据被考核者在考核期内的工作表现和考核标准，对被考核者评分，同时被考核者也需根据个人在考核期内的工作表现和考核标准进行自评。 考核者的直接上级及主管领导对考核结果进行审核，并负责处理考核评估过程中所发生的争议。 各部门每月 10 日前组织绩效面谈会议，将上月考核结果反馈给被考核者，并讨论绩效改进的方式和途径。 七、绩效工资与考核结果运用 绩效工资运用 绩效考核结果运用 绩效面谈 考核者每月5日前对被考核者上月度的工作绩效进行总结，填写附件二《绩 效考核面谈表》，并指出被考评者有待改进的地方，从而进行差距分析，确保绩效的持续改进，同时共同制定下月的绩效目标。
相关奖励 1）根据年度 12 个月的平均得分，作为员工薪资调整、职位晋升、岗位培训的决策依据。 2）连续3个月，研发人员的进度考核为满分的，当月在绩效得分中奖励加分 5 分，连续3个月，研发人员的代码质量考核为满分的，当月在绩效得分中奖励奖励 10分。 3）培训：年度绩效考核得分在 85 分（含）以上的员工，有资格享有公司安排的提升培训，年度绩效考核得分在 70 分以下的员工，可以申请相关培训，经人力行政部批准后参加。 相关处罚 1）首次月度考核得分在 59 分（含）以下的，由直属领导进行绩效面谈，对其绩效成绩进行差距分析及进行相应的培训辅导； 2）通过部门培训仍连续 2 个月绩效考核得分在 59 分（含）以下的，公司根据员工实际业绩产出给予相应的调整（降职/降薪/解除劳动合同） 员工的绩效工资发放
目标： 为了增强部门测试工程师考核的合理性、科学性，特制定本准则，根据本准则来完成对部门所有测试工程师的考核 目前部门测试团队共有11人，进行多个项目执行的软件测试工作，同时承担着部门大量的随机测试任务、性能测试任务、自动化测试任务 在每一项考核中我们都增加了考核的权数，每个文档、用例、Bug的提交都需要与权数相乘以后才是最终的得分，所有的得分相加将是测试工程师的最终得分 指标： 1、提交测试相关文档的质量 当前部门软件测试过程主要体现测试计划、测试用例、测试报告（会有多个）几个文档，故而对文档的考核将主要依据这几个文档来完成，对文档的质量的考核将在加分、扣分中阐述，文档的质量不满足要求会出现被扣分的情况，但是扣分最多只能扣除本文档带来积分（一般一个文档1分） 文档的考核权数为1 文档总分= 所有文档的总数×0.5 2、测试设计的质量 当前在部门测试过程中，测试设计的工作比重已经逐步增多，从而带来了大量的测试设计工作，测试设计的好坏将直接决定着部门测试水平的高下；我们的测试设计分为测试项和测试用例，由于当前测试管理平台还有待改进，测试用例设计文档中对测试项和测试用例没有严格的区别，故而很难定义、分解两者，目前按照统一的标准来考核 测试设计的考核权数为0.1 测试用例总分= 所有测试用例的总数×0.1 3、Bug的提交情况 对测试中发现的Bug进行分类和定义的目的，是为测试工程师的评价提供量化依据，为Bug的有效性提供参考。在考核过程中，所有的Bug统计都基于项目组确认是Bug的前提下，项目组不认定是Bug的不记入有效Bug中、同时不记入考核积分。 前提保证：目前所有的Bug每个月都会统一汇总公布，故而减少了非正常原因被拒绝的Bug数量，提高了项目经理、BA工程师对Bug的处理准确性 ? 一级Bug（系统崩溃）
1、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效
定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。
1 、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer 认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考 核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加 团队工作，其工作效率比自己单独工作时的效率 反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害 组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队 中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim 和 Schuster 则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人 主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾 团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确 定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以 确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效
定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的 总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是 结果”的典型观点。Murphy 等人将绩效定义为“一套与组织或个体所工作的 组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着 这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础 之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其 结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度 出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却 很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受 各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言， 在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核 员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置 换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的 方法。
每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。 要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。 测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。 如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。 对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。 而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。 测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。 另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。 首先我们不能单纯的以测试人员提交的bug数量进行考核，那样的结果可能会导致测试人员为了bug 数量而互相攀比，导致bug质量的下降。 所以我觉得下面这几点可能会更合理一些（仅供讨论）： 1：有效bug率用来衡量测试人员发现的，被确认为缺陷的有效缺陷比率，比率越高则测试质量越高。这个比率剔除被开发人员拒绝修改和删除，以及重复的bug之后，剩余缺陷数占缺陷总数的一个比率。 测试人员不能只重视bug的数量，为了让领导感觉测试人员每天都在工作而随意的提交bug，从而导致bug数量很高，但质量很低。造成很多bug都被拒绝修复或者bug不能重现以及bug重复报告等问题。 2：测试覆盖率主要用来衡量测试人员对功能点遗漏测试的情况。我觉得这适合测试组人员较少的公司，每个测试人员要单独负责一个完整的项目，在这种情况下，进行这样的衡量是有必要的。 3：bug描述质量主要衡量测试人员对于bug报告的描述情况。bug报告的描述是否清晰、简洁。开发人员是否能很容易的理解并依据报告描述重现bug。很多情况下开发人员拒绝修改bug是因为bug报告的描述很难理解，并且依据描述不能重现bug等。 4：严重bug率主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷。这有助于让测试人员将注意力集中在关键问题上，减少产品的致命缺陷。 5：市场反馈缺陷率产品正是发布推向市场后，客户在使用产品的过程中发现的缺陷数占缺陷总数的比率。用来总体衡量测试组整体的工作情况。 6：最后一点，让开发人员来评估测试人员的表现。我不太肯定这样做的效果会怎么样？我的想法是：测试最直接的服务对象是开发。开发人员对于测试人员所报告的缺陷进行确认，修改（或者拒绝），对于测试人员的工作表现以及缺陷质量来说，开发人员是最有发言权的。当一个质量很高的bug被报告的开发人员那里，他们是很乐意接受这样的问题，因为你报告的bug有足够充分的理由和足够准确的描述可以说明问题，让开发人员没有借口来为自己辩解。开发人员对于这样的问题会有很好的印象。所以我觉得让开发人员来评估测试人员的表现可以作为考核测试人员的一个重要依据。
软件测试工程师业绩评估标准 Testing：Liuying 2007-01-30 一．软件测试工程师职责： 1 与软件产品部配合完成软件需求分析讨论，并根据需求说明书制定《项目测试（计划）方案》；编 写《测试用例》；建立测试环境； 2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改软件的模块测 试和系统测试；建立、推广并维护实施软件版本管理系统； 3 使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录，提交《buglist报告》； 4 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 5 负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报 告； 6 负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。 7 与开发工程师和研发部门交流报告任务进展情况，并提出最近的测试需求； 8 测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交 流完成测试执行工作；及时提交准确、完整的《项目测试报告》； 9 测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交 流掌握下周或近期可能测试任务； 10外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度； 二．软件测试的不确定性： 1 软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找不完的； 2 开始测试时，可能软件使用1个小时就出现10个错误；测试修正后1个小时出现一个错误，继续 修正，继续测试，直到约一个月出现一个错误。这时这个出错几率客户已经可以接受了（如win98系统）。那么测试就结束了。交货之后测试工作由客户来进行（使用过程中）。 3 测试一些成熟的模块，测试过程中很难发现大量的缺陷；而测试一些不成熟的模块，在测试前期， 会出现大量的问题；这样就导致不同的工程师发现不同数量的bug； 4 软件测试的进度首先会按照测试计划逐步进行，但是在测试过程中，测试进度会随研发部门的进度 而调整；所以积极的与研发部门交流、协调测试中的问题是相当必要的。 三．测试工作最低成功标准及测试工程师考核内容： 测试工作的最终目标就是发现客户可能发现的所有错误。如果客户在使用第一天就发现了你没测试出来的错误，那测试是失败的。如果使用了很久（如几个月）才出现错误，那说明测试还是成功的。 测试工程师考核内容： 1 测试工程师比开发工程师更了解产品；（产品各模块总体把握能力） 2 测试工程师能从客户的角度来检测软件的功能；（用户身份） 3 测试工程师获取资料，使得编制的测试用例更切合测试的重点、难点以及关注点； （编写测试用例） 4 测试工程师比开发工程师更容易发现产品的问题；（不同的思维模式）
绩效考核方案 为加强部门员工的技术能力、所做贡献的客观准确评价，以项目实效为导向，建立良 性的技术晋升激励机制，特制订本绩效考核方案，本方案具体如下： 一、绩效标准： 公司提取项目利润值的 5-15% 作为项目组绩效奖励，项目组成员个人所占比例由组长分 配，当项目组无法协调分配比例的时候由公司合算比例，并拥有最终解释权。 考核周期按照项目周期考核，根据考核评估的总分值核算绩效工资，绩效工资核算根 据考核总分值进行上下浮动，对应绩效考核总分值兑现为月度绩效工资为： 积分总值121 分及以 101-120 分91-100 分71-90 分70 分及以下区间上 小组对应绩 利润值 *15%利润值 *12%利润值 *10%利润值 *7%利润值 *5%效结果兑现 二、绩效考核指标、考评标准、权重 将所有岗位的绩效考核指标内容分为工作业绩、工作态度、工作能力三部分。项目组初始 得分为 100 分，根据评估加减确定最终得分。 （一）工作业绩考核关键指标（权重70% ） 人员类型关键业绩指标考核目标值 实际开发周期比计划周期提前及延后 新产品开发周期 进度延迟1-10% ，减 2 分； 进度延迟11-20% ，减 5分； （月度计算） 进度延迟21-50% ，减 10 分； 进度延迟51% 及以上，减 20分 如提前完成工作，做相同比例加分 项目小组 质量测试，依据普通、严重、致命Bug 计分代码质量 普通 bug ，减 1 分 / 个 严重 bug ，减 2 分 / 个 致命 bug ，减 5 分 / 个 代码编写、注释，凌乱低劣，减1-5 分 代码编写标准 代码编写、注释，符合标准，加1-5 分设计的可生产性根据设计图的可生产性加1-5分 策划对产品需求收集、分析、整理、标注的程 产品需求分析收集 度，视情况加减1-5 分权重20% 20% 10% 10% 10%
测试人员考核标准 版本记录： 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照安徽移动业务支撑项目考核指标体系的部门考核大纲，该标准仅作为整体考核标准中的综合考核的一部分。 2适用范围 本标准适用于信息系统部软件测试人员的考核。 3 评价标准与方式 3.1每月提交BUG的总数 评价标准：每人每月提交的bug总数。 评价方式：由测试人员通过change系统来统计。 3.2测试人员上线失败率 评价标准：每次上线单失败回退情况。 评价方式：由测试经理通过上线失败反馈信息来统计。
3.3测试文档的质量 评价标准： 1)测试报告的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深 入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质 量； ①.报告描述是否清晰； ②.报告分析是否到位； ③.报告描述语言是否规范。 2）测试用例构成了设计和制定测试过程的基础，测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。 ①.用例是否包含了对中间和后台数据的检查； ②.用例是否覆盖需求要求的所有功能点； ③.用例是否包含了被测对象中所有异常流的测试。 3）缺陷问题描述 ①.问题描述是否清晰； ②.问题定位信息内容是否完整； ③.问题描述语言是否规范。 评价方式：由测试经理对测试报告、测试用例审核时对文档质量评分。 3.4测试技能以外的综合能力 评价标准： 1）考察一个测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次积极的工作态度是提高测试 质量，和整体团队风气的关键，沟通能力直接影响测试的工作效率与不同部门间的 合作分工。 ①.工作态度 ②.沟通能力 ③.钻研能力 ④.团队合作能力 评价方式：由测试经理对测试人员进行综合能力评分；
研发人员绩效考核指标公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]
研发人员绩效考核指标标准的提炼与确定 关键词：研发人员+绩效考核指标 1.研发人员绩效考核指标制定存在的问题及对策 2.怎么制定研发人员绩效考核指标 3.研发人员绩效考核指标怎么设计 4.研发人员绩效考核指标提取方法 5.【研发人员绩效考核指标】研发人员绩效考核指标制定——华恒智信 咨询 文章描述:研发人员作为企业核心部门的成员，在企业发展中起着十分关键的作用。而由于研发人员及其工作的特殊性，企业现有的研发人员绩效考核指标的制定存在诸多问题，影响了研发人员的工作积极性，对研发人员绩效考核指标的设计也成了企业绩效管理的重点和难点。那么研发人员绩效考核指标的制定出现了什么问题，我们又应该如何科学合理的提取研发人员的绩效考核指标呢本文由人力资源专家——华恒智信分析员结合咨询行业的实战经验总结了研发人员绩效考核指标的制定问题，以期大家有所借鉴。 引言： 随着市场需求的不断变化，企业不能再靠做一个产品来获取高额利润，而应把发展重心转到研发。研发人员作为企业核心部门的成员，在企业发展中起着十分关键的作用。而由于研发人员及其工作的特殊性，企业现有的研发人员绩效考核指标的制定存在诸多问题，影响了研发人
员的工作积极性，对研发人员绩效考核指标的设计也成了企业绩效管理的重点和难点。那么研发人员绩效考核指标的制定出现了什么问题，我们又应该如何科学合理的提取研发人员的绩效考核指标呢本文由人力资源专家——华恒智信分析员结合咨询行业的实战经验总结了研发人员绩效考核指标的制定问题，以期大家有所借鉴。 绩效管理是一种对公司的资源进行规划、组织和使用，以达到某个目标并实现顾客期望的过程。企业满足客户的过程一般是通过了解客户需求的前提下，设计研发出符合客户期望和需求的产品或者是提供客户所希望的服务的过程，那么针对提供产品的企业来说，其研发人员就是决定其产品是否具有市场前景和吸引力的核心所在，对其进行有效的约束和激励有助于企业产品与时俱进的更新换代，能够随时满足客户的需求并且提升组织绩效。 诚然，目前企业对研发人员的绩效指标的制定普遍存在一些问题： 1、绩效指标提取困难，由于研发人员工作本身的独特性以及工作成果不宜用时间/产出来衡量，因此难以提炼直观量化的数字性指标； 2、工作内容界定困难，因此导致绩效指标无法清晰确定，一些成果仅仅是证明某种试验或测试方法是否可行，难以在任务下达之前予以明确； 3、定性的考核内容较多，不利于绩效考核的公正性； 综合以上问题的出现，导致其绩效考核过程无法有效的进行，与绩效考核挂钩的薪酬管理、培训开发等随之出现问题，例如：薪酬浮动比
工程部绩效考核管理制度 一、目的： 为提高工程部人员工作积极性，客观、公平、公正的对部门人员进行考核评价，为部门内各位员工的的竞升、年终考评提供依据。二、考评原则： 根据岗位职责和工程管理特点，采用百分制月考核、年终考核，主要从岗位职能指标（65分）、行为指标（20分）、纪律评价（15分）三大方面考核。年考核以月考核平均分数计，若出现评分细则中考核不合格情况，则年终考核也为不合格。 三、评分细则： 结合工程管理实际、工程管理人员岗位职责要求，从岗位职能指标（65分）、行为指标（20分）、纪律评价（15分）三方面综合考核。 1、岗位职能指标（65分）分为安全文明施工、工程质量控制、进度控制、投资控制、合同资料管理、协调等6项指标： 安全文明施工管理（18分）：安全文明施工达市标化工地或得到市建设主管部门通报表彰的，得14-18分；符合正常建设施工要求、无安全事故的，得8-13分；安全文明施工不合格或市建设主管部门通报批评、无安全事故的，得0-7分；有安全事故发生，将不考虑其他项目得分，综合考评为不合格。 工程质量控制（16分）：考核期限内工程质量达市优及以上的，得13-16分；工程质量符合合格标准的，得8-12分；工程质量不合格，得0-8分；若出现分部工程质量不合格或出现工程质量事故者，
将不考虑其他项目得分，综合考评为不合格。 工程进度控制（9分）：考核期限内工程进度控制满足合同约定的工期并按计划提前完成，得7-9分；按合同工期或确定计划完成，得5-7分；滞后合同约定工期或确定的施工计划完成，得0-5分，每滞后5天，减2分；若滞后工期占总工期1/5及其以上者，将不考虑其他项目得分，综合考评为不合格（其他因素影响除外）。 合同资料管理（9分）：熟悉分管工程的各项目分包合同（劳务合同、材料采购合同、机械租赁合同、分包施工合同等），认真履约，做好预控，跟踪检查农民工工资发放情况，及时收集整理、归档、移交相关资料的，得7-9分；按要求时限完成合同管理、资料管理的，得5-7分；滞后者，每滞后一天减1分；因管理混乱，发生班组因欠薪上访相关职能部门或聚众闹事阻碍正常施工等，给工程部管理造成较大影响或给公司造成损失的，将不考虑其他项目得分，综合考评为不合格。 投资控制（8分）：考虑到方案优化组合，按公司制度规定办理、为公司节约工程造价的，得6-8分，节约金额20万及以上的（含项目部费用支出情况），建议公司给予经济奖励；按公司制度要求进行投资控制的，得4-6分；不按公司制度控制，得0-4分；违反公司制度、对公司造成较大损失的，将不考虑其他项目得分，综合考评为不合格（其他因素影响除外）。 协调管理（5分）：能按要求及时协调完成相关事宜，得3-5分；不能及时协调完成，对工程施工造成影响的，得0-3分；因协调不当，