《谷歌OKR员工手册》_OKR加油站-源目标

《Google OKR员工手册》

来源：谷歌（况阳译）

在谷歌，我们喜欢从大处着想（Think Big）。因此，我们采用了一种叫做OKR的方法来帮助我们沟通、衡量并达成那些远大的宏伟目标。

OKR一定要是很有挑战，而不仅仅是跳一跳就可以够得着的。我们无须无一遗漏地达成所有目标（如果我们真的这么做了，那只能说明我们的目标定得还不够挑战。）

正确的OKR制定方法

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

请遵循如下这些简单的OKR制定规则：

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

· 表达清楚目的和意图；

· 挑战且现实可行；

· 必须真实、客观，绝不含糊；

· 旁观者应该能够明确无误地判断出一个O是否达成；

· O的达成应对Google产生明确的价值和意义。

规则2：KR要回答的是“How”的问题，它应当：

· 清晰可衡量，一旦KR达成了，能有力地推动O的完成；

· 必须是产出导向，而非动作导向。如果你的KR包含有像“咨询”、“帮助”、“分析”、“参与”这样的词汇，那么它描述的实际上是动作而非结果。与之相反，如果描述的是这些动作对最终用户所带来的影响，例如：“在3月7日前公布6个巨细胞的平均潜伏期和最长潜伏期“就是一个合格的KR，而“评估巨细胞潜伏期”则不是。

· 必须能自证其是否已完成。这个证据取消绩效是可轻易获取的和可信赖的，例如，证据可以是变更列表、文档链接、已发布的质量报告等。

OKR写作常见错误与陷阱

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

把指令性OKR和挑战性OKR混为一谈的结果通常是真正的指令性OKR没有资源去完成，而另外一方面，挑战性OKR又不能真正的获得必要的资源支持，这会在团队中制造抵触心理。

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

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

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

对挑战性OKR而言，当它最初被制定出来的时候，你并不知道如何才能实现它，这才是挑战性OKR的真正要义。

错误4：OKR不敢挑战

指令性OKR和挑战性OKR合在一起所消耗的资源量，应当是超出团队目前的可用资源范围的。

错误5：低价值O（戏称“谁在乎”型OKR）

低价值O指的是那些即使你百分百完成了，得分达到1.0了，也没有人会真正注意到的O。

一个经典（也很有诱惑力）的低价值O示例：“将CPU利用率提升3个百分点。”这个O本身对用户和谷歌并不能带来什么帮助。

然而，如果将O描述成这样：“在不改变质量/延迟/…的情况下，将峰值查询所需内核数量减少3%，并将多余的内核返回空闲资源池。”则清晰地描述出了经济价值，就是一个好的O了。

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

一个常见的错误是，所有的KR都是必要但却非充分的，也即当这些KR都完成了，却无法支撑O的实现。这个错误很有可能是故意造成的，因为这让团队躺在舒适区，不去做必要的资源/优先级/风险等承诺，这比交付“困难”的KR要容易得多。

可以做一个小测试：如果把所有KR的得分都标记成了1.0，是否仍没有达成所希望的目标或意图？如果是，那么请增加KR，或者重新组织KR，直到O下所有KR能完整无误地支撑其达成为止。

自测Tips

可以通过下述这些小测试来检验你的OKR是否是一个好的OKR：

· 如果你只用了5分钟就写出了一个OKR，那么它通常不会是一个好OKR。请重写。

· 如果你的O超过2行，它很可能就是不清晰的。

· 如果你的KR描述中充斥着内部团队术语，例如“发布 Foo 4.1”，它们通常就不是好的OKR。真正重要的不是“发布”这个动作，而是其所造成的影响（Impact）究竟是什么。为什么Foo 4.1很重要？更好的表述是这样的：“发布Foo 4.1系统，促使注册用户数提升25%。”或者简单地写成这样：“提升注册用户数25%”

· 使用真实日期。如果所有的KR的截至日期都是季度的最后一天，你制定的计划就很可能是有问题的。

· 确保你的KR是可度量的：KR必须是每个季度末可以进行客观评分的。“提升注册用户数”不是一个好的KR，“在5月1号前提升日均注册用户数25%”则是一个好的KR。

· 确保度量指标是清晰的。如果你说“一百万用户”，你要指明这指的是全时段用户，还是只是7天活跃用户。

· 如果你发现有些重要活动或者重要活动的相当一部分工作量没有包含到OKR中，请把它加进去。对大型团队来说，可以对OKR进行分层，采用OKR级联的方式去对OKR进行分解：上层团队关注大颗粒度OKR，下层团队关注小颗粒度OKR.

· 确保那些需要横向协同的OKR在每个支撑团队都已制定相应的KR在支撑它。