谷歌OKR最佳实践

编写有效的 OKR

做得不好/管理不善的 OKR 是在浪费时间，是一种空洞的管理姿态。做得好的 OKR 是一种激励管理工具，可帮助团队明确在日常工作中什么是重要的，什么要优化，以及要做出什么权衡。编写好的 OKR 并不容易，但也并非不可能。请注意以下简单规则³：

目标是“Whats”

• 表达目标和意图；
• 积极但现实；

• 必须是有形的、客观的和明确的；对于一个理性的观察者来说，目标是否已经实现应该是显而易见的。
• 成功实现目标必须为 Google 提供明确的价值。

关键结果是“How”

• 表达可衡量的里程碑，如果实现，将以对他们的选民有用的方式推进目标；
• 必须描述结果，而不是活动。如果您的 KR 包含“咨询”、“帮助”、“分析”或“参与”等词，则它们描述的是活动。相反，您需要描述这些活动的最终使用影响：“在 3 月 7 日前发布来自六个 Colossus 单元的平均和尾部延迟测量值”，而不是“评估 Colossus 延迟”；
• 必须包括完成的证据。这些证据必须可用、可信且易于发现。证据示例包括更改列表、文档链接、注释和已发布的指标报告。

跨团队 OKR

Google 的许多重要项目都需要来自不同群体的贡献。OKR 非常适合致力于这种协调。跨团队的 OKR 应该包括所有必须实质性参与 OKR 的群体，并且承诺每个群体的贡献的 OKR 应该明确出现在每个此类群体的 OKR 中。例如，如果广告开发和广告 SRE 和网络部署必须交付以支持新的广告服务，那么所有三个团队都应该有 OKR，描述他们交付项目部分的承诺。

承诺与理想的 OKR

OKR 有两种变体，区分它们很重要：

1. 承诺是我们同意将实现的 OKR，我们将愿意调整时间表和资源以确保它们得以交付。承诺的 OKR 的预期得分为 1.0；低于 1.0 的分数需要解释，因为它表明计划和/或执行中存在错误。
2. 相比之下，有抱负的 OKR 表达了我们希望世界的样子，即使我们不清楚如何到达那里和/或交付 OKR 所需的资源。理想型 OKR 的预期平均得分为 0.7，方差很大。

经典的 OKR 写作错误和陷阱

陷阱 #1：未能区分承诺的和有抱负的 OKR

• 将承诺的 OKR 标记为有抱负会但增加失败的机会。团队可能不会认真对待它，也可能不会改变他们的其他优先事项以专注于交付 OKR。
• 另一方面，无法实现 OKR 目标将在团队中产生防御性。

陷阱 #2：一切照旧的 OKR

• OKR 通常主要基于团队认为在不改变他们目前正在做的任何事情的情况下可以实现的目标，而不是团队或其客户真正想要的。

陷阱 #3：胆怯的 OKR

• 有抱负的 OKR 通常从当前状态开始，并有效地问：“如果我们有额外的员工并且有点幸运，我们能做什么？”，另一种更好的方法是这样开始：“如果我们摆脱了大多数限制，几年后我（或我的客户）的世界会是什么样子？”。根据定义，当首次制定 OKR 时，您不会知道如何达到这种状态——这就是为什么它是一个有抱负的 OKR。但是，如果不了解和阐明所需的最终状态，您就无法保证您将无法实现它。
• 试金石：如果您问客户他们真正想要什么，您的理想目标是否达到或超过了他们的要求？

陷阱 #4：故意降低表现

• 一个团队承诺的 OKR 应该消耗大部分但不是全部可用资源。他们承诺的 + 有抱负的 OKR 消耗的资源应该比他们的可用资源多一些。（否则他们实际上是在提交。）
• 无需团队的所有人数/资本即可满足所有 OKR 的团队。. . 假设要么囤积资源，要么不推动他们的团队，或两者兼而有之。这是高级管理层将员工人数和其他资源重新分配给能够
  更有效利用它们的团队的提示。

陷阱 #5：低价值目标（又名“谁在乎？”OKR）。

OKR 必须承诺明确的业务价值——否则，没有理由花费资源来做这些。低价值目标 (LVO) 是指即使目标以 1.0 完成，也没有人会注意到或关心的目标。

• 一个经典（且诱人）的 LVO 示例：“将任务 CPU 利用率提高 3%。” 此目标本身并不能直接帮助用户或 Google。然而，（可能相关的）目标是“在不改变质量/延迟的情况下将服务峰值查询所需的核心数量减少 3%。. . 并将由此产生的多余内核返回到免费池中”具有明显的经济价值。这是一个更高的目标。
• 这是一个试金石：OKR 能否在不提供直接最终用户或经济利益的情况下在合理情况下获得 1.0？如果是这样，那么需要重新编写 OKR 。”

