谷歌OKR案例:深度解读《谷歌OKR员工手册》（谷歌的okr）

谷歌okr案例:深度解读《谷歌OKR员工手册》（谷歌的okr）

在开始阅读正宗版的《Google OKR员工手册》之前，请允许译者再啰嗦几句。我们都知道，OKR源于Intel，光大于Google，也因此，在我们试点OKR的时候，总是试图去弄清Google的OKR是什么，运作效果如何，以及为什么能取得这样的效果。但令人遗憾的是，一方面，Google是一家极其自由和开放的公司，另外一方面，它也是一家极其封闭的公司。其开放性体现在它对内部员工是开放的，所有员工只要跨入Google公司的大门，公司内部几乎所有文档和代码的权限，无特别声明时对他们都是开放的，也即是说，开放是Google的默认选项。然而，这个开放仅止于Google内部，你甚至无法在外部找到Google公司内部的哪怕任何一个OKR示例。也难怪，搜索引擎是Google自己做的，它如果不想开放，谁又能搜索得到呢。

好在，2015年前的几年里，Google的前CEO施密特和Google前CHO拉兹·博格，相继出版了2本书，一本叫《How Google Works》，中文名《重新定义公司》，一本叫《Work Rules》，中文名《重新定义团队》，分别介绍了Google的整体业务运作和人力资源运作，可算是部分满足了外界对如日中天中的Google的猎奇心理。但高层主管出版的书，通常焦点在道的层面，很少聚焦到术的层面，其结果就是，你看得很兴奋，然而回到工作岗位上后，发现理想很丰满，现实很骨干，并没有什么卵用，离真正实操还有十万八千里。

下文翻译的这篇《Google OKR员工手册》，源于Google内部（已公开），是实实在在地瞄准员工层面的OKR指导手册，你可以通过它，真实地感受到Google是如何要求它的员工开展OKR的。这寥寥数页文字，帮你去除身上的高贵气，真正地趴在天间地头上查看OKR的生长规律。请君鉴赏。

《Google OKR员工手册》

在谷歌，我们喜欢从大处着想（Think Big）。因此，我们采用了一种叫做OKR的方法来帮助我们沟通、衡量并达成那些远大的宏伟目标。我们的行动决定着谷歌的未来。就像我们一再看到的那些案例那样，我们在搜索团队、在Chrome浏览器团队、在安卓团队，通过紧密协同，只用了很少量的公司人力，就取得了辉煌的业绩。因此，对谷歌的员工和经理来说，很重要的一点是我们要有意识地、谨慎而明智地选择如何分配我们的时间和精力。

我们用OKR来规划我们要做哪些事，跟踪这些事的进度开展情况，在员工之间以及团队之间协调工作的优先级和里程碑点。我们还用OKR来帮助大家聚焦在那些最重要的目标上，避免他们被那些重要但不紧急的目标分散精力。

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，而“评估巨细胞潜伏期”则不是。

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

跨团队OKR

在谷歌，很多重要的项目需要多个不同的团队一起协同方能完成。OKR是帮助致力于这种跨团队协同的理想工具。跨团队OKR的责任人应包括所有需要参其中的团队，每个团队都应当将它所负责的跨团队OKR明确无误地写到它自己团队的OKR中去。举例来说，如果广告开发部、广告SRE部和网络开发部三个部门需协同交付一个新的广告服务，那么这三个团队就应该有一个共同的团队OKR，来描述他们的这项交付工作，指明各个部门在这个项目中所应做出的贡献。

指令性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：

如果你只用了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在支撑它。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。