咱们真的须要KPI吗?

前言

工做十几年，经历过很多的公司，每一个公司都有本身的管理方法，其中大公司比较偏心使用KPI考核，小公司则直接靠人来管理。下面谈谈以前公司KPI考核制度和如今「松散」管理的对比。

严格的KPI制度

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

工做量

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

bug量

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

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

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

二、事不关己，高高挂起

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

关键节点达成率

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

一、互帮互助少了

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

二、多任务的处理

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

「松散」的管理模式

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

太理想化

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

公平

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

总结

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

松散的管理模式，并非说无论理，而是要努力作到让每位团队成员从“要我作”到“我要作”的转变。我认为能够尝试如下一些方式：

一、领导要对团队成员要有足够的信任，用人不疑，疑人不用；二、技术人员广泛比较闷，不肯说出心里真实想法，须要常常和他们去沟通，了解他们心里真实想法，能力范围以内解除他们后顾之忧；三、团队内部须要常常组织一些活动，提高团队凝聚力。好比一个开发阶段完成后，组织吃饭唱歌等；四、按期给团队内部培训，要让每一个成员都了解产品的思想，了解客户真实需求，了解公司的愿景。目的是让你们可以一块儿为了一个共同的目标努力，而不仅是本身负责的一个功能模块。但同时也要阶段性让团队成员看到收益，而不仅是画饼子；五、创建奖惩制度，赏罚分明，公平、公正、公开；六、若是公司领导容许，或许能够尝试下阿米巴的方式。