测试工程师-绩效考核
月度绩效评价表
被考核人部门岗位测试工程师考核人考核周期
评价项目/指标本月目标评价标准与方法权重本月实绩评价得分
行为指标=100%1.服从上级安排
2.严格遵从《测试与质量管控部--部门工作条例》
3.工作积极主动，能够快速理解并解决工作中遇到的问题
4.监控任务的进度与过程质量，及时发现潜在问题并提出合
理方案
30
项目讨论会未参与数=0参与项目讨论会，并根据讨论结果给出项目测试计划，少1
次扣3分
10
测试用例不完善数=0每1个项目或者功能模块的测试用例不完善扣3分20
测试任务未及时完成数=0已完成的项目中，至少完成两轮测试，每轮未及时完成（因
特殊原因导致的除外）1个项目扣3分
20
bug未跟进数≤1运营已报告给测试部门的线上bug、测试过程中提交的bug的
后续跟进情况：
1.少跟进2-3个bug扣2分
2.少跟进4-6个bug扣3分
3.少跟进6-8个bug扣6分
4.少跟进8个以上bug，0分
10
线上项目出现bug数≤1项目上线后出现的bug次数：
1.出现2-3个bug，扣3分
2.出现4-6个bug，扣6分
3.出现6个以上bug，0分
10
分项加权合计分值
加/减分项目加/减分值合计绩效评价总分总分=分项加权合计分值+加/减分值
目标确认考核人：被考核人：
评价结果确认考核人意见：被考核人意见：
工程部弱电工程师月绩效考核表
月度绩效考核表（A） 第一章总则
第一条适用围 本方案适用于除总经理、副总经理外的全体正式员工。 第二条考核目的 1、通过奖优罚劣的手段，让员工发现自身存在的具体不足，促使员工不断改进、不断提高，进而提升公司整体效益。 2、建立良好的价值评价体系，肯定员工的付出，使员工明确自身的责任和价值，让员工有使命感，从而驱动员工发挥潜力、积极创造价值。 3、通过考核沟通，形成公司良好的上下沟通关系，建立畅通的沟通渠道。 4、为员工的加薪晋级提供重要的量化依据，公正公平，让员工保持良好的精神状态，提高员工工作积极性、主动性、工作效率和市场竞争力。 5、促进各部门相互协作，增进团队合作精神，强化管理层的责任意识，提高管理水平，指导下属提高工作效率和工作绩效，保障组织高效运行。 第三条考核原则 6、以提高员工绩效为导向； 7、定性与定量考核、个人与部门考核相结合； 8、多维度考核； 9、公平、公正、公开。 第四条考核用途 考核结果的用途主要体现在以下几个方面： 10、绩效工资基数的确定
11、年终奖 12、加薪（年度加薪及日常加薪） 13、岗位调动 14、评选优秀员工 15、其他有涉及到考核的各项福利制度。 第二章考核组织管理 第五条公司考核小组职责 为有效推进本考核方案，提高考核的公正、公平性，公司成立考核小组负责考核方案的组织与执行。考核小组由公司高管及各部门主管组成。 其职责如下： 1、负责制订高管人员和各部门主管的考核细则； 2、最终处理员工考核申诉。 第六条考核小组办公室职责 公司行政人事部是考核工作组织执行机构，是考核小组办公室，主要负责： 3、在各部门的协助下，进行各岗位的职位分析，制订员工考核管理制度的实施细则； 4、对各项考核工作进行培训与指导，并为各部门提供相关咨询； 5、对考核过程进行监督与检查，对考核过程中不规行为进行纠正与处罚； 6、通报公司员工考核工作情况； 7、协调、处理员工考核申诉的具体工作；
测试部门KPI考核指标(绩效考核)
测试部门 KPI 考核指标（绩效考核） 评分标准说明MAX 权重SCORE 工作内容和 0.3 质量（ 60%） 9-10分：需求理解无 误，并能提出需求疑完整理解需求，出 点 。现疑问能及时与 需求熟7-8 分：完整理解需 产品经理确认， 完 求 。成测试时不能出10 10% 1 悉程 度 4-6 分：理解需求，现对主要功能点 上线后无重大 BUG。的需求存在误差 0-3 ：上线后有重大 问的问题。 题 9-10分：平均覆盖率 达到 95% 测试 用 7-8 分：平均覆盖率 达到 90% 例覆 盖10 30% 3 4-6 分：平均覆盖率 度 达到 80% 0-3 ：平均覆盖率未 达 到 80% 9-10分：测试用例设 计优化，结构清晰，可执行性高，描述简 测试用洁明了 可测试性7-8 分：测试用例完 例完 成完整性10 10% 1 整，可执行性一般 质量描述简洁明了 4-6 分：测试用例基 本完整 0-3 ：测试用例不完 善，可执行性 差 10 分：提交 BUG 都为 需要修改的 BUG。 7-8 分：有1-2 个无确实为系统BUG。
有效 效 BUG 至于是否已修 改、 10 20% 2 BUG 率 4-6 分：有 3-5 个无 延后修改、 不处理 效 BUG 皆不考虑。 0-3 ：有 5 个以上 无效 BUG
9-10 分： BUG 描述 规 范清晰，简洁明了， 能有效按步骤重现 7-8 分： BUG 描述一 BUG 描 般，能有效按步骤重 现 10 5% 0.5 述质量 4-6 分：BUG 描述与实 际有出入，通过沟通 能重现 0-3 ：BUG 描述混 乱， 不能理解 9-10 分：测试报告 清 晰明确并能及时发 出，重点问题能在报 测试报 告中体现。 7-8 分：测试报告及 10 10% 1 告质量 时发出，包含基本内 容。 4-6 分：有测试报告 0-3 ：无测试报告 10 分： 0 个产品未 按 时完成 按时完 7-8 分：1 个产品未 按 成工单 时完成 非测试个人原因 10% 1 的测试 4-6 10 分：2-4 个产品未 导致测试延后的 工作 按时完成 0-3 ：5 个以上产品 未 按时完成 9-10 分：及时关注 产 品研发进度及 BUG 状 态，有问题时能及时 反映，推动测试进行 7-8 分：经提醒后， 进度更 能更新产品进度及 产品进度跟踪， 产 新，BUGBUG 状态 品状态维护， 产品 10 5% 0.5 跟踪 4-分：产品进度没 BUG 状态更新等
测试人员绩效评价标准
测试人员绩效评价方法 版本记录： 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
工程部弱电工程师月绩效考核表
月度绩效考核表(A)
第一章总则 第一条适用范围本方案适用于除总经理、副总经理外的全体正式员工。 第二条考核目的 1＞通过奖优罚劣的手段，让员工发现自身存在的具体不足，促使员工不斷改进、不斷提高，进而提升公司整体效益。 2、建立良好的价值评价体系，肯定员工的付出，使员工明确自身的责任和价值，让员工有使命感，从而驱动员工发挥潜力、积极创造价值。 3、通过考核沟通，形成公司良好的上下沟通关系，建立畅通的沟通渠道。 4、为员工的加薪晋级提供重要的量化依据，公正公平，让员工保持良好的精神状态，提高员工工作积极性、主动性、工作效率和市场竞争力。 5、促进各部门相互协作，增进团队合作精神，强化管理层的责任意识，提高管理水平，指导下属提高工作效率和工作绩效，保障组织高效运行。 第三条考核原则 6、以提高员工绩效为导向; 7、定性与定量考核、个人与部门考核相结合;
8、多维度考核； 9、公平、公正、公开。 第四条考核用途 考核结呆的用途主要体现在以下几个方面： 10、绩效工资基数的确定 11＞年终奖 12、加薪（年度加薪及日常加薪） 13、岗位调动 14、评选优秀员工 15、其他有涉及到考核的各项福利制度。 第二章考核组织管理 第五条公司考核小组职责 为有效推进本考核方案，提高考核的公正、公平性，公司成立考核小组负责考核方案的组织与执行。考核小组由公司高管及各部门主管组成。 其职责如下： 1、负责制订高管人员和各部门主管的考核细则： 2、最终处理员工考核申诉。 第六条考核小组办公室职责 公司行政人事部是考核工作组织执行机构，是考核小组办公室，主要负责： 3、在各部门的协助下，进行各岗位的职位分析，制订员工考核管理制度的实施细则；
测试绩效考核
测试绩效考核 篇一：测试人员绩效考核详细 绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。?zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差
异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科
软件测试工程师绩效评估表
软件测试工程师绩效评估表 一．软件测试工程师职责： 1 与软件产品部配合完成软件需求分析讨论，并根据需求说明书制定《项目测试（计划） 方案》；编写《测试用例》；建立测试环境； 2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改 软件的模块测试和系统测试；建立、推广并维护实施软件版本管理系统； 3 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 4 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作，并提供测 试报告； 5 负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质 量。 6 与开发工程师和研发部门交流报告任务进展情况，并提出最近的测试需求； 7 测试部负责制订测试计划、测试用例和测试实施方案，项目主负责人安排测试与对应 的开发人员交流完成测试执行工作；及时提交准确、完整的《项目测试报告》； 8 项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之 外的部门定期交流掌握下周或近期可能测试任务； 9外部接口都由测试部主管负责完成，与其他项目组和产品部门协调项目进度； 二．软件测试的不确定性： 1 软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找不完的； 2 开始测试时，可能软件使用1个小时就出现10个错误；测试修正后1个小时出现一 个错误，继续修正，继续测试，直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。 3 测试一些成熟的游戏或应用，测试过程中很难发现大量的缺陷；而测试一些不成熟 的游戏或应用，在测试前期，会出现大量的问题；这样就导致不同的工程师发现不同数量的bug； 4 软件测试的进度首先会按照测试计划逐步进行，但是在测试过程中，测试进度会随研 发部门的进度而调整；所以积极的与研发部门交流、协调测试中的问题是相当必要的。 三．测试工作最低成功标准及测试工程师考核内容： 测试工作的最终目标就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了你没测试出来的错误，那测试是失败的。如果使用了很久（如几个月）才出现错误，那说明测试还是成功的。 测试工程师考核内容： 1 测试工程师比开发工程师更了解产品；（产品各模块总体把握能力） 2 测试工程师能从客户的角度来检测软件的功能；（用户身份） 3 测试工程师获取资料，使得编制的测试用例更切合测试的重点、难点以及关注点；
公司工程部绩效考核管理细则
苏州龙湖嘉园项目工程进度、质量 内部考核管理细则 1.目的 为了进一步抓好项目工程质量，确保苏州·龙湖嘉园项目严格按照集团公司“大样板”工程要求顺利实施，并按苏州分公司年度计划目标完成各项工作节点。 2.原则 依据集团公司总经理2013年工作报告、2014年3月7日集团公司质量大会、2014年集团公司质量管控目标的精神及要求，全面落实工程部各专业工程师岗位职能制，奖优罚劣。 3.适用范围 苏州分公司工程部各专业工程师 4.考核办法 4.1每月工程部各专业工程师必须严格按照分公司工程部进度计划分解个人工作计划并按时上报。 4.2针对每月集团公司质量控制部项目检查中发现的质量问题，各专业工程师要在规定的时间内及时进行反馈并关闭。同时将根据每月集团公司质量控制部项目检查评分结果，结合工程部各月项目检查结果及评分情况，对各专业工程师的当月绩效工作完成情况进行对应考核，具体考核办法如下： 4.2.1项目质量检查评分在80分以上者，当月个人绩效总分不扣分；
4.2.2项目质量检查评分在70-79分，当月个人绩效总分扣5分； 4.2.3项目质量检查评分在60-69分，当月个人绩效总分扣15分； 4.2.4项目质量检查评分在60分以下的，当月个人绩效总分扣20分； 4.3针对每月集团公司工程管理部项目检查中发现的项目现场安全、文明施工问题，各专业工程师要在规定的时间内及时进行反馈并关闭。根据项目工作计划完成情况及个人月度工作计划完成情况进行考核。考核人员必须依据客观事实对被考核人进行严格公正的考核，如发现考核人员营私舞弊，一经查实，对考核人员进行加倍处罚。 以上内部考核管理细则从2014年3月份开始实施。 2014年3月27日 龙湖集团苏州分公司
工程部弱电工程师月绩效考核表
关注我 实时更新 最新资料 建筑 月度绩效考核表（ A ） 被考核人信息 2014年 05 姓名 许 XX 部门 工 程部 岗位 弱电工 程师 考核期 月 考核表使用说明： 本表仅适用于总经理助理级、职能部门经理级 /副经理级/经理助理级/主管级，由人事行政部留存； 本表采用初评、终评相结合方式，最终得分以终评结果为准，具体评分关系见下表： 考核层级 总经理助理级 初评 — 终评（最终得分） 总经理 职能经理级、副经理级 主管副总经理 总经理 职能经理助理级、主管级 — 部门负责人 考核 指标 初评 终评 得分 指标描述 分值 得分 责任心强，工 作积极主动，认真负责，乐于奉献。 廉洁公正，严格遵守公司 的各项规章制度。 1 3 工 作 态度 具备良好 的执行力，严格执行和遵从公司及上级领导提出 的各项工 作要求。 3 主动向上司汇报各项工 作开展情况；主动与同事沟通、联系工 作等。 2 10分 具备良好 的团队合作精神。 小计 1 10 专业知识与技能达到本职岗位要求，并能给予其他人专业指导。 良好 的沟通协调能力，善于协调各方关系，促进各项工 作顺利开展。 2 2 正确理解工 作目标，合理制定工 作计划，能够辨别工 作轻重缓急，有条理地处理各项 事务。 2 综合 能力 在系统分析和理性判断 的基础上，进行果断、合理 的决策。 团队成员任务分配明确，协作效率较高，团队工 作热情高涨。 1 2 10分 具备良好 的创新意识和能力，打破惯性思维，能够提出合理化工 作建议，工 作中有新 思路、新方法。 1 小计 10 15 工 作 严格按照公司各项工 作流程开展工 作，质量绩效达到公司标准要求。 质量 积极面对并努力克服困难，尽力避免问题 的发生。 5 20 5 20分 小计 提前或按计划完成既定工 作任务及上司安排 的各项工 作任务。 各项工 作跟进及时、到位。 工 作 效率 5 10分 10 25 20 小计 能够按要求履行好本岗位职责、工 作内容。 工 作 业绩 定期对管辖范围内相关工 作进行监督、检查与指导 ，并跟进整改效果。 完成上司交办 的各项工 作。 小计 5 50分 50 合计 100 初评人签字 终评人签字
测试部绩效考核方案【最新版】
测试部绩效考核方案 考核工作事项及流程 1、季度工作总结。部门员工完成《员工季度工作总结》 2、部门考核。按照考核工作要求，组织员工考评，填写《季度员工绩效考核互评》，部门领导填写《季度员工绩效考核表》 3、考核结果审定。部门领导审核。 4、绩效沟通。考核结果公布后，有部门经理、组长进行绩效沟通工作 5、考核工作总结。对本部门员工绩效考核情况进行总结，并提交部门年度考核工作总结报 告以便于持续改进工作 6、考核兑现。对考核结果进行兑现 考核指标
1.完成工作量(10%) a)季度内在整个小组中完成的工作量最高 b)季度内在整个小组中完成的工作量较高 c)季度内在整个小组中完成的工作量一般 d)季度内在整个小组中完成的工作量最低 2.测试的水平(15%) a)测试过程质量令人放心，基本能全部测出一般情况下的bug外，还能测出隐藏很深的bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的 b)测试过程质量较好，基本能全部测出一般情况下的bug，隐藏很深的bug偶尔能测出，在整个测试组来说，出于中上水平 c)测试过程质量一般，能测试出大部分一般情况下的bug，但总觉得欠火候，在整个测试组内来说，处于中间水平
d)测试过程质量很差，有明显的bug没有测试出来，在整个测试组内来说，相对很差 3.测试用例质量(15%) a)测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的 b)测试用例编写质量较好，编写的内容虽然有时候通不过，但明显看出是经过认真思考了的 c)测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平 d)测试用例编写质量很差，文档只是设计到了梗概，很多细节都没有描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去，在整个测试组内来说，是相对最差的 4.缺陷描述(10%)
测试人员绩效考核详细
绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易 造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在 组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ?Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的 共享和绩效的提高，降低团队工作的优势。 ?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方 面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。 Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。 基于项目团队生命周期的绩效考核: ?孵化诞生期: 这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。 ?考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团 队，所以考核的对象是个人。 ?考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因 此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。同时， 成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持， 所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成 长、问题解决、责任承担、领导技能等等。因此，在选择项目团队成员的时候，通过对被选者专业技能、基 本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。 ?成长期:这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究
研发测试人员绩效考核奖励细则
研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制，保障研发项目的按期、高效、高质完成，同时进一步促进研发部门员工自身的发展，结合研发人员的工作特点，特制定本方案。 二、适用范围 公司研发所有员工，具体包括智能硬件产品组、电商组、APP组、大数据组转正员工。（当月 15 日（含当天）前转正本月考核，15 日后转正的次月考核） 三、考核周期：月度考核 四、考核方法与原则 考核方法 采用部门考核的方法（以产品为单位，产品负责人对其下属员工的进度、质量、规范性、工作态度及能力等方面进行评估）； 考核原则 采用行为考核与结果考核相结合。 五、考核内容与评分标准（详见附件一文件《研发人员绩效考核表》） 六、考核实施 计划沟通阶段 计划实施阶段
考核阶段 考核者根据被考核者在考核期内的工作表现和考核标准，对被考核者评分，同时被考核者也需根据个人在考核期内的工作表现和考核标准进行自评。 考核者的直接上级及主管领导对考核结果进行审核，并负责处理考核评估过程中所发生的争议。 各部门每月 10 日前组织绩效面谈会议，将上月考核结果反馈给被考核者，并讨论绩效改进的方式和途径。 七、绩效工资与考核结果运用 绩效工资运用 绩效考核结果运用 绩效面谈 考核者每月5日前对被考核者上月度的工作绩效进行总结，填写附件二《绩 效考核面谈表》，并指出被考评者有待改进的地方，从而进行差距分析，确保绩效的持续改进，同时共同制定下月的绩效目标。
相关奖励 1）根据年度 12 个月的平均得分，作为员工薪资调整、职位晋升、岗位培训的决策依据。 2）连续3个月，研发人员的进度考核为满分的，当月在绩效得分中奖励加分 5 分，连续3个月，研发人员的代码质量考核为满分的，当月在绩效得分中奖励奖励 10分。 3）培训：年度绩效考核得分在 85 分（含）以上的员工，有资格享有公司安排的提升培训，年度绩效考核得分在 70 分以下的员工，可以申请相关培训，经人力行政部批准后参加。 相关处罚 1）首次月度考核得分在 59 分（含）以下的，由直属领导进行绩效面谈，对其绩效成绩进行差距分析及进行相应的培训辅导； 2）通过部门培训仍连续 2 个月绩效考核得分在 59 分（含）以下的，公司根据员工实际业绩产出给予相应的调整（降职/降薪/解除劳动合同） 员工的绩效工资发放
工程部造价人员绩效考核表
工程部造价人员绩效考核表被考核人姓名：职位：部门： 考核人姓名：职位：部门： KPI指标分值绩效目标自评项目负 责人 部门经 理 工作态度 10 工作的服从性高，工作主动性强，具有敬业精神 工作纪律 10 能够遵守公司的各项规章制度、工作考核规定、造价人员取业道德准则及公司有关廉政律建设的要求 工作能力 10 按照咨询程序开展工作，具有较强的专业水平、协调沟通能力、处理问题能力 工作表现 10 工作完成质量好、效率高，具有很好的团队协作性，业主及承建单位的信息反馈良好 资料控制 10 1.缺少咨询、施工合同及相关关补充协议的，每缺少项扣1分: 2.缺少与最终咨询成果义件相关的文件、纪要和函件的，每缺少一项 扣0.5分; 3.无接受、归还和移交归档清单的每缺少一项扣0.5分。 质量控制 50 1、咨:询成果义件如出现工程量或计量单位有误、单价小含埋、项目漏项、顶目特征及工程内容不明确、项目编码、项目名称等小符合计价规范势求的，每发现一处扣0.5分; 2、采用的消耗量定额、取费标准、材料及设备价格有误、套用消耗量定额项目错项、漏顶、重项、计价程序、取费基数出现错误的，每发现一处扣0.5分; 3、咨询成果文件无项目负责人签字的扣5分； 4、工程变量与现场签证审核的依据不充分，设计变更手续、签证程序无相关专业造价工程帅签字的、内容与实际情况不符，变更计价方式不合理，并末就此向委托方提出合理建议的，每发现一处扣5分； 5, 工程进度款的审核与确定不符合合同相关支付条款的，计价基数有误.工程量的核定出现重项、漏项和汁算错误的，中期付款报介的签发程序及时间不符合施工合同要求的，每发现一处扣5分。 考核得分 对应考核等级A(100-90) B(89-80) C(79-60) D(59-0) 被考核人（签字）：主管领导（签字）：总经理（签字）：
软件部绩效考核要求规范
软件部绩效考核方案 第一部分、考核对象 研发全体人员 第二部分、工作职责 一、项目经理 与客户方对接需求，合理分配部资源，统筹所负责项目的整体规划，监控跟踪开发过程进度，着手解决棘手问题，并应对突发情况对项目整体计划做出调整。 二、开发人员（程序员、中级程序员、高级程序员） 根据需求文档，在项目经理的任务划分负责围，按效率每天完成固定功能的编码工作，并承担该部分的维护工作。 三、测试人员 按指定的文档编写测试用例，并对相关项目进行单元，集成及系统测试工作。 四、美工人员 负责直接和客户沟通UI方面的相关业务，并针对所负责项目的软件交互进行美术及交互设计,并按需切图，主要输出产物为牵引图，UI指引，拓展图，PSD原图，及切图。 第三部分、开发及测试人员的考核容（初，中，高） 一、质量考核 1. 度量指标
质量度量主要是根据度量指标来进行评价的；质量指标是指软件开发程序缺陷率（bug的数量）。 2. 度量指标计算方法 （1）度量指标评分标准 根据软件开发程序的缺陷率（bug量）来确定，缺陷率越高，其评价分就越低。 （2）缺陷率来源 主要是软件经过测试组测试后，所产生的测试报告； ◆软件交付使用后一年产生的软件维护记录表; ◆开发人员的缺陷率考核，主要依据测试报告和软件维 护记录； ◆测试人员的缺陷率考核，依据软件维护记录。 （3）缺陷率单位 以程序单元为单位，相比较而得出缺陷率的值（原理：缺陷数/单元总数）。这里所指的程序单元，是WBS分解后的容。 （4）开发人员缺陷率计算方法 根据测试报告和软件维护记录中的缺陷类别，分别统计各类别的缺陷率，然后依据度量指标的计分标准表
软件测试人员绩效考核详细
1、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效
定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。
工程师绩效考核标准
工程师绩效考核标准 一：考核总则 为了提高项目工程师的积极性，主动性，创造性，自身的责任感，提升工程师的创新能力，为了在公司内部形成有团结，讲效率，重结果的良好职业气氛，为了体现公平，公正的原则，根据公司的发展规划，与工程师现在工作的情况，特制定本管理制度； 二：考核对象 适用于工程部各项目工程师； 三：考核周期 项目工程师每月考核一次，年底进行汇总，作为项目工程师工作的评价标准； 四：考核的内容 1：考核的权责 1.1部门负责人按每月对项目工程师的工作完成情况进行考核，并呈交给副总经理或总经理核定； 1.2工程部每月月底开会公布考核结果； 2：考核的结果与薪资，职称，奖金，福利待遇挂钩； 3：考核的项目与标准 3.1样品的品质，样品质量问题必须在界定责任的情况下，项目工程师必须保证图纸，加工工艺正确，失效模式分析有效与过程控制完善的情况下，项目工程师将不承担任何责任，反之，项目工程师都必须承担责任（全部责任，主要责任或次要责任，客户原因的品质问题
将不算在考核里）； 3.1.1样品的客诉，以QIP为依据，样品的客诉不能超过样品完成 数量的_%； 3.1.2样品的返工，客户反馈问题返工，以QIP为依据，内部返工， 以样品问题总结会为依据，样品的客诉不能超过样品完成数量的_%； 3.1.3样品的退货，以QIP为依据，样品的客诉不能超过样品完成 数量的_%； 3.1.4样品报废，需重新加工，因质量问题，导致客户不能使用，无法返工，需重新加工的样品，以QIP为依据，内部报废，以样品问题总结会为依据，界定责任人，样品的报废不能超过样品完成数量的_%； 4：样品的交付数量 4.1每月交付的合格样品数量为__PCS（投诉，返工，退货，报废均不计交付的样品数量）； 4.2每月成功导入的量产的产品； 5：样品的交付率 5.1客户的配件，包材，更改图纸影响的交付，不影响交付率；5.2样品制作过程中的延期，不影响项目工程师的考核交付率；5.3因图纸，制定的工艺，失效模式分析等原因引起的延期，将影响工程师的绩效考核； 6：创新与改善能力
软件测试人员绩效考核详细
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有足够充分的理由和足够准确的描述可以说明问题，让开发人员没有借口来为自己辩解。开发人员对于这样的问题会有很好的印象。所以我觉得让开发人员来评估测试人员的表现可以作为考核测试人员的一个重要依据。
工程部绩效考核
工程部考核细则 1、目的 （1）为建立有效的监督激励机制，考核员工素质、能力与其职务、岗位的匹配情况，合理使用人才，提高员工素质，激发员工潜能和工作热情，制定本细则。 （2）考核的目的在于全面了解员工工作业绩，对员工进行定性、定量的分析和评价，为员工的岗位调整、流动、培训和岗级调整、奖惩提供依据。 2、适用范围 本细则适用于公司工程部正式员工。试用期员工不参与考核。 3、岗位职责 （一）工程部主任岗位职责 （1）认真完成上级下达的各项任务，负责工程项目的整体运作和管理； （2）协调施工队、相关单位之间的关系，负责对外协施工队的管理工作； （3）负责工程施工过程中质量、进度、现场及投资的控制管理； （4）负责项目的工程人员管理。包括工程人员的调配、考核、奖惩等方面的管理； （5）负责各项目之间的资源调配，与工程管理相关各部门、单位进行沟通平衡； （7）负责工程验收、审计等工作； （8）完成领导交办的其他工作。 （二）管理专责岗位职责 （1）负责工程开工前的准备工作； （2）对工程管理过程中的文件、资料进行管理； （3）负责计划、统计的管理工作 （4）协助部门主任做好对外协调、调配工作 （5）负责工程项目的后勤保障工作 （6）负责工程竣工验收及移交工作； (7) 负责工程合同管理； （8）完成领导交办的其他工作 4、考核 （一）考核原则 （1）依据岗位职责和任职资格，以考核员工的实际业绩为主。
（2）坚持公平、合理的原则，对考核内容、考评方法和考评标准力求合理、科学，严格、客观地进行考核评估，增强考核工作的透明度。 （二）考核对象 工程部主任、资料员（管理专责）。 （三）考核内容 根据员工的岗位要求，主要考核员工的能力、态度和业绩三个方面。 （1）能力：指业务、技术、管理水平。主要包括：知识技能、学习发展、解决问题、工作效率、团队合作等。 （2）态度：指工作态度、事业心和勤勉精神。主要包括：纪律性、主动性、责任性、服从指挥、上进心等。 （3）业绩：指工作成绩和成果。 （四）考核周期及权重及内容如下表所示： 工程部主任绩效目标