最近公司决定对所有技术人员实行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，没有银弹，只是看适不适合当前的团队，而且也没有什么制度是定下来就不变的，随着团队的成长和进步会不断的优化和调整。也许到最后，又会回归到一种「松散」的管理模式。