软件开发项目考核管理办法

《软件开发项目考核管理办法》由会员分享，可在线阅读，更多相关《软件开发项目考核管理办法（11页珍藏版）》请在金锄头文库上搜索。

1、北京九城大数据科技有限公司文件九城大数据（2013）人字 009 号CEO签发：日期：2013年 3 月 19 日软件开发项目考核管理办法1 目的及适用范 本考核管理办法，用于考核研发中心软件开发项目组的业绩，同时也用于对项目开 发负责人（研发经理）的考核。 本办法适用于研发管理中心以任务委派工作单形式承接的项目。本文所谓“软 件任务”，包括公司业务部门委派的任务，公司职能部门委派的任务，及研发中心 自己认可的任务。 软件研发负责人考核分为：业务类考核和价值观类考核，本管理办法重点说明对业 务类的考核，管理类考核参见九城集团 2012 年绩效考核总纲。考核办法中， 尽量以可量化的方式进行考核，

2、对于每个考核项，说明考核内容、考核标准，评价 人可以据此给出考核对象的考核得分。 研发负责人个人业绩考核得分人=项目考核得分+特殊奖惩得分。如果一个研发负责人（研发经理）在某段时间同时负责两个或两个以上项目，则其业绩考核结果， 是各项目考核结果按内部收入进行加权平均。特殊奖惩，包括对突出贡献的奖励得 分，以及对严重过失的扣罚得分（负值）。 研发管理中心的激励政策同九城集团2012 年绩效考核总纲规定一致，具体参 见九城集团 2012 年绩效考核总纲“激励政策”部分。2 考核周期对于周期短的项目，项目的考核周期，随项目的里程碑一起进行。也就是，按照签 署的任务委派工作单中规定的项目推进的整体的起

3、止时间和阶段性里程碑规定 的节点进行。 对于周期较长的项目，一般每季度考核一次，在下季度初进行。 有些产品或项目的任务委派数量多，但每个任务的完成周期都比较短，这种情况， 项目的考核周期为一个季度，考核得分为本季度内完成的委派任务按照工作量权重 累计得分。3 考核内容项目的业绩考核分为如下内容： 软件用户评价：由任务委派方负责评价，考核项包括工期、软件质量（缺陷、用户 反馈等方面）。 项目成本评价：考查开发组项目开发成本、项目成员有效工作量、委派工作量之间 的关系。由项目管理部汇总成本相关数据并计算。 项目过程评价：由项目管理部负责评价，考核项包括研发成果、项目管理成果、过程执行情况（CMMI

4、规范的执行情况）等 考核内容表格形式展示为：考核内容评价人考核项（打分依据）比重软件用户评价委派方代表工期10%服务质量（缺陷、用户反馈等）10%项目成本评价项目管理部根据开发组成本、有效工作量、委派工作量等对项目的成本情况评价50%项目过程评价项目管理部研发成果（技术文件规范、代码质量）10%项目管理成果10%过程执行情况10%4考核项定义对于项目的业绩考核，包含工期、服务质量、项目成本、项目过程评价等考核项，其定义和打分标准为：4.1工期考核按照任务委派工作单工期的要求，以累计工作日天数做为数量单位，评分标准:工期考核标准提前如果里程碑提前结束，则工期考核得100分。按时完成如果基本按时（

5、延期小于等于5%）完成可也以算为百分制满分。延期若延期超过5%,则每超过5个百分点扣除百分制5分，即100-5X （例 如：延期为8%，则工期考核得95分，如果延期为12%，则工期考核 得90分）丄评价人： 项目管理部提供工期数据，任务委派方进行评价4.2服务质量考核（用户评价）本考核项由委派方代表根据上线后的缺陷报告、用户反馈等因素给出分数，分数范围0100,并对分数给予说明。具体内容、格式参见附件研发项目委派方评价参考的打分标准为优90,100、良80,90）、中70,80）、差（0,70）。丄评价人：任务委派方4.3项目成本考核1、项目成本涉及名词定义: 公司认可工作量（或称：签约工作量

