谷歌OKR指导手册 (译)

这是一本关于 OKR 迷你小册子，名为《google OKR playbook》，由 www.whatMatters.com 网站发布。 该网站由John Doerr 团队经营， 而John Doerr 正是 1999年将 OKR 引入 谷歌的那我的。

本文仅供你们学习参考，虽然文章较长，但值得一读，欢迎收藏。

文章的末尾有一些 8 道自我测试题，用来验证你的OKR是否在正确的实施。

若是你正实施OKR，能够用它们来验证一下吧～

在实现OKRs方面
没有人比谷歌更有经验

随着公司规模的扩大，它按期发布 OKR 指南和模板。如下摘录主要来自内部资源，并经谷歌许可转载。
（注：这是谷歌对 OKRs 的作法。你的方法可能不一样，也应该不一样。）

在谷歌，咱们喜欢大张旗鼓。咱们使用一个称为目标和关键结果（OKRs）的过程来帮助咱们沟通、衡量和实现这些崇高的目标。

咱们的行动决定了谷歌的将来。正如咱们在互联网搜索、Chrome 和 Android 中屡次看到的那样，一个由少许员工组成的团队，朝着一个雄心勃勃的共同目标努力，就能够在不到两年的时间里改变整个成熟的行业。

所以，做为谷歌的员工和经理，咱们必须有意识地、谨慎地、明智地选择如何分配咱们我的与团队成员的时间和精力。OKR 是这种谨慎选择的体现，也是咱们协调我的行动，以实现伟大集体目标的手段。

---

咱们使用 OKR 来规划要生产的产品，跟踪它们的进度与计划，并协调人与团队之间的优先级和里程碑。
咱们也用 OKRs 帮助你们专一于最重要的目标，并帮助他们避免被紧急但不过重要的目标分散注意力。

---

OKR是有野心的，它不是逐步增量式的，咱们并无但愿一次性就完成全部这些野心。（若是咱们真的这样作，那么，咱们就不会具备足够的进取性）。

咱们用色阶来衡量咱们作得有多好：

• 0.0 -- 0.3 是红色●
• 0.4 -- 0.6 是黄色●
• 0.7 -- 1.0 是绿色●

正确的OKR制定方法规则

没有认真实施和管理的OKR，是一种时间上的浪费，是管理上的假大空。与之相反，若是实施得好，OKR将是一种很好的动机激励工具，它能让团队明白什么是真正重要的，哪些地方须要优化，在平常工做中应当如何去进行利弊权衡。

要写出好的OKR可不是一件容易的事，但也不是不可能。请遵循以下这些简单的OKR制定规则：

1. 规则1：O 要回答的是 "What" 的问题，它应当：

• 表达清楚目的和意图；
• 挑战且现实可行；
  - 必须真实、客观，毫不含糊；
  - 旁观者应该可以明确无误地判断出一个O是否达成；
  - O的达成应对Google产生明确的价值和意义。

1. 规则2：KR 要回答的是 "How" 的问题，它应当：

- 清晰可衡量，一旦KR达成了，能有力地推进O的完成； - 必须是产出导向，而非动做导向。若是你的KR包含有像"咨询"、"帮助"、"分析"、"参与"这样的词汇，那么它描述的其实是动做而非结果。与之相反，若是描述的是这些动做对最终用户所带来的影响，例如："在3月7日前公布6个巨细胞的平均潜伏期和最长潜伏期"就是一个合格的KR，而"评估巨细胞潜伏期"则不是。 - 必须能自证其是否已完成。这个证据取消绩效是可轻易获取的和可信赖的，例如，证据能够是变动列表、文档连接、已发布的质量报告等。

1. 规则3：跨团队OKR

在谷歌，不少重要的项目须要多个不一样的团队一块儿协同方能完成。OKR是帮助致力于这种跨团队协同的理想工具。跨团队OKR的责任人应包括全部须要参其中的团队，每一个团队都应当将它所负责的跨团队OKR明确无误地写到它本身团队的OKR中去。

举例来讲，若是广告开发部、广告SRE部和网络开发部三个部门需协同交付一个新的广告服务，那么这三个团队就应该有一个共同的团队OKR，来描述他们的这项交付工做，指明各个部门在这个项目中所应作出的贡献。

