KPI的初衷

激励辛苦付出的人，或鼓励创新，鼓励多做有贡献有价值的任务。

有了KPI考核，leader们就能名正言顺的对比手下人员的忠诚度、贡献情况，就好比说，这个任务要这个月完成，你们小组的完不成会影响这个季度的KPI 等场景。

有奖励，有惩罚或许的传统的管理方式，但对于IT界的研发人员来说，如何制定一套合理的KPI考核指标，却是难倒了一大批HR。

严格3-6-1制度，也就是末尾淘汰。比如对应S-A-B-C-D级别，S级当然是属于最优秀或者有特殊贡献的，才会评出个S级，但这种需要有充分的理由，一般leader没有特殊贡献的不会评个S级的来难为自己去汇报。D级别的基本是要砍掉的，如果不是工作态度问题，一般也不会有D级别的。

那强制末尾淘汰，在阿里那边已经取消了，因为一个团队没有拖后腿的人，不至于淘汰掉。如果团队里有这样的人，leader也会使用各种方法，让这个人离开团队的。

即使没有末位淘汰，作为leader也需要有个绩效排名，那么这些指标应该用什么合适？下面就举例一些经验或者案例跟大家分享下：

研发KP制定：

一、任务完成情况 + 行政考核

指标：

1、任务量，这个季度开发了哪些功能。

2、bug率，总共产生多少个bug，都有哪些等级的bug。

3、加分项，比如技术升级、技术分享。

优势：

1、领导可以看出每个人做了哪些任务，bug情况。

2、看起来都是研发类的统计，感觉专业。

劣势：

1、任务量无法实际统计，用工时？用难易度？用任务数量？ 工时的话，初级、中级、高级Java的工时如何对应？难易度也一样，什么样的算难，如何参照？

2、bug率，会让研发人员与测试人员，更多的在扯皮是不是bug，是不是需求问题，是不是可以降级bug等等，让研发效率大大降低，严重拉后腿。

二、OKR方式 + 行政考核

指标：

1、每个人的季度OKR 提前规划，并去执行

2、ORK季度末评定个完成情况

优势：

1、OKR整体的目标是可实现、有难度，最终只要接近OKR的目标即可算完成。

2、不会统计Bug情况，不会让bug的探讨浪费时间

劣势：

1、OKR是整个团队的目标，每个人要怎么细化？细化后，感觉每个人都一样。

2、OKR的目标清单，随着研发进展，需求变更等，发生变化后，OKR整体目标就会改动，（目标偏移在研发这个层面是经常的）。

研发团队还有必要KPI？

所以最终，如果一定要对研发团队做KPI考核，那么最终执行起来，就是研发的leader根据自己平时带团队的日常，得出个排名，然后很主观的提供一份数据给到HR，让HR有的交差。 而高层看到有一份数据，也就够了，也许大家心里都清楚...

如果是一个单纯的研发团队，如何制定KPI，有没有必要这样的KPI，已经没啥益处了，偏移了本身KPI的目标，因为这不是流水线上...研发本身就是创造，一个没有的东西，成为一个现成的产品。