绩效考核OKR分析和总结.docx

绩效考核OKR

OKR

编辑OKR

编辑

OKR全称是ObjectivesandKeyResults即目标与关键成果法，OKR是一套定义和跟踪目标及其完成情况的管理工具和方法:1999年Intel公司发明了这种方法,后来被JohnDoerr推广到Oracle,Google,LinkedIn等高科技公司并逐步流传开来，现在广泛应用于IT、

风险投资、游戏、创意等以项目为主要经营单位的大小企业。

中文名

OKR

OKR

外文名

外文名

OKR

OKR

KPI

KPI理论上是必须严格按照SMART标准制订的，是否达到甚至达到比例多少（小于100%还是大于100%）都是要能测量的。但这就导致一个问题，有些事情值得去做，但在做出来一部分之前无法测量因此无法制订目标，这时候就陷入了先有鸡还是先有蛋的问题了。比较保守的做法就是这项KPI先不写，或者写一个很低的目标值，反正季度末再改KPI的事情又不算罕见。有些团队常常到季度末才完成KPI制订的工作，那时候什么能完成什么不能完成都基本上确定了，当然能够让KPI都处于基本达成状态。

KPI还有一个更严重的问题，那就是为了完成可测量的目标，有可能实际执行手段与该目标要达到的不可测量愿景正好相反。举个例子来说，我们希望用户更喜欢使用我们的产品，因为喜欢无法测量，所以把PV写进了KPI里面。（确实大家都还不懂NPS或DAU这样的先进理念，只会用PV来测量一切。）但在实际执行过程中，我们可以把用户原本在一个页面上就能完成的事情分到几个页面上来完成，结果PV达到了KPI指定的目标，但用户其实更讨厌我们的产品了。

大家如此应付KPI是因为KPI跟绩效考核挂钩。如果KPI达不到那就会影响奖金，所以就算违背公司利益违背用户利益，也要把自己的KPI完成了，把部门的KPI完成了。

OKR解决了KPI的种种缺陷。首先它和绩效考核分离，把绩效考核交给peerreview

（相当于中国公司的360度评价）来做。然后它强调KeyResult必须服从Objective，

所以如果你在Objective上写了要让用户喜欢我们的产品，但你实际执行KeyResult的手段违反了这一点的话，谁都能看得出来，自然你做了也只有坏处没有好处。既然KeyResult只是用来服务于Objective的，那就没必要像KPI那样一早制订好然后强制执行了。你可以在做的过程中随意更改KeyResult，只要它们还是服务于原本的Objective就行。其实OKR最重要的作用就是帮助你「stayfocus」，「stayfocus」又能帮助你「makeimpact」

（当然有人没focus都能有impact，或者有focus都做不出impact）。

OKR的指导原则：

OKRs要是可量化的（时间数量），比如不能说“使gmail达到成功”而是“在9月上线gmail并在11月有100万用户”

目标要是有野心的，有一些挑战的，有些让你不舒服的。一般来说，1为总分的评分，达到0.6-0.7是较好的了，这样你才会不断为你的目标而奋斗，而不会出现期限不到就完成目标的情况。

每个人的OKRs在全公司都是公开透明的。比如每个人的介绍页里面就放着他们的OKRs的记录，包括内容和评分

为什么用OKRs，好处是？：

促使我们思考，主要目标会随之浮现；

沟通会更顺畅，让每个人都知道什么是最重要的；

能找到一个衡量过程的指标；

能让我们集中地为某件事而努力。实施的关键流程：

从上至下，目标的设立顺序应该是公司到部门到组到个人。

个人自己想做什么，和管理者想他做什么一般来说是不会完全相同的。那他可以通过先查阅上层的目标，在自己想做的事情范围内找到能对公司目标有利的部分，将他拿出来和自己的管理者进行讨论，做权衡取舍。某种情况下，很有可能这个自己想做的东西，会变成公司今后改变的发展方向。（比如gmail的例子）

沟通的问题：分两种方式。

一对一的交流，即个人和他的管理者沟通。尤其是在一季度结束，另一季度开始时，要协商好关键结果是什么。因为不仅个人能说明自己想做什么，也是上面表达他想要你做什么，最好的情况是两者得到结合。

全公司的meeting，以team的形式进行，各team的learder参加并介绍自己组的OKRs，最终大家一起打分评估。

一些基本的要求：

最多5个O，每个O最多4个KRs。

百分之六十的O最初来源于底层。下面的人的声音应该被听到，这样大家工作会更有动力。

所有人都必须协同，不能出现任何命令形式。

一页