1. 规则4：指令性OKR和挑战性OKR

一般，存在两种类型的 OKR（指令性OKR和挑战性 OKR ），有必要对他们进行区分：

指令性 OKR 指的是那些咱们必须承诺达成的OKR，咱们必须调度充足的资源在指定时间内确保达成它。

对指令性 OKR 而言，目标分数是 1.0 ；若是得分低于 1.0 必须作出相应的解释，由于这意味着计划上或者执行上存在误差。

与之相反，挑战性 OKR 则意味着即使在咱们对将来一无所知，或者在没法得到必要资源支持的状况下，也依然应该去探索的那些事。挑战性 OKR 承载的是咱们改变世界的梦想。

挑战性 OKR 的目标分数是 0.7 分，由于它存在高度的不肯定性。

OKR写做常见错误与陷阱

1. 错误1：把指令性 OKR 和挑战性 OKR 混为一谈

把指令性 OKR 当成是挑战性 OKR ，会增长 OKR 达成的风险。团队可能不会去认真对待挑战性 OKR ，确保高优先投入其中以成功交付这些 OKR 。

另一方面，若是把挑战性 OKR 标记成了指令性 OKR ，就会出现优先级倒置状况，一方面，真正的指令性 OKR 没有资源去完成，而另一方面，挑战性 OKR 又不能真正的得到必要的资源支持，这会在团队中制造抵触心理。

1. 错误2 ：OKR 只是在例行公事

所制定的 OKR 都是些团队无须作任何改变便可垂手可得完成的工做，而不是团队或者客户真正想要实现的那些事情。

1. 错误3：挑战性 OKR 并不挑战

若是在制定挑战性 OKR 时的基本假设是："假若有额外的人力支撑，或者再幸运一些，那么咱们能够作点什么？"，这样制定出来的 OKR 还不能算作是挑战性 OKR 。更好的作法是，在制定挑战性 OKR 时，问咱们本身这样一个问题："若是咱们解除了绝大多数限制，那么我或者个人客户的世界看起来应该是什么样的？"

对挑战性 OKR 而言，当它最初被制定出来的时候，你并不知道如何才能实现它，这才是挑战性 OKR 的真正要义。但若是你不去理解和描绘这种最终状态，你就必然实现不了，这和知道目标但不知道如何实现它是有本质区别的。

你能够作一个小测试：问你的客户他们真正想要的是什么，而后看看你定出的挑战性 OKR 是否达成或者超越了他们的预期？

1. 错误4：OKR 不勇于挑战

毫无疑问，一个团队的指令性 OKR 会消耗他们大多数可用资源和精力，但不是所有资源和精力。指令性 OKR 和挑战性 OKR 合在一块儿所消耗的资源量，应当是超出团队目前的可用资源范围的，否则这个团队的 OKR 就所有都只是指令性 OKR ，由于指令性 OKR 是要求必须在现有资源范围内要能所有达成的 OKR 。

若是一个团队只使用部分人力/费用就能达成他们全部的 OKR ，那么这个团队事实上是在浪费资源，或者说团队一把手没有管理好他们的团队成员。这意味着上层管理团队须要从新分配其人力和资源，把它们调配给那些真正能够作得更好的团队。

1. 错误5：低价值O（戏称"没人在乎"型 OKR）

OKR 必定要体现清晰的商业价值，不然，就不值得浪费资源去作它们。低价值O（LowValued Objective, 简称 LVO ）指的是那些即便你百分百完成了，得分达到1.0 了，也没有人会真正注意到的 O 。

一个经典（也颇有诱惑力）的低价值 O 示例："将 CPU 利用率提高 3 个百分点。"

这个 O 自己对用户和谷歌并不能带来什么帮助。然而，若是将 O 描述成这样："在不改变质量/延迟/...的状况下，将峰值查询所需内核数量减小 3 %，并将多余的内核返回空闲资源池。"则清晰地描述出了经济价值，就是一个好的 O 了。

