IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

OKR 工作法简介

唐巧的博客 2019-08-10 22:33:13 累计浏览 5,508 次
本机暂存

   最近看了 《OKR 工作法》,又查了一些相关资料,觉得是一个很好的面向个人和自组织团队的管理方法,而且它可以和 Scrum 的工作法搭配使用,于是给大家介绍一下。

   我的介绍大纲是:

  • OKR 的历史

  • OKR 的内容

  • 如何实践 OKR

  • OKR 与 Scrum

  • OKR 与 KPI

  • OKR 的问题

OKR 的历史

   很多人应该听过 Intel 的传奇人物安迪·格鲁夫。他是 Intel 的前 CEO,领导了 Intel 从一家濒临倒闭的存储器公司,转型为微处理器公司。我曾在 2016 年也分享过他的一本著作的 读书笔记:《High Output Management》,中译版叫 《格鲁夫给经理人的第一课》

   格鲁夫在 Intel 公司引入了 OKR 工作法,随后这种工作法在硅谷流行,被 Google 和 Linkedin 等公司采用。随后 OKR 工作法传入中国,明道团队为推广 OKR,翻译了《OKR 工作法》,也推出了一些相关的资料和工具。据我所知,今日头条在公司内部推行和使用了 OKR。

OKR 的内容

   OKR 即 Objective 与 Key Results 的首字母缩写。

   OKR 的核心其实一句话就能讲明白:制定一个较长期的目标(Objective),并且将目标分解成为一些关键的结果(Key Results)。

   OKR 在这个核心思想下,再附加有一些规范:

  • 希望目标和关键结果不要泛滥,小的团队和个人刚开始最好只定一个目标,3 个以内的关键结果,以便再加专注。

  • OKR 的实施结果不要与绩效挂钩。不要与绩效挂钩。不要与绩效挂钩。希望我重复三遍能有一些强调效果。

  • OKR 的目标应该较长,最少一个月以上。我个人觉得以季度为粒度的阶段目标较为合适。

  • OKR 不追求完成,而是追求最大挑战。关键结果应该制定在 50% 可能性能够完成的假设上,以便发挥团队最大的动力。稍后我们看到,我们用 5/10 来表示初始的关键指标信心指数。

  • 实施 OKR 的团队应该是自组织的团队,而不应该严重依赖于外部团队成员。

  • OKR 的目标和关键结果应该由团队讨论决定,而不应该是领导指定。

  • 每隔一段时间回顾一下 OKR 的结果,大家分享成绩,并重新调整信心指数。

如何实践 OKR

   OKR 在上面这个核心思想下,构建了一个更加具体的实践流程,《OKR 工作法》中用一个四象限的画布来呈现这个实践,这个画布如下所示:

   在这个画布中:

  •    右上角是我们的 OKR 主要内容,它包含了目标和关键结果的内容。在每个关键结果的最后,我们标注上完成该结果的信心指数,初始值为 5/10,即 50%。

  •    右下角是我们支持完成该关键结果的一些状态指标,有助于帮助我们更好的判断关键结果的达成可能性。

  •    左上角列出本周重点需要完成的事情。

  •    左下角列出未来四周需要重点完成的事情。

   介绍完画布,那 OKR 的实践过程,就是围绕着这个画布做创建和更新:

  • 第一次先团队一起讨论,初始化这个画布。大家需要对目标和关键结果达成一致,并且初始化信心指数为 5/10,初始化围绕这些关键结果的当周重要工作。

  • 每周更新讨论一次这个画布。如果一些事情完成了,那么信心指数应该会有所变化,可能上升为 6/10。如果事情没有完成,那么信心指数就保持不变,但是大家因为有这个讨论过程,自然就会反思和总结为什么。

  • 每过一个周期(一个季度或更长时间),重新重置这个画布,看是否要调整目标和关键结果。

   如果你的团队正在实施 Scrum,那么 OKR 稍微调整一下,就可以与 Scrum 进行一定程度的融合,我稍后会介绍。

OKR 与 Scrum

   我认为 OKR 与 Scrum 可以完美融合。因为 OKR 属于宏观和全局视角,关注于长远的目标和任务的主干。Scrum 属于微观和具体视角,关注于每个 Sprint 迭代的工作与是否能够按时完成。

   OKR 属于战略,战略层面上我们要藐视敌人,所以我们要定制高标准,高目标。即便达不成,团队也在超着超预期的目标前进。就像雷军说的,梦想总是要有的,万一达成了呢!

   Scrum 属于战术,战术层面上我们要重视敌人,万丈高楼平地起,事情是一步一个脚印做的。所以我们在 Scrum 会上要强调客观,强调工作拆解与估分,强调每天的站立会议检查进度与风险,强调完成。

   OKR 强调高标准。让关键结果只有 50% 的信心指数。OKR 也不会因为最后完不成这些梦想而让团队反思。

   Scrum 强调完成。Sprint 中的迭代如果没有完成,是需要整个团队认真反思和改进的。

   那么 OKR 与 Scrum 如何融合呢?我觉得可以把 OKR 与 Sprint 的计划会议、评审会议、回顾会议进行一定程度上的整合。具体来说:

  • 在 Scrum 计划会议的最后。我们将其中与 OKR 最相关的事情,列到 OKR 的画布的左上角象限。便于我们是否将与目标最相关的事情排在了当周工作中。同时我们将 Scrum 的待办事项列表中,选出与 OKR 最相关的事情,列到 OKR 画布的左下角象限。

  • 在 Scrum 回顾会议的最后。我们更新一次 OKR 的信心指数,看是否有变化。

  • 评审会议其实和 OKR 流程中提到的每周五分享好的结果其实非常相似,我们可以认为它俩做的是同一件事情。

   在这种融合方案下,我们仅需要在 Scrum 的流程最后,加入一点点更新 OKR 画布的工作,即可以让我们在 Scrum 的微观视角中融入宏观视角,既不费时,效果又好。