陷阱 #6：KR 不足以实现 O。

• OKR 分为预期结果（目标）和实现该结果所需的可衡量步骤（关键结果）。编写 KR 时，所有关键结果的得分为 1.0，目标得分为 1.0，这一点至关重要。
• 一个常见的错误是编写必要但不足以完成目标的关键结果。这个错误很诱人，因为它让团队避免与“硬”关键结果所需的困难（资源/优先级/风险）正面交锋。

• 这个陷阱特别有害，因为它会延迟发现实现目标需要的资源，导致目标无法按计划完成。
• 试金石：是否有可能在所有关键结果上都得 1.0 分，但仍然没有达到目标的意图？如果是这样，添加或重新处理关键结果，直到它们成功完成才能保证目标也成功完成。

阅读、解释和执行 OKR

承诺型 OKR

• 预计团队将重新安排他们的其他优先事项，以确保按计划交付 1.0。
• 无法可信地承诺 OKR 上交付 1.0 的团队必须迅速升级。这是一个关键点：在这种（常见）情况下升级不仅可以，而且是必需的。无论问题是由于对 OKR 的分歧、对其优先级的分歧，还是无法分配足够的时间/人员/资源，升级都是好的。它允许团队的管理层制定选项并解决冲突。

推论：每一个新的 OKR 都可能涉及一定程度的升级，因为它需要改变现有的优先事项和承诺。不需要更改任何团队活动的 OKR 是一种一切照旧的 OKR，它们不太可能是新的——尽管它们之前可能没有被记录下来。

• 在到期日之前未能达到 1.0 的承诺 OKR 需要进行事后分析。这不是为了惩罚团队。它旨在了解在 OKR 的计划和/或执行过程中发生了什么，以便团队可以提高他们在承诺的 OKR 上可靠地达到 1.0 的能力。
• 承诺 OKR 类别的示例是确保服务满足本季度的 SLA（服务水平协议）；或在设定日期前为基础设施系统提供定义的功能或改进；或以某个成本点制造和交付一定数量的服务器。

抱负型 OKR

• 一组有抱负的 OKR 将在设计上超出团队在给定季度的执行能力。OKR 的优先级应告知团队成员在完成团队承诺后将剩余时间花在哪里的决定。一般来说，优先级较高的 OKR 应该在优先级较低的 OKR 之前完成。
• 理想的 OKR 及其相关的优先事项应保留在团队的 OKR 列表中，直到它们完成，并在必要时逐个季度进行。由于缺乏进展而将它们从 OKR 列表中删除是一个错误，因为它掩盖了优先级、资源可用性或对问题/解决方案缺乏理解等持续存在的问题。

推论：如果该团队拥有比当前 OKR 所有者更有效地完成 OKR 的专业知识和能力，那么将一个有抱负的 OKR 移到另一个团队的列表中是件好事。

• 团队经理应该评估完成他们理想的 OKR 所需的资源，并每季度提出要求，履行他们向企业表达已知需求的职责。然而，管理者不应期望获得所有必需的资源。

测试

一些简单的测试，看看你的 OKR 是否良好：

• 如果你在五分钟内把它们写下来，它们可能不太好，那就需要思考。
• 如果您的目标不适合在一条线上，没有对齐，则它可能不够清晰。
• 如果您的 KR 以团队内部术语（“Launch Foo 4.1”）表示，它们可能并不好。重要的不是发布，而是它的影响。为什么 Foo 4.1 很重要？更好：“启动 Foo 4.1 将注册率提高 25%。” 或者简单地说：“将注册率提高 25%。”
• 使用真实日期。如果每个关键结果都发生在季度的最后一天，那么您可能没有真正的计划。
• 确保您的主要结果是可衡量的：必须能够在季度末客观地分配成绩。“提高注册率”并不是一个好的关键结果。更好：“到 5 月 1 日将每日注册量提高 25%。”
• 确保指标是明确的。如果您说“100 万用户”，那是全时用户还是 7 天活跃用户？
• 如果您的团队中存在 OKR 未涵盖的重要活动（或其工作的很大一部分），请添加更多活动。
• 对于较大的团队，使 OKR 分层——对整个团队有高层的，对子团队有更详细的。确保“横向”OKR（需要多个团队贡献的项目）在每个子团队中都有支持的关键结果。