OKR篇：Google OKR员工手册告诉你，真正的OKR是什么？

在人力资源界有一种叫OKR的管理方法。是目前最最流行和火热企业员工考核方法之一。听说高逼格的公司都在使用这种方法。例如：Google、Oracle、滴滴、字节跳动……

OKR前世？

上个世纪50年代加州大学的教授创立了目标管理体系，Manage By Objective，简称MBO，德鲁克是这个体系的坚定推动者。50年代开始，位于加州的HP，Intel等企业就一直大力推行目标管理体系，直至今天。

后来,Intel的VP John Doerr投资了Google，在99年的时候John给Google的两位创始人说，你们需要更成熟的管理体系，就把Intel使用的OKR体系介绍给了两位创始人，从那个时候起一直沿用至今。

目标管理之前是指令管理，工业时代到来手工业者和农民进入工厂，机器的力量胜过了人的力量。对于产业工人来说，服从指令是那个时候要务。

服从指令的缺点是：

1、没有人对最终结果负责，每个人只对自己的过程负责。

2、人的主观能动性被压抑。

3、结果高度依赖机器和管理者的指令。

目标管理的精髓是：

1、员工和经理共同制定目标，员工对结果负责。（请对比指令管理）

2、员工在设定目标后自主决定实现的路径和方法，经理人提供必要的资源。

3、经理人在过程中提供辅导，帮助和监控，不能撒手不管。

不要太在意叫法是什么，多看看背后的管理原则和管理脉络就好。

OKR全称是Objectives & Key Results，即目标与关键成果。

所谓OKR，O = Objective 可以理解为企业目标，KR ＝Key Results 可以理解为关键结果。浓缩在一起就是“为确保达成企业目标的关键结果分解与实施”。

主要知识：

1、OKR是企业进行目标管理的一个简单有效的系统，能够将目标管理自上而下贯穿到基层。对一个项目来说，设定目标是非常重要的，因为这决定了如何去做，以及能做到何种程度。

2、OKR 首先是沟通工具：团队中的每个人都要写 OKR，所有这些OKR都会放在一个文档里。任何员工都可以看到每个人在这个季度最重要的目标是什么，团队这个季度的目标是什么。

3、OKR是努力的方向和目标：OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。

4、OKR必须可量化（时间和数量）。比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」，肯定不是一个好的 OKR，因为无法衡量，好的OKR是「今年的跑步时间较去年增加一倍」。

5、目标必须一致：制定者和执行者目标一致、团队和个人的目标一致。首先，制定公司的OKR；其次，每个团队定自己的 OKR；第三，每个工程师或设计师写各自的OKR。这三步各自独立完成，然后对照协调这三者的OKR。OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。

6、目标要是有野心的，有一些挑战的，有些让你不舒服的。一般来说，“最佳”的 OKR 分数在0.6-0.7之间，如果某人只拿到1分，那么他 OKR 订的目标显然是野心不够的。但是低分数的人也不应该受到指责，而是应通过看他工作上的数据，帮助他改进下一季度的 OKR 目标。

7、通过月度会议Review ，时时跟进OKR：在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。

8、通过季度会议Review ，及时调整OKR：互联网的变化非常快，每季度有一个OKR 的 review，调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）。

讨论OKR之前，有必要先说一个前提：impact文化。衡量的是员工为impact，而不是员工是不是很努力地干了很多活，也不是员工是不是听老板的话完成了老板布置的任务。

所以OKR也是为了让员工有可能做出更大的impact服务的，因而有以下特点:

1. 模糊的目标，用于统一努力的方向，而非计划

所有做过IT项目的人都知道，再周全的计划总是赶不上变化。所以OKR不是计划，只是一个模糊的目标，具体如何实现还需要探索。但有了目标至少有了努力的方向，这样，个人的目标，团队的目标和公司的目标才有可能能够一致，从而为产生更大的impact提供可能。

2. 量化

OKR必须是个measurable goal

3.由员工或者Tech Lead提出，而非经理

OKR需要统一的是个人的目标和团队的目标。Tech Lead负责的是团队的目标，而员工在意的是个人的职业生涯和个人为Google做出的impact，两个目标通过共同制定OKR来统一。

4. (基本)不作为考核标准

既然OKR是用来统一目标而非衡量成果的，一般不作为考核标准，虽然Perf的过程中也会参考，但1.0和0.7之间本身并没有太大差别。

1、公司：OKR 是管理层向整个公司表达近期想要着重做的事情？是开拓新的领域还是深耕现有领土？

2、团队：OKR 是团队 Leader 首先需要考虑为了公司的 OKR，自己的团队能为了做什么；除此之外本团队想做的紧急而重要的事情；

3、个人： OKR 除了绑定公司和团队的 OKR，自己还想改变和挑战什么，为什么？

执行时的几个关键点：

1、自上而下：公司和团队的 leader 需要明确自己想要的 O 是什么？更重要的是为什么有这个 O？然后是各项优先级，至于 KR 可以多种多样；

2、需要遵循SMART原则：任何一个同学都能看懂你的 OKR，特别是跨部门的同学；

3、强调产出(Key Results) : 所谓产出导向就是关注做事情的成果，而不仅仅关注事情做了没有；

4、及时调整：定期排序，调整优先级。

主要收益：

1、OKR 公开之后，每个团队和个人都能清楚伙伴们在做什么，避免浪费，借力合作。

2、每个人的精力是有限的，对应到团队和公司也一样；OKR 更多会是作为一个管理方法或者沟通的工具，经常打开 OKR 看看，让大家的努力都在一定时间内专注在一致的方向上。

对于员工：

1、绑定到公司、部门的OKR，对应于她的 JD ，她需要做什么？

2、除此之外，还有什么是部门、个人迫切想改变和挑战的？比如科学的评价体系、如何提升效率。

制定OKR的基本方法是：

1、设定一个“目标”（Objective），这个目标务必是确切的、可衡量的，例如不能说笼统地说“我想让我的网站更好”，而是要提出诸如“让网站速度加快30%”或者“融入度提升15%”之类的具体目标

2、设定若干可以量化的“关键结果”（Key Results），用来帮助自己实现目标。

OKR在谷歌

在Google成立的第一年，投资者约翰·杜尔提出了使用目标和关键结果法（OKR）设定目标的想法。他把它作为一种有效的方法，既能设定高水平的目标，又能以量化的方式衡量这些目标的进展。我确信他做了一个很有说服力的演讲，因为OKR很快就被整个公司接纳了。

OKR系统是在组织内设定可衡量的目标并将公司、团队和个人目标联结起来的有效方式。它使你的公司和员工在聚焦于一个明确、共同的目标，并不断发展壮大。

今天，每一个Google的新员工，在他加入的首周，都需要花时间观看Google的风险投资伙伴Rick Klau在YouTube上关于OKR的演讲与介绍。

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

OKR一定要是很有挑战，而不仅仅是跳一跳就可以够得着的。我们无须无一遗漏地达成所有目标(如果我们真的这么做了，那只能说明我们的目标定得还不够挑战。)我们用下面几个颜色来标识目标的完成情况：

0.0 – 0.3 是红色

0.4 – 0.6 是黄色

0.7 – 1.0 是绿色

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

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

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

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

如果你的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分，因为它存在高度的不确定性。

错误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能按计划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小时内删除侵权内容。