Bob Jiang | 敏捷教练 | Scrum Master

敏捷培训 | Scrum培训 | 组织创新

谷歌OKR指导手册 (译)

Posted at — Apr 22, 2020 阅读

译者:乔梁 来源:《持续交付2.0》公众号

这是一本关于 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是有野心的,它不是逐步增量式的,我们并没有希望一次性就完成所有这些野心。(如果我们真的这样做,那么,我们就不会具有足够的进取性)。

我们用色阶来衡量我们做得有多好:

正确的OKR制定方法规则

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

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

  1. 规则1:O 要回答的是 “What” 的问题,它应当:
  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 分,因为它存在高度的不确定性。

关注《持续交付2.0》

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状态吧。

wechat