KPI与OKR是两种目标管理理论。
KPI流行已久，但也有硬伤。码农是写代码越多越好么？写文档的码农的贡献是不是比写代码的少？我曾呆过的研发机构曾一直在纠结于类似的KPI设定问题，强硬的制定各类看似科学的量化指标，然而一到年底，指标的执行情况也就只能看看而已，并不能真正令人信服，而且起了些反作用。反作用的表现有，代码变得故意复杂起来，文档服务器上多了一堆看似齐全却没营养的僵尸文档。
OKR是另一种考核导向方法，看起来能部分解决以上的问题。
OKR，即目标与关键成果法，代表Objectives和Key Results。最初由Intel发明，1999年，被引入谷歌，并一直沿用至今。OKR系统看起来很简单，它帮助公司整理和执行计划，并从上到下按照命令链排布。
这个图看起来很像KPI的套路，首先是设定Objectives，然后设定实现Objectives过程中或结果的Key Results，这些Key Results必须是要量化的。
OKR与KPI的区别在于，OKR的主要目标不是考核某个团队或者员工，而是时刻提醒每一个人当前的任务是什么，相信并依靠员工的自主性和创造性去完成任务，使自由和方向达成一种平衡。OKR的内容和成绩都是公开的，经理把OKR分享给下属，同事之间也可以横向分享。在了解了不同人的OKR后，同事间更容易互相了解对方的诉求，配合更加和谐。
听着好像很没谱，但是一旦Key Results不用于考核，那么团队会更注重Objective。如果采用这种方法来交付一个软件产品的话，团队应该更注重与给客户创造价值本身，而不会为了KPI而创造虚假代码量、文档量。这看起来好像是件不错的事情。
OKR适合的自主的、创造性、团结的团队，他们对自己的期望应该很高，具有很大的积极性实现目标。而KPI更适合于可量化的工作团队，比如呼叫中心、生产流水线等等。在KPI的效果不好的情况下，倒是可以在某些IT团队里面试试这种方法，倒是可以先把我的企业IM Profile里写上我的Objective。