6、），是公司相关部门签署并验收的任务委派 工作单工作量。它是公司计算研发中心收入的主要依据。“公司认可工作量”以标 准人月数作为计算单位。 研发中心认可工作量：（或称：计划工作量），是研发中心对某项工作确认的工作量。 它是研发中心考核项目组业绩、贡献的主要依据。“研发中心认可工作量”以标准人 月数作为计算单位。 项目认可工作量：（或称：计件工作量），是项目负责人对某一软件模块（或称工作 单元）确认的“计件工作量（” 具体计算办法，参见研发人员工作量核算管理方法）。 项目管理部需定期（每月或项目结项时）统计项目和项目成员计件工作量。它是项 目考核项目成员业绩、贡献的主要依据。“项目认可工作量”以标

7、准人月数作为计算 单位。 项目实际完成工作量：（或称：项目已完成工作量），是指截止统计日期，确认完成 的计件工作量之和。原则上，某项目或任务的计件工作量之和=本项目或任务的 计划工作量。 内部收入：指某个团队或个人完成的认可工作量对应的收入（内部收入分为：研发 中心内部收入，项目组内部收入，个人内部收入）。计算方式为：“认可工作量”（包 括：“公司认可工作量”，“研发中心认可工作量”，“项目认可工作量”），与单位工作 量标准成本价（单位工作量标准成本价：由人力资源部与预算部根据研发中心从事 软件开发人员的平均薪水，所用设备折旧，公共分摊等费用计算并定期公布。）的 乘积（单位为人民币元）。 例如

8、，项目签署并验收的工作量为10 人月，单位工作 量标准成本报价为 15000 元，则本项目的内部收入为150000 元。注：计算研发中心内部收入，使用公司认可工作量；计算项目组内部收入使用 研发中心认可工作量；计算个人内部收入，使用项目组认可工作量。 项目开发成本：是指软件项目开发的实际成本，是参与软件项目开发的所有人员的 人力成本、分摊成本、日常费用的总和。项目开发成本反映公司对本项目的实际投 入，按参与项目的成员的“实际工时”或称“自然工时”计算。项目开发成本计算方式如下：项目管理部记录、统计参与项目开发的每个人的 实际工时（或称在岗日期，单位为工作日）。人力资源部根据每个人的实际工时计

9、算参与项目的人员实际人力成本总和（工资、福利等）。预算部根据实际工时，参 照公司公布的当期人均分摊成本计算出参与项目开发期间员工的分摊成本总和及 日常费用总和。项目管理部最终汇总成项目开发成本。 开发人员成本：是指某个开发人员在某个项目中的实际成本，是该员工在参与本项 目期间人力成本和分摊成本之和。开发人员成本二（员工人力成本+单位分摊成本）/21*实际工时。员工人力成 本人力成本由人力资源部计算并掌握。单位分摊成本参照公司公布的当期人均分摊 成本。项目管理部记录、统计参与项目开发的每个人的实际工时（单位为工作日）。 实际工时:（或称“自然工时”），是项目管理部记录的某成员参与某项目的实际工作

10、 时间。（单位为工作日）。 项目完工百分比：已完成工作量/计划工作量。2、项目成本考核公式：项目成本成考核得分（M）=项目小组研发内部收入/项目开发成本* 100；特别规定： “某项目或任务的计件工作量之和”大于“本项目或任务计划工作量”反映项目负责人对项目进展分配“超支”。“项目或任务的计件工作量之和”如果超过“本项 目或任务计划工作量”的120% （包括120%）,则项目成本考核最多得60分。 “项目内部收入”超过“项目开发成本”表明项目负责人对项目控制良好，可在 20%内适当加分。 如果一个研发负责人（研发经理）在某段时间同时负责两个或两个以上项目， 则其个人成本按项目投入进行分摊。丄评

