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