最近公司决定对所有技术人员实行KPI考核,曾经一度非常反感KPI的我也被要求制定产品团队的KPI指标。为什么要实行KPI考核,因为在项目团队和产品团队的管理中出现了问题:

  • 不同项目团队的开发人员的工作量饱和度问题,阶段性会出现有的项目组加班加点忙死,有的项目团队成员工作量严重不够;
  • 分配的任务总是在截至时间的最后时刻完成;
  • 开发提交给测试的质量不高,需要反复的修改和再次测试,常常是因为态度问题,而不是能力问题。

不推行KPI,针对这些问题难道就是视而不见,没有去管吗?并不是,没有制度,就只能靠团队Leader去言传身教了,团队中的成员能理解吸收多少,最终有多少能转化成行动,取决于每个人的自我驱动力。

驱动力

驱动力1.0-生物性驱动

生物性驱动是本能,是最原始的驱动力,具体表现在:

  • 肚子饿了会去找食物吃
  • 困了会去睡觉

说白了就是日常生活中的吃喝拉撒睡。

驱动力2.0-外在驱动

外在驱动最典型的就是胡萝卜大棒理论,建立合理的奖惩机制,人们为了得到奖励而做某事,为了不收到惩罚而做某事。

驱动力3.0-内在驱动

内在驱动是从内心渴望去做某事,小时候,父母经常对我说,在学习上要将「要我学」变成「我要学」,这个「我要学」其实就是内在驱动力。

我一直都想打造一支每个人都是内在驱动型的团队,但可遇不可求,或者说需要团队领导者有很强的能力,能够将每个成员变成内在驱动型,在这方面,我还需要不断地学习和进步。

KPI和OKR

近几年OKR很火,那么和传统的KPI有什么区别呢?是不是任何团队都适合OKR呢?先来看看KPI和OKR的区别:

  • KPI是Key Performance Indicator(关键绩效指标);OKR是Objectives and Key Results(目标与关键成果)
  • KPI关键在于指标分解,是自顶向下的;OKR在于目标对齐,是自底向上的
  • KPI是被动执行;OKR是主动挑战
  • KPI是以指标为核心,所看到的都是冷冰冰的数字,其背后的思想很难准确传递给员工;OKR是站在价值观、使命感与自驱力的高度,更重视目标的一致性,自发与赋能的意味更重

从上面的对比来看,OKR的好处远远大于KPI,但有一个前提,团度成员是有自驱力的,就是上面所说到的驱动力3.0,或者说有一位很强的团队Leader,能让将团队成员培养出自驱力。如果满足不了这个条件,OKR将无法落地。

现阶段,虽然我团队的成员都表现的不错,有很高的积极性,但离OKR的要求还有一定的距离,加上很多人对OKR都不太熟悉,所以,只能先推行KPI。

KPI落地

KPI在团队的落地分为两个步骤:制定KPI指标和制定成员目标。

KPI指标

指标 权重 计算公式 评分标准
工作量 50% 个人工作量完成值/目标值 A:挑战值 ≥150% B:合格值 ≥100% C:保障值 ≥80%
BUG量 50% BUG数/已完成工作量 A:挑战值 ≤0.4 B:合格值 ≤0.6 C:保障值 ≤0.8
  • 目标值:需要跟团队中的每个成员进行沟通
  • A、B、C三个等级的达成值也是会根据情况进行优化和调整的,上面表中的仅供参考

将工作量和BUG指标的三个等级进行交叉结合就可以形成绩效的系数,如下表

工作量 BUG量 A B C
A 1.5 1.3 0.9
B 1.3 1 0.7
C 0.9 0.7 0.4

制定成员目标

成员目标的制定需要和团队中的每个成员进行单独沟通,每个人对给自己设定的目标值能够认可。

目标值设置的太容易达到,会降低前进的动力,设置的太难,又会带来挫败感,所以建议以跳一跳就能够到为标准来设置。

目标值也不是制定一次以后就永远不变,我们以一个季度为一个周期,在下一个季度到来之前,会进行每个成员下一个季度的目标值的沟通。

可能存在的问题

在KPI的考核制度中,很容易将考核指标当成了目标。例如:我们的目标是能持续的交付高质量的软件,设置的考核指标为:工作量和BUG量,开发人员如果只是看到了指标,会出现下面问题:

  • 为了追求工作量多,之前成员之间的相互帮助会变少
  • 为了追求BUG少,不会进行重构,写出的代码会是「只能运行的代码」,目标中提到的高质量不仅仅是没有BUG,另一方面是可维护,可扩展

所以,一定要强调,考核指标是手段而不是目的,不能只盯着指标去做事,我们也可以采取一些措施来进行制衡:

  • 鼓励沟通,如果发现一个任务中实现需要对现有代码进行重构,可以提出,增加相应的工作量
  • 重构代码引发的BUG可以看情况降低权重
  • 除了工作量、BUG量,可以在另外的维度,比如积极性、协作性、创兴性等方面来打分,最后综合来评定

总结

不管是KPI还是OKR,没有银弹,只是看适不适合当前的团队,而且也没有什么制度是定下来就不变的,随着团队的成长和进步会不断的优化和调整。也许到最后,又会回归到一种「松散」的管理模式。