KPI在小型产品团队中的实践

Mon, 29 Jul 2019 07:05:59 +0800

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

我们真的需要KPI吗?

Fri, 03 Aug 2018 22:51:21 +0800

前言

工作十几年，经历过不少的公司，每个公司都有自己的管理方法，其中大公司比较偏爱使用KPI考核，小公司则直接靠人来管理。下面谈谈之前公司KPI考核制度和现在「松散」管理的对比。

严格的KPI制度

之前的公司在武汉研发中心有大概五六百的技术人员，每个团队的项目经理只考虑需求沟通、任务分配和资源协调。完全不用管团队成员是否有认真干活，员工的管理依赖KPI制度。当时开发岗的考核制度大致如下：

工作量

任务系统的任务都会评估出一个工作量，以天为单位。计算方法为在季度末算出整个季度中完成的工作量和总出勤天数的一个比例。表明上看这个指标非常好，公司不用怕员工偷懒，相反员工还会主动去找事情做，因为担心工作量不够。当由于各种任务之间的衔接、各种内耗，往往会造成「忙」的假象。

bug量

bug量的计算方法是一个季度所做的任务的有效bug量和所做任务的工作量的一个比例，最终算出每天的平均bug量是多少，再根据这个bug量来打分。设置bug量这个指标的初衷是为了提高开发人员的开发质量，减少测试与开发之间往返的消耗。但这个指标至少会带来两个弊端：

1、开发人员和测试人员的对立

因为测试岗也有bug量的质量，他们是平均每日找到多少个bug，所以很多时候开发人员都在和测试人员纠结bug有效性的问题，其实开发和测试的目标应该是一致的，都是为了软件能够高质量的交付。

2、事不关己，高高挂起

经常会在项目中发现一些不合理的代码，如果这些代码不是自己负责的，开发人员不会去进行重构，因为可能会带来更多的缺陷，而这些缺陷最终会记在修改者的头上，即便重构不会带来任何的风险，也没有人会关心这个，人们更多关心的是软件能不能正常的运行。正是由于这个指标的存在，随着时间的增长，项目中的坏味道会越来越多。

关键节点达成率

任务系统中的每个任务都会设置关键节点，对于开发来说关键节点就是某个任务提交测试的时间点。计算方法是未超时的任务数和总任务数的比例。这项指标的初衷是保证开发的效率，但也带来了一些问题：

1、互帮互助少了

虽然公司一直都强调同事之间要多沟通，多互相帮助，但正是有了这个指标当你的任务已经快到关键时间点的时候，你就没有多余的时间去顾及其他的事情了。

2、多任务的处理

当你正在处理设置了关键节点的任务的时候，突然来了紧急bug任务，正常逻辑应该是优先响应紧急bug，但也有了这个指标，开发人员就会先保证当前任务不超时，而不会去响应bug需求哦。

「松散」的管理模式

近些年在一个中小公司负责产品团队，团队规模很小，自然也就没有严格的KPI考核制度，开发人员都是有个性的，都不会喜欢被KPI所束缚。但没有KPI制度的管理也会碰到各种问题。

太理想化

我一直想象的理想团队是每个成员都应该是自我驱动型的，当需要通过制度或是人来管的时候，自然是做不好事情的。现实情况是，人都是有惰性的，团队并不会了一个伟大的共同目标去努力奋斗，每天朝九晚九仅仅只是当成了一个工作。起初最典型的一个表现是，分配的任务总是在截至时间的最后时刻完成。

公平

没有KPI这种量化的考核，对团队成员的考评就会偏主观，就可能带有感情色彩，就可能有失公平。做事快的人可能会被分配更多的任务；bug多的人可能会感觉一直都处于「忙碌」的状态；效率高的人可能会被认为不够努力。

总结

任何管理方式都会各有利弊，包括最近两年比较火的OKR，相信在实践过程中一样会遇到各种问题。既然都会遇到困难和问题，我个人还是偏向松散的管理模式。

松散的管理模式，并不是说不管理，而是要努力做到让每位团队成员从“要我做”到“我要做”的转变。我认为可以尝试以下一些方式：

1、领导要对团队成员要有足够的信任，用人不疑，疑人不用； 2、技术人员普遍比较闷，不愿说出内心真实想法，需要经常和他们去沟通，了解他们内心真实想法，能力范围之内解除他们后顾之忧； 3、团队内部需要经常组织一些活动，提升团队凝聚力。比如一个开发阶段完成后，组织吃饭唱歌等； 4、定期给团队内部培训，要让每个成员都了解产品的思想，了解客户真实需求，了解公司的愿景。目的是让大家能够一起为了一个共同的目标努力，而不只是自己负责的一个功能模块。但同时也要阶段性让团队成员看到收益，而不只是画饼子； 5、建立奖惩制度，赏罚分明，公平、公正、公开； 6、如果公司领导允许，或许可以尝试下阿米巴的方式。

KPI on 冯威的博客