[原创] 研发人员绩效管理之KPI设定

上一篇 / 下一篇 2008-04-10 16:42:31 / 个人分类：经验分享

H君问：

准备实施绩效管理，在设定研发岗位KPI时一时感觉还是比较的迷惘，那些需要定量考核，那些需要定性考核？定量考核的以什么指标量化？定性考核的如何说得清楚明白？

H君说，研发岗位，首先是程序员，参考了一些文档暂且定义如下：

岗位职责：
1完成项目经理安排的开发任务；
2按照详细设计文档编码；
3对所负责的开发模块进行单元测试并通过；
4修改测试部门反馈的缺陷；
5对使用公司或部门产品/框架提出反馈意见；
6定期完成工作周报，向项目经理汇报。

序号指标名称定义计算公式及考核方法
1 完成代码数量完成的代码行数工具统计所得的代码行数×难度系数（难1.2，中1，易0.8）
2 工作态度是否迟到早退、工作是否认真积极定性指标
3 整体bug数量所负责的模块所产生的bug数量 Bug数量×严重程度系数
4 修复缺陷引起其他缺陷的数量修复bug后再次产生的bug数量 Bug数量×严重程度系数
5 计划时间与实际完成时间的偏差项目经理计划的完成时间与实际完成时间之间的偏差（实际完成天数－计划完成天数）/计划完成天数
6 提出建议和意见对项目组或部门的实际情况在管理、技术上提出有益的建议和意见的条数

谷雨霖的意见：
太细了。失去kpi含义啦！
kpi是关键业绩指标，是考核你关心的、对项目重要的指标，不是所有都要设。原则上不要超过5条。
如果条款太多，你的权重过于分散，考核的意义就不大了。
对于程序员考核，无非是TQ态度。
对于项目而言，因为有项目计划和项目质量要求，KPI对TQ的设定就可以不作要求。
对于部门制管理，每个季度考核，需要设定TQ。

通常，
T设置：按进度计划完成任务，延迟1天**，缩短1天**（或者设置比例）；
Q设置：功能点缺陷率低于**，千行代码缺陷率低于**；
态度：缺陷关闭速度、规范执行（如需求变更）、加班、建议、知识库等贡献，违反的扣**/贡献的加**。

如果项目生存以交付进度为主，T权重可以大一些，比如50%；质量30%；态度20%
如果质量为重，则提升质量的权重。
KPI是指挥棒，组织想好去哪里，权重向那倾斜。

全部脚印 不留脚印留下脚印:

导入论坛引用链接收藏分享给好友推荐到圈子管理举报

TAG: 绩效

引用删除 Guest / 2008-04-16 13:24:18: 评 5 分

引用删除 husthxd / 2008-04-14 14:16:26: 前段时间看过一本书，提到cmm，认为cmm首先把人的因素排除在外，在此基础上再去定义规范。

引用删除 pharos / 2008-04-14 00:29:13: agile在国外和国内外企涉及比较多，面对中国国情，Agile方法面临的一些问题：
1、 “刚刚好”的尺度在实践中不易把握；
2、 Agile方法与CMM/SPICE/ISO9000等的结合点在哪里？不能搞非此即彼的对立。
3、Agile方法特别强调人的重要性，那么如何考虑文化的差异，特别是中国的文化？等等。

关键是有没有足够素质的人员，或者说如何培养这样的人员。同时，我相信对于那些对需求比较挑剔的客户会更喜欢agile。

引用删除 pharos / 2008-04-14 00:25:10: cmm/cmmi与agile的区别主要有：
1、CMM更注重质量，Agile更注重生产率
2、CMM强调过程的可观测性，Agile强调可观测的结果（可运行软件）
3、CMM注重管理和过程，Agile注重技术和效率
4、CMM注重组织，Agile注重个人
5、CMM无所不包（Universal)，Agile有明确的适用范围
6、它们都包含了一些软件工程的好的实践（Practices)

引用删除 pharos / 2008-04-14 00:22:31: 如果要说说项目开发模式，我相信也没有最好的，瀑布也好、v模型也好、agile也好，都有其适用性。
就agile与cmm/cmmi来说，前者是轻量级的，后者是重量级的，没有好坏只有适合与否。
我们知道Agile方法的一个共同特点：
努力营造诚信、开放的组织氛围，根据项目中信息流通的具体情况，按高内聚、松耦合的原则，将项目组划分为若干个小组（每个小组以不超过10人为宜，组员均在一个工作间内工作），通过小组内各种渠道的沟通，来减少中间制品的工作负担，提高应变能力。
但，适合采用Agile方法的情况主要涉及：
1、需求不确定、易挥发（Volatile,意指今天的要求明天就不需要了）
2、有责任感和积极向上的开发人员
3、用户容易沟通并能参与

开发人员能力不足、客户参与度不够的项目，agile是拔苗助长。

引用删除 pharos / 2008-04-14 00:16:57: 这几天比较忙，没有时间来更新blog。看到大家的评论很高兴！因为真理不辨不明。但在软件项目开发管理方面并没有一成不变的真理，如果说有就是--适合自己的就是最好的。
其实，软件项目的员工管理kpi更多适合部门制行政管理的模式。因为很多项目要跨季度的，纯粹考核失去了意义。如果说设置的优势，就是它可以用来帮助部门（如软件一部）来推动部门任务，比如效率、进度、知识建设等方面。