OKR 与 KPI

   KPI 通常和绩效绑定。这使得大家非常在意它的完成与否。而这种情况下,大家容易走极端,从而背离 KPI 背后的初衷。

   我举几个我身边的真实故事。

   故事一:某个社交产品为了拉明星入驻。把明星数定位 KPI,于是很多编辑拉明星的时候,只要他注册一个帐号,就送礼物,丝毫不考查这些明星帐号有没有真正用起来。

   故事二:某个公司的 PM,他的 KPI 是一个页面某个按钮的点击率。他为了这个点击率,设计出让用户很容易误点,结果点击率很快就上去了。

   故事三:某个公司,为了达成安装量目标 KPI,去积分墙刷量,结果这些量留存率极低,根本就是垃圾下载量。有人说:那我定几个组合的 KPI 来避免极端呢?组合的 KPI 一来使得大家对目标就不太清楚了。二来如果定得少了,也容易出现钻空子。比如,在刷量市场上,就有人专门不但帮你刷下载量,还帮你做留存数据。

   OKR 怎么解决这个问题的呢?其实很简单,OKR 不与绩效绑定!

   KPI 本质上是一种外部激励,利用金钱来驱动人性努力工作。但是人性又习惯走捷径,所以只要有一种捷径可以达到 KPI,人性很可能会忽视别的影响。但是一个产品要做好,很多时候不是一两个指标的事情。

   OKR 本质上是一种内驱激励,它假设人们都会追求有价值的工作和生活。于是 OKR 并不与绩效挂钩,但是将各种自主权利下放,并且构建一个扁平化的、自组织的团队,让这个团队来自己设立高标准并为之努力。

   有人说,OKR 应该替代 KPI ,我觉得这句话如果潜台词是:OKR 应该替代 KPI 做绩效管理,那就不对。在很多情况下,KPI 就是应该被干掉的,不管有没有 OKR 存在。我们猿辅导公司在创业前 5 年,都没有 KPI ,也没有听过什么 OKR ,团队一样正常工作和发展。

   所以,OKR 与 KPI 并不是替代关系。它们俩一个是做绩效考核的,一个不是做绩效考核的,何从来「代替」这个说法呢?

   OKR 真正替代的,是原本缺少的、或者并不明确公开出来的团队季度目标与目标拆解。以前这些事情可能在团队负责人的文档里面,需要团队负责人自己记得更新和传达,现在用一个工作法流程化了,使得这部分工作更透明了,团队就更容易朝一个方向努力。

OKR 的问题

   OKR 的问题在于,很多公司的组织架构并不适合施行 OKR。用 OKR 做产品的话,需要这个团队是一个以业务为单元的组织,融入了产品建设需要的各种人才,比如:产品经理、运营、设计、开发、测试。如果公司是以职能做为团队划分的单元,则会对 OKR 的推进造成影响。因为职能团队的目标通常是偏专业角度的,而不是偏业务角度的。

   OKR 另一个问题在于,构建一个自组织团队本身就很难。OKR 希望大家主动地讨论目标和关键结果,但这强依赖于团队的积极性。如果团队并不是一个积极向上的组织,那么 OKR 很容易流于形式。变成另一种管理者的工具。

   OKR 还有一个问题,就是团队对于它的学习和理解需要付出额外的努力。如果理解不当,就并不会产生效果。比如,如果管理者不理解 OKR,把它当作 KPI 的替代品做绩效考核,那么就其实把 OKR 当一个多 KPI 组合在用了,本质上还就是在用 KPI。

小结

   OKR 也适合个人自我管理,特别是你需要兼顾很多事情的时候,OKR 可以帮你理清出最重要的目标与关键结果,从而让你生活得更舒适。

   希望本文能帮助到大家,谢谢!

同分类推荐文章

  1. 一个冷门的速查日历方法 (2026-05-27 16:22:00)
  2. Stack Overflow: When We Stop Asking (2026-05-20 21:51:34)
  3. Use Obsidian Sync on Desktop without Installing Obsidian (2026-03-27 00:00:00)

查看更多 开发者 文章 →

建议继续学习

  1. 再次写给我们这些浮躁的程序员 (累计阅读 17,085)
  2. 技术人员的未来:做技术还是做管理? (累计阅读 8,785)
  3. 小公司如何留住人才 (累计阅读 6,104)
  4. 加班与效率 (累计阅读 6,106)
  5. 软件公司的两种管理方式 (累计阅读 5,485)
  6. 领导如何应对员工离职 (累计阅读 5,410)
  7. 不懂技术的人不要对懂技术的人说这很容易实现 (累计阅读 5,246)
  8. 产品经理与研发经理的分工 (累计阅读 5,245)
  9. 项目经理是干什么的 (累计阅读 4,965)
  10. 互联网的人才储备 (累计阅读 4,926)