11、价人：由项目管理部将从人力资源、委派方得到的数据进行统计4.4研发成果考核4.4.1技术文件规范技术文件包括：需求说明书、需求跟踪矩阵、设计说明书、代码、测试方案、测试用例、安装部署文件、用户手册等。从以下方面考核规范性： 格式规范性：成果是否符合模板要求、代码规范或其他规范方面的要求； 易懂性：是否易于他人理解，使得开发工作不依赖于个人，成果可为后续使用； 可跟踪性：能够从需求、设计到测试进行跟踪和追溯；丄打分标准：等级考核标准优90,1001. 所有成果都能够按照规范进行，而且内容较为准确和全面：2. 易懂性好，无需解释，他人即可理解，评审和预评审基本能够顺利 进行；3. 所有的变更都能正

12、确且详细地体现到对应的需求、设计和测试用例 中；4. 几乎所有的需求都能找到相应的设计和测试用例；或仅有个别非关 键或相对简单的需求没有被设计或被测试用例覆盖。良80,90)1. 大部分成果都能够按照规范进行，而且内容较为准确和全面；2. 易懂性较好，无需解释或仅需少量解释，他人即可理解，评审和预 评审基本能够顺利进行；3. 大部分变更都能正确且详细地体现到对应的需求、设计和测试用例 中；4. 大部分的需求都能找到相应的设计和测试用例；或仅有个别非关键 或相对简单的需求没有被设计或被测试用例覆盖。中70,80)1. 半以上的成果符合规范，存在有些成果规范的符合性方面存在较 大问题，如描述不全面

13、或不详细；2. 他人基本能看懂，但仍有很多内容需要作者解释，由于易懂性差， 导致评审或预评审延期或花费工作量增加较多；3. 需求、设计和测试用例基本能够对应，但有些关键或复杂需求没有 被设计或测试用例覆盖；4. 有些变更没有反映到需求中，或者反映的不够准确，易造成设计人 员或测试人员理解错误。差(0,70)1. 非常不符合规范，或缺少关键内容；2. 易懂性差，他人难以理解，评审或预评审无法进行；3. 很多需求、设计和测试用例都对应不上；4. 很多变更都没有反映到需求、设计和测试用例中，导致需求、设计 说明书跟实际情况相差甚远，测试人员无法正确编写测试用例。丄评价人： 项目管理部4.4.2代码质

14、量通过测试活动的结果来衡量代码的质量。 发布前：由系统测试期间和试运行期间发现的缺陷数量和严重程度分布，以及 缺陷修复的速度和质量（如缺陷是否能够很快修复，是否有很多缺陷被reopen 或修复后引入了新的缺陷）； 发布后半年内：由客户和维护人员发现的缺陷数以及严重程度分布。丄打分标准：代码质量由以下两个方面决定，最后由这两个方面进行综合评价， 最后计算总分TS二M1*80% + M2*20% :a）缺陷状况M1 （比重:80%）:M1二 每月缺陷状况的平均情况；由测试负责人根据缺陷的情况进行评价，总分100分，参考的因素如下： 缺陷的严重程度分布，特别是高严重程度的缺陷比例； 缺陷数和测试用例

15、的比例，即一定数量的测试用例所发现的缺陷数; 评价的缺陷等级，即（缺陷等级X缺陷数）/总缺陷数；b）缺陷修复的速度和质量M2 （比重：20%）:由测试负责人进行评分，总分100。考虑的因素包括缺陷修复的速度，缺陷被重新打开的频次以及修复缺陷后又重新引入的缺陷。说明:Bug级别的定义参加缺陷管理规程一般分级为15级，权重也 分别为15，对于1级轻微缺陷可以不扣分。丄评价人： 测试负责人4.5项目管理成果考核丄考核内容： 规范性和准确性：成果是否符合模板要求，填写内容是否正确； 及时性：成果能够按时提交； 易懂性：文字描述是否全面，便于高层经理或QA对成果的理解；项目管理成果包括:WBS拆分、估算过程数据、项目计划（初步计划、阶段 详细计划）、项目阶段状态报告、成员工作日志、需求变更跟踪、项目问题跟踪等 丄打分标准：规范性和准确性比重：50%及时性比重：30%易懂性比重：20%等级考核标准优90,100所有成果都符合模板规范，