目前中国国内几乎所有的软件公司或者技术性公司都存在一个十分困扰的问题，那就是：如何评定技术人员的工作量和贡献度！而在国际上通常情况下使用的工作日报、周报、月报、年度总结和计划的绩效考核模式下，让技术人员头疼欲裂却又不得不因为工资和奖金与此相关而被迫填写这些东西。
但是因为技术人员工作的特殊性，加上市场项目的不确定性，使得技术人员的年度计划往往等于空谈。而每天的日报填写虚空无物，因为技术人员的工作量实在是难以衡量，比如说，这一天写了多少代码，但是谁又能保证这些代码有多少行是不需要修改的，这些代码带来的价值到底有多大？同样周报和月报也遇到了类似的问题。除非是写文档和一些外围辅助内容的时候，文档的字数和文档的重要性可以进行一定程度的衡量，而毕竟技术人员主要的工作内容是写代码，代码的价值和有效性可是无法轻易衡量的。
本文所提到的绩效管理方法是笔者在 2004 年产生的想法，从 2004 年起到今天不断的进行补充和丰富，终于在今年得到了一定程度的系统化，同时开始在一些公司得到推行。
总体来说，这个绩效管理模型是为了实现有效的绩效管理，提高技术人员工作的积极性，同时为团队后续进行个人贡献度计算以及奖金的分配提供绩效计算基础数据，因此采用这种以数据为基础的管理办法来衡量技术人员的工作量和贡献度。
本文涉及到的内容将包括开发过程中的项目计划管理、风险管理、团队组成、配置管理和企业代码库构建等几个方面的内容。
团队的组成模式要根据各个公司的现状进行考虑而不能一概而论，下面这种模式适用于一些做产品的公司。
团队的组成模式要根据各个公司的现状进行考虑而不能一概而论，尤其是对于已经有自己相对稳定管理模式的公司就更需要根据具体情况进行考虑了。
所有人员一律平等，人员根据经验，毕业年限，为公司工作年限设定基本工资，然后根据项目组情况设定奖金和特殊奖励。
奖金部分根据所参加的项目组获得相应的奖金收入，同时还根据所开发的基础组件当月被重用的次数获得额外的奖金收入 [ 参见企业代码库构建 ] 。
在没有具体产品和用户需求的时候，进行公司方向性开发和研究，并根据方向进行团队组织和管理，同意隶属部门经理或者某一个级别的管理者管理。
在有具体用户需求、订单和产品的时候，进行人员重新组合，选择合适的人员设定为项目经理，由项目经理全权根据公司产品架构组的建议进行人员选择和搭配，然后进行项目开发。
产品策划组考虑为无形态组的方式进行组织，公司内任何人员都可以自行或者自由组队的方式进行游戏产品的策划和规划考虑，并将相应的策划和规划案提交给公司产品架构组进行分析定位和评审。
评审通过的，公司将考虑进行投资研发。
产品策划成形的相关参与人员都可以在公司投资研发的费用中获得 1% （一个设定的比例）的奖励，同时得到后期产品研发成功后的销售股份和提成。
内容开发组是负责游戏内容开发和实现的团队。
这个团队是根据具体项目需求进行组建的，不属于常设团队。
工具开发组主要是进行机构设计和游戏辅助工具开发的团队。
这个团队是根据具体项目需求进行组建的，不属于常设团队。但是，基本上每一个内容开发组都可能对应有一个同样的工具开发组进行配套支持，工具开发组也可能独立成立来进行机构研究。
工具开发组的可能人员的技能与内容开发组差异较大，主要是具有机械设计方面知识和技能的人主要执行，有部分软件设计和策划人员参与辅助工作。
基础组件组是为了构建企业代码库所提供的一种组织形式。
基础组件组也是采用无形态组的模式进行组织，公司内任何人员都可以提交自己开发的成品组件，要包括下列内容：
公司要求的设计说明书和设计模型。
组件详细功能说明书、接口详细说明书和详细设计文档（建议采用
模型的表述方式来进行设计，代码直接导出，有利于重用和升级）。
可运行组件。
组件全部源代码和对应版本说明（注释不得少于 30% ）。
采用本组件的示例性 Demo 。
本绩效管理办法需要通过下面几个内容的积累才能获得准确执行。
实施项目计划管理，制定项目计划和工程过程的基本规范，不需要太详细，将来根据情况和需要进行扩充。
制定项目计划模板、项目周任务安排模板、项目风险评估模板和项目计划评审模板。
切实实行项目周工作例会，有效安排工作任务和工作总结。
每项任务完成后都必须经过文档的评审和代码测试来进行审核。
版本管理规则、开发基线管理规则都需要制定。
任务安排：周例会上进行工作量安排，配合工作完成后的审核机制以及再分配方式进行。
工作内容带绩点值。
绩点的合作分配规则（主管 / 组长 / 项目经理和主承接人员商议分配）。
配置库中的 check in 次数配合每次的 comment 内容进行绩点调整（通过次数体现时间加成和工作量加成，详情参见配置库）。
任务分配不满造成每个月被分配任务所得到的绩点奖金低于前三 / 六个月平均值则按照前三 / 六个月平均奖金发放。每月按照 22 个工作日计算，如果每个月被分配任务所占用的工作时间少于 18 个工作日（这个数字可以按照企业现状来进行重新设定），则认定任务分配不满。
配合工作绩点根据情况通过加权累计方式计算额外奖金。
配置库可以采用各种知名的配置管理工具来实现。
要求所有的使用者在每天 check out 其开发工件的时候，必须写明本次的任务。在每次 check in 其开发的工件时，应该写明本次 check in 的完成情况。这个信息都可以写在 comment 中（各种配置管理工具都提供了这个功能）。
如果是撰写文档，则必须保持每次 check in 的内容和文档上的历史修订记录的内容时间相一致，时间由工具自动保持一致性，而修订内容则由技术人员自己填写，只需要填写一次，进行复制粘贴即可。
额外的问题：
公司如果考虑到代码安全性的问题，那么建议采用下面的代码管理规则：
在软件进行系统测试前，代码完全组内公开，系统测试后，对于需要控制的代码实行专项工作小组模式进行管理和后续的开发延续，代码就不再全部公开了。
组件代码库的建立和支持办法可以在开发过程启动前进行相应的培训和指导。
代码库主要是构建企业代码基础库，降低企业的重复劳动，提高代码的通用性和共用性。这在 2002 年我到四川院的时候提出过做法和具体的操作措施，技术人员很支持，不过，因为当时是做工程的缘故，同时加上当时企业并没有考虑到如此长远的技术发展规划，因此就没能做起来。
每个人可以在闲暇时间，或者任务间隙来完成，具体要求如下：
完成具体代码的全部开发和测试（建议和别人合作）。
完成一个调用的 Demo 例子程序，以便于其他人使用。
提交（提交内容按照基础组件组中的要求进行）到配置库中的审核区，等待审核。
这个代码库在一次完成后可以由本人升级，也可以由其他人升级完成，每次升级后进行评审，确定参与人员的贡献度比例，以便于今后相关绩点或者奖励的分配。
进行两个月的配置库和开发过程的数据积累，所有技术人员一方面在积累数据同时还要熟悉整个过程。
第三个月开始制定绩效体系的数学模型，然后通过三个月的数据或者根据情况加上第四个月的数据进行分别计算，确保模型的有效性和稳定性，确保平稳过渡。
算法完成后的执行期到稳定期大约需要 5 个月，基本上包括下面的内容：
在基础模型算法的基础上，需要增加调整优化算法，调整优化算法的作用是逐渐减弱的，也就是六个月后这个调整优化算法的任务就结束并退出模型了。其目的是让所有人员的工资收入在潜移默化的微量变化中走向规范，而不是一下子出现大的收入变化波动。
所以，整个绩效体系的执行时间为下面三个阶段：
前三个月数据积累，在第三和第四个月构建数学模型，同时完成调整优化算法，进行数学推演，反向计算每个人的收入变化情况和可能的今后六个月的变化情况。
最早在第五个月开始应用该模型，同时，调整优化算法起作用，直到第六个月底为止（这个时间可以根据具体情况进行分析，不是固定的六个月时间，而是会有变化的）。
从调整优化算法推出模型前两个月开始，对算法进行进一步的计算和修改，从第十二个月开始，整个公司的薪酬体系就将完全按照该绩效管理办法来计算奖金和贡献度。
整个过程的实施计划表
注：上面这个计划表是按照每周 5 个工作日，每天 8 小时工作时间的方式计算出来的，如果各个公司的工作周期不同，则需要作适当的调整。
对应的计划文件资源下载： http://download.csdn.net/source/535604
整个薪资的组成包括两个部分，一个是基本工资，这个部分是每个月固定的收入，保证员工的基本生活水平不受到影响，另一个部分是绩效奖金，这个部分根据员工的工作情况和贡献度来进行计算。
基本工资采用下面这些计算加成：
参加工作年限指标：这是考虑到工作经验的影响指标。
进入公司年限指标：为公司工作的历史贡献影响指标。
学历指标：大专、本科、硕士、博士各有不同，这是考虑到每个人求学历程的时间，以及他们进入公司时的基础贡献的影响指标。
等等，诸如此类的一些个人因素性指标来决定基本工资的组成和数额。
绩效奖金分为了三个部分，一是开发工作绩效，二是管理工作绩效，三是代码库贡献度。
根据任务安排和协助任务安排，并且完成这些任务后所获得的工作绩效。
这一项的范围最容易定义，但是，具体计算的时候却必须依靠历史数据的积累进行模型分析。
参与管理工作所付出的劳动对应获得的工作绩效。
这一项包括：
团队工作任务计划安排等、任务审核（包括各种评审、代码走查等）、配置库等的管理和维护，以及其他事务性工作所占用的工作时间对应的工作绩效。
可以初步定义，一次评审任务为每个参与者一个基础绩点，并以此工作量来计算相关任务的绩点。
一个人对公司代码库的付出，同时这个付出在当月内被引用的次数以及相应的加权。
代码库主要是对代码的分类管理，要求每一个维护的技术人员撰写维护文档和代码功能说明书，企业内给以相应的支持和奖励。
在积累的时候，通过配置管理软件来支持，或者自行开发一个简单的检索管理工具都是可行的。
比如对于代码库的构建和使用，这里举一个相对简单的例子：每一个人创建一个新的类，撰写完成它的所有说明文档和使用手册后，公司给予 20 元的奖励，每被别人调用一次，则奖励 5-10 元或者一个绩点。如果发现有人能使用公司代码库中的现成内容而没有使用，则进行每次每模块 20 元罚款或者其他处罚方式。维护代码库，给代码升级一次奖励 5-10 元。个人认为：虽然不高，但是积累多了，还是能够促进大家的使用和沟通交流的。
关于绩效管理的算法模型的基本形态从上面可以看到一些，不过，更具体的算法和实现必须根据各个企业的不同进行构建，简单来说，它包括基本算法模型和调整优化算法。
前者将是持续的，当然也要随着公司的发展每年或者固定时间进行一些调整，后者则是短时期的，主要在整个模型实际应用的前两到三个月内进行应用，过期后，其作用逐渐减弱并被消除掉。
在每个月进行工资和奖金发放前，只需要根据所有技术人员的绩点进行数字计算即可。
如果一个产品 / 项目获益，公司决定对项目组成员进行奖励，这时候，就可以用该产品 / 项目总绩点数来除每个人的绩点，这样就可以相对客观的得到每个人应该得到的奖励，而不会因为管理者与员工之间的亲疏关系造成他人的不满，也就避免了公司因此带来的不稳定因素。
通过上面的方式，就可以将一家公司的技术人员划入到一个整体范畴内，而不会因为个人好恶来影响到公司整体技术人员的心情和变动。
将人为的数字影像放在周工作任务安排上，而此后的一切内容都是用模型和数字说话的，因此就可以在最大的程度上避免因为个人好恶而产生相对的不公平事件发生，同时也可以在很大程度上避免一些弄虚作假的行为。
更有利于促进软件企业的合理分配。
BTW：本文首发于it168，按照约定一个月后可以发布于个人blog。本文中涉及到的计划表将放置在blog资源中提供下载。
扫码向博主提问
非学，无以致疑；非问，无以广识
擅长领域：
权限管理模型之一
访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Dis...
【量化分析】投资绩效归因分析-Brision模型
没有更多推荐了，扫二维码下载作业帮
3亿+用户的选择
下载作业帮安装包
扫二维码下载作业帮
3亿+用户的选择
老板要我制定绩效考核的方案,给了我一个薪酬的计算公式：岗位工资+绩效系数*绩效基数*考核等分百分比请问各位有这样的计算方法吗?
作业帮用户
扫二维码下载作业帮
3亿+用户的选择
正常的很特别是绩效改革的时候一般都是用这个公式.比如一个人拿的工资1000,其中岗位工资（也叫基本工资）500,绩效基数500,绩效系数1（不同的人或岗位系数是不一样的,比如文员为1,主管为1.5,经理为2等）,考核百分比就是每个月进行绩效考核,达到80%的话,就是500*1*80%=400,那么找个人这月的工资为岗位工资500+400=900；这么算能明白了吧.做百度任务,如果觉得满意,希望给个最佳,如果还有不明白的,可以继续追问.
为您推荐：
扫描下载二维码欢迎登录步步为赢&时代光华管理培训网
热门搜索：
您的位置： >
> 绩效考核方法创新技巧
绩效考核方法创新技巧
主讲专家：
中国著名管理学家
培训对象：高层管理&中层管理&基层主管&
员工最关心的一项工作。员工对它关心，绩效考核。甚至会逾越对工资奖金的关心，因为工资奖金的发放都要以它为依据。
最核心的问题是管理，企业管理发展所面对的问题中。而管理过程中最关键的环节却是绩效考核，并且最难让人满意的环节也是绩效考核。
企业管理水平也就直接上了一个大台阶。绩效考核达到公正、公平、客观、准确、全面&十字规范。
其关键在于是否能找到科学而与自己企业实际相适应的方法。绩效考核能否达到十字规范。
不能靠硬套照搬，科学而与自己企业实际相适应的方法。必需自己创新。
由授课专家提出问题后，1问题讨论。首先由参训人员讨论，然后由授课专家归纳总结，给出答案；
由授课专家提出一个案例后，2案例引导。参训人员一起讨论分析，加深对所讲内容的掌握；
参训人员可现场提出自己工作中所遇到问题，3现场答疑。进行讨论，最后由授课专家进行解答；
讲解一个技术方法后，4现场练习。通过现场练习，保证准确理解和运用；
课程安排有启发式游戏，5游戏启发。以通过游戏启发参训人员思考，加深理解；
每班不超过40人，6小班组织。因为是教练式培训，超越40人就难以保证互动练习效果。
绩效考核方法创新技巧课程大纲：
1.绩效考核方法创新的限制和思路
1、照搬照套他人的绩效考核方法为什么效果不佳？
2、十字标准：公正、公平、客观、准确、全面；
3、绩效考核目的、频率限制
4、企业行业特征、岗位工作性质限制
2.绩效考核创新方法之一&&目标化管理法
5、工作杂，职责多的管理人员的绩效，真的不能实现客观而准确的量化考核吗？
6、目标族系分析；
7、绩效得分的绝对数和相对数的计算模型；
8、实施的八步程序。
3.绩效考核创新方法之二&&用户评价法
9、谁说&搭便车&问题在企业内不可能消除？
10、人人是老板，人人是客户
11、两个成功实例；
12、五步实施要点。
4.绩效考核创新方法之三&&质证举证法
13、如何对远离总部的独立单位主管进行考核？
14、三大优点；
15、五个要点；
16、实施操作11步程序；
5.绩效考核创新方法之四&&问题清算法
17、绩效天天考，可能吗？
18、十个要点；
19、绩效得分计算模型；
20、实施操作十步程序。
6.绩效考核创新方法之五&&问题查寻统计法
21、没有交接的工作，如何考核其绩效？
22、七个要点；
23、两个计算公式；
24、十步操作程序。
主讲讲师：
专长领域：&|&&|&&|&
行业领域：&|&&|&&|&&|&
擅长解决的问题：
如何建立企业竞争优势如何有效整合社会资源如何树立正确的战略观念
该讲师其他课程：
相关内训课程
近期公开课
SPOT团队引导技术认
擅长领域：团队引导
中国著名实战管理专
擅长领域：领导技能,领导艺术,管理..
人力资源和生产管理
擅长领域：生产流程,人力资源,精益..
原网易培训经理
擅长领域：培训管理
人力资源管理专家
擅长领域：人力资源绩效的加权平均法_百度知道
绩效的加权平均法
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
来自经济金融类芝麻团
采纳数：14040
获赞数：66163
参与团队：
所谓“加权平均”是把数量概念引入计算公式，而不是简单把几个数据相加再除以个数。不知你指的“绩效的加权平均法”是指绩效工资还是单位绩效评价？如果是指绩效工资加权平均计算：部门绩效分值=绩效工资总额/∑（部门总系数*部门考核得分）部门绩效工资=部门绩效分值*部门总系数如果是指单位绩效考核：这个问题比较复杂，是在模糊数学的基础上进行综合评价，涉及矩阵计算（线性代数），把事先确认的因素量化（一般是专家评定），作为权重，然后综合打分，再将各指标的权重与分数进行计算，得出一组数据，即是绩效的几个等级。
来自：求助得到的回答
为你推荐：
其他类似问题
您可能关注的内容
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。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、考核办法一览表
提交缺陷总数(5)
单位（个）
基本考核指标
提交非缺陷数量（5）
单位（个）
要测试人员意识到处理非问题影响测试，开发的工作效率
提交有效缺陷数（20）
单位（个）
基本考核指标
提交缺陷分类数（20）
回归缺陷数（5）
单位（个）
基本考核指标
争议缺陷数（5）
单位（个）
是否存在对需求理解，系统构架设计，系统设计等方面引起争议的问题，体现出测试人员发现问题的深入层次，反过来也反映测试人员对业务的理解能力。
基本考核指标
非独立测试发现的缺陷数（5）
单位（个）
非独立测试人员（如：开发人员，用户等）发现的问题数 。基本考核指标
严重缺陷所占比例（5）
A/(A+B+C+D+E)=%
基本考核指标
设计执行用例数
单位（个）
基本考核指标
用例难度（5）
加分考核指标
工具掌握能力（+5）
加分考核指标
缺陷描述(5)
D (不合格)
问题描述是否清晰
问题定位的附件是否完整
问题描述语言是否规范
测试报告的质量(5)
D (不合格)
报告描述是否清晰
报告分析是否到位
报告描述语言是否规范
工作态度(6)
积极、情绪变化大
基本考核指标
沟通能力(2)
良好、一般
基本考核指标
自学、钻研能力(+3)
强、普通、差
加分考核指标
团队协作能力(2)
合作性强、 差
基本考核指标
注：缺陷分类算法：
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
如何考核测试人员？
csdn论坛上，有人问如何考核测试人员，我回了几个帖子，下面就是我回帖的内容，可以代表我对此事的一些看法。
一：测试人员的工作评价比较的难办，因为测试人员没有具体的工作...
测试人员的绩效考核应该如何开展？
http://www.cnblogs.com/zhangyublogs/p/5104427.html
测试人员的绩效考核应该如何开展？
问题描述：企业越来越重视对员工的绩效考核，对于一些传...
关于软件测试人员绩效考核的讨论
同某公司测试部经理关于测试人员绩效考核的讨论，由于保密的原因隐去了对方的姓名。讨论并没有结束，尤其是有效的度量指标是什么还在思考中。测试过程中我们有很多的度量数据，但是如果用来做考核，并对测试人员的工...
如何有效的对测试人员进行业绩考核？
如何有效的对测试人员进行业绩考核？
软件测试每周一问：随着企业对软件测试的不断重视，测试团队的规模也越来越大，测试相关的岗位也在逐渐增多，测试工程师、测试leader、高级性能测试工...
如何评价测试人员的绩效？（续）
日 17:14:00
Author：袁琳MSN：说实在的，对于测试人员的绩效考核，没有一个通用的标准。再就个人的工作体会补充一些，供大家参考...
没有更多推荐了，