OKR
许多实践 DevOps 的公司都在使用目标与关键结果（OKRs）——其中包括谷歌、微软、推特和优步。
OKR 是一个灵活的框架，用于公司定义和跟踪目标及其成果。
OKR 方法可以追溯到 1970 年代，当时 OKR 的奠基人安德鲁·格罗夫（Andrew Grove）将这种方法引入英特尔。这种方法被称为 iMBO，即英特尔目标管理（Intel Management by Objectives）。他在他的著作《高效能管理》（High Output Management）中描述了这种方法（Grove, A. S. (1983)）。
1999 年，约翰·多尔（John Doerr）将 OKR 引入谷歌。他曾在安德鲁·格罗夫引入 iMBO 时为英特尔工作。OKR 很快成为谷歌文化的核心部分。
约翰·多尔出版了他的书《衡量重要的事》（Measure What Matters）（Doerr, J. (2018)），这使得 OKR 成为家喻户晓的概念。如果你想了解更多关于 OKR 的信息，我强烈推荐阅读这本书。
什么是OKR？
OKR 是一个帮助组织在战略目标上实现高度对齐，同时保持团队和个人最大自主性的框架。目标（Objectives）是定性的目标，旨在提供方向并激励和鼓舞人们。每个目标都与明确可衡量的定量指标——关键结果（Key Results）相关联。关键结果应关注成果，而不是活动，如下表所示：
OKR 绝不应与公司的绩效管理系统或员工奖金挂钩！目标不是实现 100% 的成功率——这意味着 OKR 设定得不够具有挑战性。
OKR的格式如下：
我们将 [目标] 通过 [一组关键结果] 来衡量
重要的是，OKR应该聚焦于结果，而不是活动。一个很好的例子是谷歌首席执行官（CEO）Sundar Pichai在2008年为谷歌推出Chrome浏览器时设定的OKR。这个OKR是：
我们将打造最好的浏览器 通过2008年底达到2000万用户来衡量
这个目标对一个新浏览器来说非常大胆，而谷歌在2008年没有达到目标，用户数不到1000万。到了2009年，关键结果目标增加到5000万用户，然而谷歌再次未能达成，用户数约为3700万。但谷歌并没有放弃，而是继续将目标提高——到2010年，目标设定为1亿用户！这次，谷歌超额完成了目标，达到了1.11亿用户！
OKR如何运作？
为了让OKR发挥作用，公司需要有一个清晰的愿景和使命，以定义“为什么”：
我们为什么为这家公司工作？
愿景随后被分解为中期目标（称为MOALS）。这些MOALS本身也是OKR。它们被进一步分解为OKR周期的OKR，通常周期为3到4个月。在OKR规划和对齐过程中，OKR会在组织内逐层分解，以便每个个人和每个团队都有自己的OKR，这些OKR都能为更大的目标做出贡献。然后，OKR会被持续监控，通常是每周一次。在OKR周期结束时，OKR会被审查，并（希望）庆祝成果。通过从周期中获得的经验教训，MOALS会进行更新，新的周期随之开始（见图1.6）。
OKR 在理论上很简单，但实施起来并不容易。写出好的 OKR 尤其困难，需要大量的实践。它还与企业文化以及现有的度量标准和关键绩效指标（KPI）有很大的依赖关系。
OKR与DevOps
一旦正确实施，OKR 可以使您的团队之间保持强大的对齐，同时保留他们决定自己构建什么的自主权，而不仅仅是决定如何构建（见图 1.7）。当我们在第 19 章《使用 GitHub 进行实验和 A/B 测试》中讨论实验时，这一点尤为重要。您的团队可以定义自己的实验并衡量结果。基于此，他们决定哪些代码留在项目中，哪些不留。
现在让我们来看一个例子。 贵公司的愿景是成为在线可视化项目管理工具的市场领导者。您目前的市场份额为12%。公司的中期目标（MOAL）如下： 我们将构建最好的可视化项目管理工具 通过在2025年底之前实现75%的市场份额来衡量
您的产品由两个团队构建：一个团队专注于产品的核心，构建项目管理的可视化界面，主要面向现有客户，致力于打造一款客户喜爱的产品。该团队达成了以下OKR： 我们将构建一款客户喜爱的可视化项目管理工具 通过NPS评分超过9来衡量
目前的NPS为7.9，因此该团队需要自行决定如何才能使客户更为满意。经过几次与客户的访谈后，他们提出了一个假设：所有的项目管理工具都基于较老的项目管理技术，在更具敏捷导向的项目环境下显得过于复杂。为此，他们决定针对部分客户进行实验，推出一种全新的可视化项目管理概念，以验证或否定这一假设。
第二个团队是共享服务团队，专注于用户管理、企业集成和账单处理。为了实现公司目标（MOAL），产品需要吸引更多新用户，而不仅仅是让现有用户满意。因此，本周期内该团队的OKR关注的是吸引新客户，如下所示： 我们将构建一款易于新客户使用的项目管理工具 通过每月新增注册用户增加20%来衡量
目前，新注册用户的增长已趋于平缓，因此目标是再次推动增长。该团队分析数据后发现，很多新客户在注册过程中的详细信息页面放弃注册，尤其是在填写地址和银行信息时。他们假设，如果简化注册过程，更多客户可能会尝试该产品，并有可能留下来。为此，他们决定进行一次实验，将注册流程简化至仅要求身份验证所需的最基本信息，并在30天的免费试用期后再要求提供支付信息。
我将在第18章《精益产品开发和精益创业》和第19章《使用GitHub进行实验和A/B测试》中解释假设驱动开发和实验的方法。这与OKR无关，但两者可以很好地结合使用。
如果您对实际的OKR感兴趣，GitLab公开分享了他们的OKR（https://about.gitlab.com/company/okrs/）。他们还分享了整个过程，以及如何将OKR与史诗任务（epics）和问题（issues）进行关联。
OKR并不是DevOps的前提条件。但与敏捷实践一样，它们非常契合。如果您没有采用敏捷方式并开始实践DevOps，您的工作方式最终会变得敏捷，您可以通过Scrum等框架受益，而无需重新发明轮子。同样，对于OKR：当您在大公司中扩展DevOps时，它们也会自然地成为一部分，并帮助您为团队提供很大的自主性，同时保持与全球目标的一致性。