这里有一个小测试能够帮到你：OKR 可否在没有直接最终用户参与，或者产生经济收益的状况下就获得 1.0 分？若是是，那么你须要从新组织你的 OKR 描述，让它显性地体现有形收益。好比："发布X" 就没有道出成功的标准。更好的描述是："将 X 发布到 90% 以上的集群管理器网元，使集群 Y 容量翻番。" 则是一个不错的 O 。

1. 错误6：KR 不足以支撑 O 的达成

OKR 包含 2 个部分：O 描述的是指望达成的结果，KR 是达成这个结果所要经历的步骤。于是，关键的一点就是，若是全部 KR 的分数都是 1.0 了，那么与之相关的 O的分数也应该是 1.0 。在制定 OKR 时，一个常见的错误是，全部的 KR 都是必要但却非充分的，也即当这些 KR 都完成了，却没法支撑 O 的实现。这个错误颇有多是故意形成的，由于这让团队躺在温馨区，不去作必要的资源/优先级/风险等承诺，这比交付"困难"的 KR  要容易得多。

这一陷阱极其有害，由于它拖延了发现达成 O 所需资源的时机，没有及时暴露 O 不能按计划达成的风险。

能够作一个小测试：若是把全部 KR 的得分都标记成了 1.0 ，是否仍没有达成所但愿的目标或意图？若是是，那么请增长 KR ，或者从新组织 KR ，直到 O 下全部KR能完整无误地支撑其达成为止。

OKR查阅、解读和实施：

指令性OKR

要求团队要及时调整其余事项的优先级，以确保这部分 OKR 能按计划 100% 交付，这部分 OKR 的得分须为 1.0。

若是团队不能承诺在指令性 OKR 上达成 1.0分，团队须适当地将这一风险及时进行升级上报。这一点很关键：这种情形下的升级不只是合适的，并且你必须这么作。不管是由于对 OKR 的分歧、对其优先级的分歧，仍是因为没法分配足够的时间/人员/资源而致使没法按承诺达成 OKR ，都应对之进行升级。这让管理层能提早思考应对策略。

推论：这意味着每一个 OKR 都会涉及到适度升级，由于它须要基于已有优先级或者承诺作出改变。一个不须要作任何修改的 OKR 只是一个例行性 OKR ，即使之前没有被明确制定成 OKR，它们也不多是新的 OKR。

不能按时达成 1.0 分的 OKR 都应进行过后回溯。这不是要惩罚哪一个团队，而是要弄清楚究竟发生了什么，是计划制定不合理？仍是 OKR 执行上出现了问题，找到真正的问题所在，持续提高团队能力，以便将来更好地完成指令性 OKR。

指令性 OKR 的示例有：

- 确保服务达成 SLA（服务水平协议）。 - 发布预先定义好的特性，或者在指定日期提高基础设施系统的性能。 - 以必定成本制造并交付必定数量的服务器。

对挑战性OKR

挑战性 OKR 被设计成须要团队在某季度付出额外的努力才能达成的那些 OKR。挑战性 OKR 的优先级指明了团队成员在完成了指令性 OKR 后，还须要在哪些地方进行额外的时间和精力投入。当团队有多个挑战性 OKR 时，团队应优先完成高优先级挑战性 OKR ，而后再完成次优先级挑战性 OKR......依此类推，以确保资源和精力的聚焦。

挑战性 OKR 及其优先级，一样应该出如今一个团队的 OKR 列表上，直至其完成为止。若有必要，这些 OKR 能够持续多个季度，并不断推动其进展。仅仅由于一件事情进展不佳就将其从 OKR 列表中删除是不对的，这是在掩盖问题而非真正解决问题。

推论：若是另一个团队既有充足的专家资源也有充足的时间投入，那么把一个挑战性 OKR 转交给这个团队去作会更合适。

团队管理者须要每季度按期评估挑战性 OKR 的资源知足度，履行其职责确保业务的已知需求得以知足。管理者不是要接受全部的资源需求，而是应在团队全部指令性 OKR 完成以后，按目标优先级去进行资源调度。

关注公众号
回复 "OKR" 获取《OKR小测试》，
检测一下你的组织OKR状态吧。

本文首发于 Bob Jiang的博客 ，转载请联系 Bob Jiang