【管理文书】研发人员绩效管理办法实施细.docVIP

********则研发人员 绩效管理办法实施细则（试行） 文件状态 [√] 草稿 [ ] 正式发布 [ ] 修订 [ ] 废止 当前版本 0.1 编制 ************************ 审核 发布日期 修订人/日期 版本号 修订内容概要（或原因） ******* 0.1 编写初稿 目 录 第一章 总则 3 1.1. 目的 3 1.2. 绩效考核内容 3 第二章 考核细则 3 2.1. 标准工时工作量 3 2.1.1. 任务类工作 3 2.1.2. 运维支持类工作 9 2.1.3. 事务类工作 13 2.2. 单项指标评价 14 2.2.1. 指标范围 14 2.2.2. 指标原则 15 2.2.3. 指标设置 15 2.3. 综合评价 20 第三章 绩效结果应用 21 3.1. 年度考核 21 3.2. 薪资调整 21 第四章 附录 22 总则 目的 为落实《研发人员绩效管理办法》，规范研发部门绩效考核，特制定本细则。 绩效考核内容 绩效考核内容包括标准工时工作量、单项指标评价和综合评价三部分。如图： 考核细则 标准工时工作量 标准工时工作量反映了研发人员工作量，占总绩效值的大部分比例，包括任务类工作、运维支持类工作和事务类工作。如图： 任务类工作 任务类工作是指通过CQ下达的任务，包括开发类任务和非开发类任务。 开发类任务工作量核算 考核范围 开发类任务的考核范围是CQ二级开发任务，本考核周期内代码审查任务及技术测试任务均已完成的开发任务纳入本期核算。 已在往期核算过的开发任务不再重复核算。 考核流程图及说明 说明： 响应任务，编写任务修改方案 承接人应根据任务描述，分析任务，编写任务修改方案，细化修改内容并估算所用标准工时。 填写《开发类任务修改方案》、《开发类任务工作量估算表》（以下简称“估算表”）。 修改方案要描述清楚为达到任务目标，所要做的业务逻辑调整，或新增的业务处理，如有必要可通过流程图说明；具体的修改方案，如果有多个可选方案，要说明选定最终方案的原因；修改方案所涉及的具体程序及程序类型。 任务承接人根据经验填写《估算表》，最小单位为0.5人天，任务的工作量指完成任务所需的标准工时，而并非任务书中填写的“允许工期”（即交单时间与下单时间之间的间隔天数）。任务工作量估算需参考已完成的同等规模、难度任务的实际工作量，原则上不得高于已完成的类似任务实际工作量，如遇特殊情况，需要增加工作时间，即高于同类任务的工作量，承接人需说明详细原因，填写在《估算表》的补充说明栏中。 开发类任务的工作量估算可从修改方案设计与评审、开发（具体修改内容）、单元测试、配合技术测试、代码审查、部署说明文档编写、同步相关技术文档等方面进行。修改方案设计工作占该任务工作量的30%，合格的设计工作应该有Rational Software Architect输出物。 确定工作量评估小组成员 评估小组成员由本专业的骨干组成，并且必须在3人以上。任务参与人遵循回避原则。 修改方案及工作量评估 评估小组对任务工作量估算需参考之前完成的同等规模、难度任务的实际实施工作量，评估量原则上不得高于已完成的类似任务实际工作量。 如因特殊情况，本次任务的工作量高于同等规模、难度任务的实际实施工作量，并且任务承接人已在《估算表》中说明原因，则评估小组根据实际情况评估，结果需要报处室负责人确认，并在技术组内部备案，作为任务过程资产保留，为今后任务工作量估算提供参考。 修改方案与评估结果应全员公开。 分配需求、开发、测试、代码审查任务 任务承接人在接收到一级研发类任务（包括上线项目修改和新项目开发）时，必须新建四类二级任务：需求任务、开发任务、代码审查任务以及测试任务。其中开发任务要与技术测试任务和代码审查任务关联。 上述四类任务，一般情况下，均只允许有一个。每个开发任务，为了保证工时评估的准确性，要求最大工时不超过200人时。特殊情况下，如果有分配多个开发任务，相应的代码审查任务、测试任务也要有多个，要求开发任务，代码审查任务、测试任务一一对应。对于新项目，由于一般工时比较大，要求按客户端、服务器端以及后台传输三个方面进行二级开发任务分配。 二级任务负责人应根据估算工时审批三级任务。二级任务估算工时与实际工时允许上下10%的浮动。 开发完成提交技术测试 任务开发及单元测试均完成后，即可提交技术测试，并通知代码审查人员进行代码审查。 技术测试通过后要填写《任务修改程序说明》。 处理实际工时与估算工时误差 技术组长审批二级任务时，会比较实际工时与估算工时，若误差超过10%，则需要进行相应调整，并通知二级任务负责人。若二级任务负责人有异议，则需要提交相关补充文档说明误差超过10%的原因