这是一本关于 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：O 要回答的是 "What" 的问题，它应当：
- 表达清楚目的和意图；
- 挑战且现实可行；
- 必须真实、客观，绝不含糊；
- 旁观者应该能够明确无误地判断出一个O是否达成；
- O的达成应对Google产生明确的价值和意义。
- 规则2：KR 要回答的是 "How" 的问题，它应当：
- 清晰可衡量，一旦KR达成了，能有力地推动O的完成； - 必须是产出导向，而非动作导向。如果你的KR包含有像"咨询"、"帮助"、"分析"、"参与"这样的词汇，那么它描述的实际上是动作而非结果。与之相反，如果描述的是这些动作对最终用户所带来的影响，例如："在3月7日前公布6个巨细胞的平均潜伏期和最长潜伏期"就是一个合格的KR，而"评估巨细胞潜伏期"则不是。 - 必须能自证其是否已完成。这个证据取消绩效是可轻易获取的和可信赖的，例如，证据可以是变更列表、文档链接、已发布的质量报告等。
- 规则3：跨团队OKR
在谷歌，很多重要的项目需要多个不同的团队一起协同方能完成。OKR是帮助致力于这种跨团队协同的理想工具。跨团队OKR的责任人应包括所有需要参其中的团队，每个团队都应当将它所负责的跨团队OKR明确无误地写到它自己团队的OKR中去。
举例来说，如果广告开发部、广告SRE部和网络开发部三个部门需协同交付一个新的广告服务，那么这三个团队就应该有一个共同的团队OKR，来描述他们的这项交付工作，指明各个部门在这个项目中所应做出的贡献。
- 规则4：指令性OKR和挑战性OKR
通常，存在两种类型的 OKR（指令性OKR和挑战性 OKR ），有必要对他们进行区分：
指令性 OKR 指的是那些我们必须承诺达成的OKR，我们必须调度充足的资源在指定时间内确保达成它。
对指令性 OKR 而言，目标分数是 1.0 ；如果得分低于 1.0 必须做出相应的解释，因为这意味着计划上或者执行上存在偏差。
与之相反，挑战性 OKR 则意味着即便在我们对未来一无所知，或者在无法获得必要资源支持的情况下，也依然应该去探索的那些事。挑战性 OKR 承载的是我们改变世界的梦想。
挑战性 OKR 的目标分数是 0.7 分，因为它存在高度的不确定性。
OKR写作常见错误与陷阱
- 错误1：把指令性 OKR 和挑战性 OKR 混为一谈
把指令性 OKR 当成是挑战性 OKR ，会增加 OKR 达成的风险。团队可能不会去认真对待挑战性 OKR ，确保高优先投入其中以成功交付这些 OKR 。
另外一方面，如果把挑战性 OKR 标记成了指令性 OKR ，就会出现优先级倒置情况，一方面，真正的指令性 OKR 没有资源去完成，而另外一方面，挑战性 OKR 又不能真正的获得必要的资源支持，这会在团队中制造抵触心理。
- 错误2 ：OKR 只是在例行公事
所制定的 OKR 都是些团队无须做任何改变即可轻而易举完成的工作，而不是团队或者客户真正想要实现的那些事情。
- 错误3：挑战性 OKR 并不挑战
如果在制定挑战性 OKR 时的基本假设是："假如有额外的人力支撑，或者再幸运一些，那么我们可以做点什么？"，这样制定出来的 OKR 还不能算做是挑战性 OKR 。更好的做法是，在制定挑战性 OKR 时，问我们自己这样一个问题："如果我们解除了绝大多数限制，那么我或者我的客户的世界看起来应该是什么样的？"
对挑战性 OKR 而言，当它最初被制定出来的时候，你并不知道如何才能实现它，这才是挑战性 OKR 的真正要义。但如果你不去理解和描绘这种最终状态，你就必然实现不了，这和知道目标但不知道如何实现它是有本质区别的。
你可以做一个小测试：问你的客户他们真正想要的是什么，然后看看你定出的挑战性 OKR 是否达成或者超越了他们的预期？
- 错误4：OKR 不敢于挑战
毫无疑问，一个团队的指令性 OKR 会消耗他们大多数可用资源和精力，但不是全部资源和精力。指令性 OKR 和挑战性 OKR 合在一起所消耗的资源量，应当是超出团队目前的可用资源范围的，不然这个团队的 OKR 就全部都只是指令性 OKR ，因为指令性 OKR 是要求必须在现有资源范围内要能全部达成的 OKR 。
如果一个团队只使用部分人力/费用就能达成他们所有的 OKR ，那么这个团队事实上是在浪费资源，或者说团队一把手没有管理好他们的团队成员。这意味着上层管理团队需要重新分配其人力和资源，把它们调配给那些真正可以做得更好的团队。
- 错误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 。
- 错误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