下载掌阅APP，畅读海量书库
立即打开
许多正在实践DevOps的企业正在使用目标与关键结果（OKR），其中包括谷歌、微软、Twitter和Uber。
OKR是企业定义和跟踪目标及其结果的灵活框架。
OKR方法可以追溯到20世纪70年代，当时OKR之父安德鲁·格鲁夫将该方法引入英特尔。这种方法被称为iMBO，即英特尔目标管理。他在《高产出管理》（Grove，A.S., 1983）一书中描述了这种方法。
1999年，约翰·多尔将OKR引入谷歌。安德鲁·格罗夫将iMBO引入英特尔时，约翰·多尔曾在英特尔工作。OKR很快成为谷歌文化的核心部分。约翰·多尔于2018年出版了《衡量重要性》一书，使OKR声名大噪。如果读者想更多地了解OKR，强烈推荐阅读这本书。
OKR是一个帮助组织实现战略目标的高度对齐的框架，同时为团队和个人保持最大程度的自主权。目标是定性的目标，能给人指明方向并且启发和激励人们。每个目标都与明确可测量的定量指标相关，即关键结果。关键结果应侧重于结果，而不是活动，如表1-2所示。
表1-2 OKR的特点
OKR绝不应与企业的绩效管理体系或员工奖金挂钩！企业的目标不是实现OKR的100%成功率——这意味着OKR不够具有挑战性。
OKR的格式如下：
我们用（一组关键结果）来衡量（目标内容）。
很重要的是OKR关注的是结果，而不是具体过程。一个很好的例子就是谷歌的首席执行官桑达尔·皮查伊在2008年推出Chrome浏览器时设定的目标。OKR是这样说的：
我们用在2008年年底拥有2000万用户这个结果来衡量打造最好的浏览器这一目标。
对于一款新浏览器来说，这个目标是大胆的，谷歌在2008年年底能实现这一目标，实际只有不到1000万用户使用Chrome。2009年，关键结果增加到5000万用户，谷歌同样未能实现这一目标，只有大约3700万用户使用Chrome。但它并没有放弃，而是在2010年将关键目标提高到1亿用户！这一次，谷歌超额完成了他们的目标，拥有1.11亿用户！
要让OKR发挥作用，企业需要一个好的目标与愿景来定义“WHY”：我们为什么为这家企业工作？然后将愿景分解为中期目标（称为MOALS）。MOALS本身也是OKR。它们被分解为OKR周期，通常在3～4个月之间。在OKR计划和对齐中，OKR在组织中被分解，以便个人和每个团队都有自己的OKR，为实现更大的目标做出贡献。然后对OKR进行持续监测，通常每周进行一次。在OKR周期结束时，对OKR进行回顾，并庆祝所取得的成就。随着在周期中获取经验，MOALS得到更新，开始一个新的周期（见图1-6）。
图1-6 OKR周期
OKR在理论上很简单，但实现起来却很困难。制定好的OKR尤其困难，需要大量的实践。它还强烈依赖于企业文化、现有的度量标准和关键绩效指标（KPI）。
一旦正确实行，OKR可以使团队在保持自治的同时，对他们正在构建的内容有很强的一致性，而不仅仅是在他们如何构建上（见图1-7）。在第19章讨论实验时，这一点很重要。团队可以定义自己的实验并衡量输出。基于此他们决定将哪些代码保留在项目中。
图1-7 OKR帮助实现一致性和自治性
现在请看一个案例。
某企业的愿景是成为在线可视化项目管理工具的市场领导者。企业产品目前的市场份额是12%。企业的MOAL如下：
我们将构建最好的可视化项目管理工具，到2025年年底市场份额将达到75%。
产品由两个团队构建：一个团队专注于产品的核心，并开发项目管理可视化的功能。他们专注于现有的客户，打造客户喜爱的产品。他们同意接受以下OKR：
用NPS高于9，来衡量构建深受客户喜爱的可视化项目管理工具这一目标。
NPS目前是7.9，所以团队必须自己想出如何让客户满意的方法。在与一些客户进行了几次面谈之后，团队提出了一个假设，即所有的项目管理工具都是基于旧的项目管理技术，并且在面向敏捷的项目的情景中过于复杂。团队决定对部分客户进行实验，用一个全新的概念来验证或否定这个假设。
第二个团队是共享服务团队，主要关注用户管理、企业集成和计费。产品需要更多的新用户来实现MOAL，而不仅仅是让现有用户满意。因此，OKR周期的重点是为产品带来新客户，如下所示：
用每月新注册客户增长20%，来衡量构建一个新客户易于使用的项目管理工具这一目标。
目前，新注册用户已经趋于稳定，所以团队的目的是重启增长趋势。该团队查看了这些数字，发现许多新客户在详细信息页面上退出了注册过程，因为客户必须输入自己的地址和账户详细信息。团队假设如果注册过程更简单，就会有更多的客户尝试该产品，并希望留在平台上。团队决定进行一项实验，将注册过程减少到认证所需的最低限度，为新客户提供30天的免费试用，并要求在此期限后提供付款详情。
第18章和第19章将解释假设驱动的开发和实验是如何进行的。这独立于OKR，但两者都能很好地协同工作。
如果读者对真实世界的OKR感兴趣，GitLab公开分享了他们的OKR（https://about.gitlab.com/company/OKRs/）。他们还分享了建立OKR的整个过程，以及如何将OKR与史诗和问题联系起来。
OKR不是DevOps的先决条件，但与敏捷开发一样，只是天生匹配。如果团队不是以敏捷开发，而是从DevOps开始，那工作方式无论如何都会变得高效，可以从Scrum等框架中受益，不必重复造轮子。OKR也是如此：当在大型组织中推广DevOps，并且希望通过保持与全局目标的一致来为团队提供极大的自主权时，就会自然而然地建立OKR。