技术程序员绩效考核办法(算法案例).doc

开发部程序员绩效考核办法
绩效目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价,用评价的结果指导软件的开发过程,不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。
2、 工作内容 市场调研 需求分析 成本预算 技术合同 概要设计 测试文档 详细设计 编写代码 技术文档 说明书
3、 完成质量
3.1 完成情况 根据需求功能列表 50分
3.1.1 完成功能例表中所表述的功能。 30
3。1。1。1 （完成功能数\列表中功能数)*30
3。1.2 代码可读性，注释 5
3。1。2.1 变量命名方式不统一,没有规律。 —2
3.1。2.2 代码没有缩进不整齐，有注释了的但并没有用代码 -1
3。1。2.3 代码无注释(函数 必须注释） —2
3。1。3 程序的强健性。 10
3。1。3。1 没有对非法输入进行处理。 -3
3。1。3.2 对用户的非正确顺序操作，产生的错误没做处理。 —2
3。1.3。3 对数据库中NULL值的未做处理。 —1
3。1。4 操作界面 5
3.1.4。1 界面不整齐：按钮、输入框、大小不统一。 —2
3。1。4。2 能缩放的窗体未做缩放处理。 —1
3.1.4.3 书写不准确，有错别字。 -1
3.2 是否及时 30
v=（实用工时-计划工时）\计划工时
v<=0
v>=0.1
v=0.2
v〉=0.5
30 20 10 0
3。3 程序成熟度 5
以软件项检查、评审、测试的结果为评价基准，评分标准如下：
〈1>5分：一次检查、评审、测试通过，无须调整；
〈2〉4分：一次检查、评审、测试通过,略有调整,或第二次检查、评审、测试通过无须调整;
〈3〉3分：二次检查、评审、测试通过。
〈4〉2分:三次检查、评审、测试通过。
〈5〉1分以下:三次检查、评审、测试未通过。
3.4 改善效率 5
<1〉5分：改善效率良好，软件项的修改无须增加工作量，不影响阶段的 继续进行和项目计划的总体完成，或无须修改;
<2〉4分：改善效率一般,软件项的修改或完善影响阶段的继续进行，增 加工作量在原计划的20％（此阀值可根据具体项目而定）以内；
<3〉3分以下：改善效率较差,软件项的修改或完善过程使项目延期，或 增加的工作量超过20%（此阀值可根据具体项目而定)。
3。5 技术文档
优：结构清析，详细、如实，并准确地反其设计思想和其实现的代码、数据等. 良：如实,并准确地反其设计思想和其实现的代码、数据等 差：不详细、不清析，不能反应其全部设计。 无 0， 优 5, 良 3， 差 2 3。6
说明文档
优:结构清析，功能描述详细.准确、全面。
良：功能描述全面.
差：功能描述不全面。不能让用户看说明书就能操作。 无 0, 优 5， 良 3， 差 2
4、 综合评价 绩效考核计分标准
5、 序号 得分 考核评价 1 90~100 优秀 2 80～89 良好 3 60~79 及格 4 低于60 很差
5、 奖惩标准 软件部门根据软件项综合评价表每个月或季度统计各开发人员所负责的软件项的平均得分值，比较开发人员软件项的平均得分值与绩效考核标准范围，确定开发人员绩效考核评价。绩效考核为“良好”以上人员奖励相应金额,绩效考核为“很差"人员处罚相应金额。绩效考核为“及格"的人员不奖不罚.对于很差的开发人员需要通报批评,并要求在项目经理、开发经理帮助下写个人软件开发过程改进书。如果是连续三个月都是很差则可能降级、降工资、甚至解雇；对于优秀的开发人员通报表扬，并组织经验交流会绍其优秀的软件开发过程控制方法，如果是连续三个月都是优秀，则可能升级、升工资。 奖：设p为所得分,m为绩效工资。
奖金为S S=(p-80)＊（m\（100—80））
例如：p=90 m=800 S=（90-80)＊（800\(100-80）)=400
惩：设p为所得分，m为绩效工资。罚金为S S=(60—p)＊(m\（100—80)）
例如：p=50 m=800 S=（60-50）＊（800\（100—80））=400