引用删除张恂 / 2008-04-12 19:52:44: 原帖由husthxd于2008-04-10 23:27:01发表

可能我们对某些名词的概念还没有达成一致，我指的“详细设计文档”并不是瀑布模型中的文档，是一个泛指，

ok

我不知道你所说的概要设计个什么概念？

我说的概要设计差不多就是你说的这个概念：

这个文档从需求分析文档而来，详细程度是：把事情说清楚，开发人员可以据此开发即可。

现在一般指架构设计文档（SAD）

引用删除张恂 / 2008-04-12 19:47:34: husthxd：自选任务实施的效果如何？好处是什么？负面影响有什么？

我写在这儿：

8 年前我们如是做：开发任务分配的双向选择
http://space.itpub.net/13633641/viewspace-235561

总之是利大于弊，负面影响不多，以后再补充。

我会把它写成一个管理模式。

引用删除 husthxd / 2008-04-11 14:14:44: 开发人员擅长什么，作为管理者是应该很清楚的，所谓“知人善用”也。
进一步来说，跟开发人员沟通交流，了解他们自己想做什么，想往什么方向发展，探讨职业生涯规划倒是很有必要，不过，这些工作更多是由职能经理而非项目经理去做的。

引用删除 ziying / 2008-04-11 13:28:27: 张恂是讲让开发任务在一定程度上可由开发人员自主选择
不是完全自选的。
自选任务在一些项目建设中我们也实施过。好处就是任务都是开发人员选择的，一般都是会选择他们比较擅长的那一块。效率和质量都会比较理想。基本没有负面影响

引用删除 husthxd / 2008-04-10 23:30:05: 通常来说，项目组里面会有技术经理，沟通和协调技术上面的事情，通常也会“越界”去解决技术难题。
但我个人认为任务分派还是由具备管理经验的PM和TeamLeader去分派为妥，你所提到的自选/指定不过是方式而已，一句话：目标/结果为导向。
btw:
自选任务实施的效果如何？好处是什么？负面影响有什么？

引用删除 husthxd / 2008-04-10 23:27:01: 可能我们对某些名词的概念还没有达成一致，我指的“详细设计文档”并不是瀑布模型中的文档，是一个泛指，这个文档从需求分析文档而来，详细程度是：把事情说清楚，开发人员可以据此开发即可。
我不知道你所说的概要设计个什么概念？

引用删除张恂 / 2008-04-10 23:19:57: husthxd >> 1. 小型项目PM往往可能既是系统分析员亦是高级程序员，由PM分解任务给各开发人员最为正常不过。

补充：

PM 和 Architect/Technical Lead 是两个角色，当然也可以由 1 人担任。

由 PM 来明确需求任务，Architect 来分配开发/实现任务，而且让开发任务在一定程度上可由开发人员自主选择，有指定动作，也有自选动作，可能更为合理。

我们 8 年前就是这么做的。

引用删除 ziying / 2008-04-10 23:03:12: 1 完成代码数量
那我多敲几个回车呢.是不是分数就高了
高级程序员可能用3行的代码完成程序员5行的代码功能?这个不太好计算吧.

引用删除张恂 / 2008-04-10 23:00:50: husthxd >> 2.不管敏捷与否，我个人认为按照详细设计文档编码是程序员/coding的本职工作

在敏捷开发中，详细设计文档通常是多余的累赘，做到概要设计就可以了。有了初步的架构设计，就可以编码了。

用架构设计文档取代传统的详细设计文档更为合理。

引用删除张恂 / 2008-04-10 22:54:53: husthxd >> 3.解释一下：项目组是一定会配备测试人员的，直接上级是PM，职能上级是测试部的Manager。

不错，这是比较流行的做法。

引用删除 husthxd / 2008-04-10 22:49:18: 呵呵，聊到软件开发上面来了，越来越有味道了。

引用删除 husthxd / 2008-04-10 22:40:43: 1.小型项目PM往往可能既是系统分析员亦是高级程序员，由PM分解任务给各开发人员最为正常不过。对于稍大型的项目（>12），通常以team为单位分解任务。
2.不管敏捷与否，我个人认为按照详细设计文档编码是程序员/coding的本职工作；另外，开发是一个迭代的过程，简单的说，可以把每一个迭代看作为一个瀑布过程，分析->设计->编码，所谓敏捷软件开发，看各人理解和应用如何了，最终还得看实际效果。
3.解释一下：项目组是一定会配备测试人员的，直接上级是PM，职能上级是测试部的Manager。

引用删除张恂 / 2008-04-10 22:01:54: 赞成老谷的意见。

由于 H 君参考的是某些“传统”文档的程序员岗位职责，我发现其中有几处可能存在较大的风险，属于应该避免或淘汰的做法。

* 完成项目经理安排的开发任务

由项目经理给每位程序员分配具体的开发任务，尤其是涉及到技术细节的任务，可能是一种管理的错位。

* 按照详细设计文档编码

对于许多项目开发类型，通常这种做法暗示了一种过时应该淘汰的瀑布开发思维。

不过，我听说在不少离岸外包环境中，这种做法还是比较流行的，可能有其合理性。

* 修改测试部门反馈的缺陷

缺陷来自于一个独立的测试部分的反馈，而项目组不配备测试人员，似乎也暗示着一种高风险的瀑布行为。