如何整合OKR（目标和关键结果）与敏捷产品管理

【本文翻译自https://herbig.co】

目标和关键结果（OKR）是使自治（产品）团队获得支持，同时又使公司范围内始终专注于构建重要事项的有效方法。同样，尽管围绕如何实施OKR的“硬性”规则很少，但是，当您希望看到它发挥其真正潜力时，确实有一些最佳实践可以遵循。

但是，当您向已经在使用敏捷方法论的组织中引入像OKR这样的渐进工具时，您会遇到一些挑战：OKR和Epics（史诗）有何关系？OKR对我的产品路线图有什么影响？可以通过哪种方式将OKR集成到现有的Scrum过程中？此外，对于产品经理来说，什么是真正好的OKR？

因此，让我们仔细研究将OKR和敏捷产品管理相结合的挑战——从理论到最佳实践，再到将其整合到您的日常工作中。

OKR——组织的敏捷目标（OKR - Agile Goals for your Organisation）

OKR代表目标和关键结果。简而言之，OKR将目标设定的最佳实践组合到一个框架中：一个高度鼓舞人心的定性愿景，以及确定成功或失败的简明且可度量的度量标准。目标就像使命宣言，只是时间更短。一个伟大的目标激励着团队，虽然很难但不是不可能在规定的时间内完成，并且由确定该目标的人来独立实现。一个目标通常应该检查这些选项：

• 定性的和鼓舞人心的
• 有时限的
• 由团队独立执行

关键结果采用了所有鼓舞人心的语言并将其量化。您通过问几个简单的问题来创建它们：我们如何知道是否达到了目标？哪些数字会改变？

什么是目标和关键结果（OKR）？（What are Objectives and Key Results (OKR)?）

OKR将目标设定的最佳实践组合到一个框架中：一个高度鼓舞人心的定性愿景，以及确定成功或失败的简明且可度量的度量标准。关键结果都采用鼓舞人心的语言，并通过2-5个整体衡量标准对其进行量化。

一个公司应该有大约三个关键目标。关键结果可以基于您可以衡量的任何结果。如果您明智地选择了自己的KR，则可以通过确保代表了潜在的对立力量来平衡诸如增长和绩效，收入和质量等力量。一个公司的目标应该有三个关键的结果。关键结果可以基于任何你可以测量的东西。如果你明智地选择你的KRs，你可以平衡增长和绩效，或者收入和质量等潜在的对立力量。

一个“好的” OKR的常用示例如下：

目标	推出超赞的MVP
关键结果1	一周内有40％的用户使用两次
关键结果2	推荐分数八分
关键结果3	百分之十五的用户计划转换为高级版

OKR的“发明”经常被认为是安迪·格鲁夫在英特尔工作期间的功劳。后来，它通过像谷歌这样的硅谷公司的广泛实施而得到普及。当许多人欣赏Google为员工的绩效管理带来改进的同时，OKR也已经发展得更加完善。

如今，OKR对敏捷产品团队的吸引力在于其改变我们工作方式的核心承诺：

1. 更加专注
2. 更大的自主权
3. 更多对齐

但这到底是什么意思？

更加专注（More focus）

OKR的典型周期为一个季度。规模较小的公司可以将其与年度OKR合并起来，以使每个目标都可以在接下来的三个月中实现。

此外，虽然每季度为一个团队设置最多三个OKR是标准的（也是可以的），但是就每次专注的一些关键计划而言，这已经能够带来巨大的进步。虽然一些利益相关者混淆了迭代计划中的敏捷（Agile）和每两周改变一次他们想法的概念，但OKR提供了一条贯穿整个季度的持续发展之路。

此外，即使OKR不一定需要涵盖您的所有工作（每个人都知道某些维护工作可能很关键），但它们应该反映出对您的团队来说什么是最重要的。

更大的自主权（More autonomy）

好的OKR故意不谈论功能。相反，他们将注意力转移到团队应寻求产生的影响上，而不是通过发布的功能数量来衡量。对于您的利益相关者而言，这意味着推迟他们与您讨论功能列表的冲动，而是首先就一组结果指标达成一致。

对于团队来说，这意味着首先专注于最关键的（most critical）问题，以便有更多的机会找到更重要的杠杆来实现雄心勃勃的（ambitious）关键结果。

好的OKR故意不谈论功能。相反，他们将注意力转移到团队应寻求产生的影响上，而不是通过发布的功能数量来衡量。

更多对齐（More alignment）

确定OKR的过程应该涉及公司的各个层级。虽然领导层设定公司级别的OKR是很自然的事，但下一步是让公司的其他团队也要参与进来。

只有这样，单个团队才有可能从公司的整体方向中获得灵感，以契合的OKR的形式定义他们的贡献。通过在季度开始/结束时对OKR进行定义，并审查整个公司的重点工作，可以大大减少对团队之间的相互依赖性和优先级的误解。

制定敏捷目标的完整OKR周期

敏捷产品管理层（Layers of Agile Product Management）

构建数字产品的执行过程常常被误认为是简单的发布代码。相反，我想拓宽你的视野，让你了解可持续的敏捷产品管理流程的三个层次：

1. 规划——使用主题（Themes）而不是基于时间（time-based）的路线图
2. 发现——为了解决客户问题，决定实际构建什么
3. 交付——产品构建的实际过程，重点关注基于任务和用户故事的迭代开发

让我们仔细看看这些步骤背后的含义，以了解在敏捷产品管理流程中实现OKR的切入点。

规划路线图（Planning with Roadmaps）

遗憾的是，大多数企业仍然依赖基于时间的路线图，这些路线图遵循甘特图风格的可视化，用于规划未来12个月的产品开发。虽然这种方法可能适用于我们过去经常使用的静态瀑布式规划，但它并不适合敏捷和迭代方法，因为敏捷拥抱不确定性，而不是试图在最后期限前才解决它。

基于时间和基于敏捷的路线图对比

一个更合适的方法是根据所谓的基于主题的路线图来规划你的工作。它们使您能够优先考虑更广泛的计划，而不是固定的功能集，并且随着您对未来的进一步了解，不确定性会不断增加。

您还可以将主题（themes）作为特定史诗（epics）的父元素进行比较。主题代表了一个更重要的用户或业务问题，您希望找到一个解决方案(即Epic)来实现您的目标。

典型的基于主题的路线图可以分为以下三类：

1. 现在——你现在正在做的事情。
2. 下一步——即将到来的工作。
3. 以后——您将来想从事的工作，但是在继续工作之前需要做更多的研究。

主题的例子可以是“用户增长”、“收入”、“用户流失”或“企业”之类的东西。相应的史诗可以是“推荐机制”、“免费试用”或“单点登录”。

C.Todd Lombardo在Mind the Product San Francisco Conference in 2018上就现代路线图的构建方法做过一次精彩演讲。

建立产品探索过程（Setting up a Product Discovery Process）

尽管主题为实现目标提供了一个大致的方向，但您的产品探索过程应有助于您确定要构建的内容。发现（Discovery）这个术语在这里应该被理解为一种思维方式（mindset），这样你就可以保持足够的灵活性，以便在你的旅程中找到解决方案。

虽然对于产品探索来说没有一种放之四海而皆准的方法，但是好的发现方法有一些共通的步骤，您可能需要按照大致顺序进行操作（取决于您的利益相关者和组织结构）：

Tim Herbig的迭代和模块化产品探索过程

1. 对齐（Alignment）——集中精力让您的团队和利益相关者在需要做什么、需要哪些资源、实际目标是什么以及需要避免哪些副作用等方面达成一致。有多种框架可用于实现一致性，但最重要的是，它应该为创建自组织团队服务。
2. 研究用户问题（Research & User Problems）——在这个阶段，您可以通过现有的定性和定量数据来发现潜在的用户问题，或者进行研究以弄清事情的真相。
3. 构想（Ideation）——在此阶段，您将变得有创意，如何解决用户群中已确定的问题。想法最好能在多元的群体中验证，从而尽可能避免现有的偏见并保持开放的心态。
4. 创造（Creation）——现在是时候将最有前途的想法变得更加具体了。通过基于构想会议（ideation session）的结果创建一些高保真或低保真原型，您可以快速了解解决方案的外观和感觉。
5. 验证（Validation）——在编写任何代码之前，都需要将所创建的解决方案(以某种方式)重新交给用户来确定它们的有效性。通过使用可用性访谈或模拟的登录页面等工具，你必须确定你的想法有多少价值。
6. 细化（Refinement）——当一个想法的核心价值主张得到验证时，需要对其进行分解以用于将来的开发。到目前为止，在设计文件中看起来很漂亮的东西现在需要切成小块，并且最好是独立的可发布部分，用户故事地图（User Story Mapping）是实现这一目标的绝佳工具。

遍历产品交付周期（Iterating through the Product Delivery Cycle）

如果您执行的想法不正确，那么它们将一文不值。此阶段是产品交付（Product Delivery）发挥作用的地方。现在，使用SCRUM或Kanban之类的敏捷框架，您需要将已确定和经过验证的想法作为跨功能团队的一部分来协调执行。

例如，如果您使用Scrum来组织您的工作，则您要建立如下所示的开发周期：

典型的Scrum产品交付周期

典型Scrum周期的所有活动主要可以分为两部分：组织当前周期的工作和准备下一步的工作。

虽然冲刺计划是关于提交接下来两周的工作，但是审查（Review）和回顾（Retrospective）分别关注已经完成的工作和团队可以改进的工作。另一方面，待办事项细化（The Backlog Refinement）和反馈与估算（Feedback & Estimation）会议讨论下一个冲刺的潜在问题，并确保大家理解需要执行的操作以及这些问题的复杂程度。

一起玩 - 双轨敏捷（Playing together - Dual Track Agile）

产品探索与产品执行之间的关系通常称为“双轨敏捷（Dual Track Agile）”，因为两个工作流都需要采用关注客户、迭代进度和跨功能协作的思维方式。

产品探索和产品交付如何在双轨敏捷中共同发挥作用

建立关联（Connecting the Dots）

公司里的每一项活动都是关于为什么、做什么或如何做的。例如，一个公司的愿景、使命和战略着眼于长期(一年以上的未来)，从而定义了一个公司的目的（WHY）。另一方面，OKR（目标和关键结果）和敏捷产品执行都集中在短期到中期的时间轴上，从日常工作重点一直到规划季度目标。

OKR如何与敏捷产品管理相关联

让我们将产品执行的不同层次及其各自的时间范围，与OKR作为敏捷目标系统提供的粒度进行比较。显然，要成功地采用这两种框架，我们需要将它们集成到所有常规的决策过程中。

在产品待办列表中链接OKR和用户故事 使用关键结果跟踪用户故事的成功

在最高层次上，在为特定的计划创建一致性时，可以将已定义和承诺的OKR与敏捷产品管理流程联系在一起。实现这一目标的一个很好的框架是由战略顾问Stephen Bungay开发的任务简报框架（mission briefing framework）。在概述产品探索的关键任务时采用“结果第一”的思维方式，您就无法超越自己，而是专注于你现有的OKR中定义的定性目标和相应的成功标准。

任务简报（mission briefing）是一个简单的文档，重点关注项目的五个基本方面：

• 首先，写下你的团队所处的环境——在这里，您应该客观地描述你的产品和市场所处的环境。收集所有可以使外部观察者了解现状的事实，以及是什么变化导致你现在的新方案。
• 其次，解释高层目标——虽然这部分通常被视为引述CEO言论的地方，但对于作为一个领导者，你有必要向你的同事展说明他们的努力与公司的大局（比如公司的愿景，使命和战略）相符是至关重要的。因此，这里看似简单的问题是：“如何与我们的整体使命和战略保持一致？”
• 第三，详细说明我的意图——在这里，您可以激发同事跟随您的旅程。您想简化现实生活中的复杂问题，并通过给同伴一个总体目标来使他们采取行动：这是一种对本质的洞察。想想如何把高层目标也联系起来。
• 第四，注意关键的隐藏任务——不要被标题弄糊涂。这不是为你的团队编写一个如何执行该项目的分步教学手册（还记得领域专家如何抵制人们进入其领域吗？）。相反，你应该列出你的团队在前进的道路上需要取得什么样的成果，以便奥他们可以针对这些结果进行划分和进一步分配。
• 第五，定义边界——在这里，我们希望为我们同行的创意游乐场添加正确的护栏。这是关于说明我们明确将不会在此项目中进行的操作以及不允许发生的副作用（side effect）。诸如此类的指标通常也被称为“关键失败指标”（Key Failure Indicators），这些指标是你不希望在计划中朝着特定方向发展的指标。KFI旨在与项目的主要KPI保持平衡，即 “在保持毛利率的同时增加收入。”

任务简报（mission briefing）旨在确定您将要进行的特定产品探索工作，以实现OKR中定义的团队目标。

当开始产品执行（Product Execution）时，您需要确保您的产品待办列表中有尽可能多的条目可以与OKR相关联。只有这样，您才能将日常任务与组织的高层目标联系起来。如果您使用JIRA管理用户故事和敏捷流程，则可以通过一组自定义字段轻松集成此OKR连接。内置的仪表板会给你一个简明的概述，告诉你团队为达成OKR付出了多少工作：

当开始产品执行（Product Execution）时，您需要确保您的产品待办列表中有尽可能多的条目可以与OKR相关联。只有这样，您才能将日常任务与组织的高层目标联系起来。

将JIRA问题与团队OKR相关联

OKR与Scrum流程整合（Combining OKR and Scrum Routines）

接下来，通过将活动与检查其相关性的问题相关联，还可以将每个敏捷订单链接到前面提到的OKR的链接，也可以将每个敏捷例程与目标链接起来：
接下来，除了前面提到的将单个的待办事项与OKR关联外，你还可以将你的每一个敏捷流程与OKR联系起来，方法是将你的敏捷活动与目标联系起来:

• 双周迭代计划：要使我们的OKR取得进展，要优先处理哪个事项？
• 双周评审：我们取得了哪些产出和成果？
• 双周回顾：我们的合作是如何达到我们的标准的?

将OKR集成到您的产品路线图流程中（Integrating OKR into your Product Roadmap Process）

当您的公司仍陷于年度静态路线图流程中时，您很快就会遇到引入像OKR这样的敏捷目标系统与这种类型的计划之间的（典型）冲突。如果OKR（通常）“仅”专注于四分之一，那么您应该在一年的其他九个月中提出要求的路线图吗？
当您的公司仍然停留在静态的年度路线图流程中时，您很快就会遇到像引入OKR这样的敏捷目标与这种类型的计划之间的典型冲突：OKR（通常）只关注一个季度，那么您应该在一年的其他九个月的路线图上写些什么呢?

解决这一冲突的一个办法是引入年度OKR，以共享未来12个月的总体方向。当你把每季度的重点放在解决方案的执行上时，每年一次的OKR当然可以帮助利益相关者放松下来。尽管他们可能无法获得像全年基于功能的路线图所感知到的那种安全性和详细程度，但您仍然可以大致(但更可靠地)了解今年什么时候会成功。

如果你把年度OKR放在基于主题的路线图方法（theme-based roadmap approach）旁边，他们的对比大致是这样的:

年度OKR和基于主题的路线图

在产品探索中使用OKR（Utilizing OKR in Product Discovery）

虽然产品交付的重复步骤很合适使用OKR，但是将OKR集成到更不可预见的产品探中会有一些挑战。

一方面，有一个时间方面的问题：当您在本季度初定义了OKR，然后开始（通常）为期6周的探索阶段时，你几乎没有足够的时间来对你正在构建的东西产生影响。尤其是如果您考虑到有时需要交付功能后好几周，才能导致客户行为和度量指标的变化。

如果您能够将关键结果集中在成果上，并将OKR集成到现有工具和流程中，那么OKR可以作为敏捷很好的补充。

另一方面，如果你还不知道下个季度的目标，你该如何决定去探索哪个领域呢？这就是基于主题的路线图概念再次派上用场的地方。

因为你对你的团队想要和需要以后在哪些领域工作有一个大致的了解，你可以为当前季度定义一个产品探索OKR。这可能包括“了解10个企业（Enterprise）产品前景的关键需求”这样的关键结果，因为你下个季度的主题之一是“企业（Enterprise）”。

这样，可以使用OKR来组织敏捷团队的双轨制工作，并且产品经理也可以清楚地了解其产品探索的工作重点。

OKR与产品探索节奏对照

使用健康指标获得持续认知（Using Health Metrics for ongoing awareness）

完成一个季度的OKR之后，人们最担心的是之前关注的目标会发生什么变化？主要结果是否会因为新的OKR而开始下降？健康指标（Health metrics）是解决这个问题的好方法。

健康指标可以是你在过去一个季度中最关心的主题之一，同时使用一个简单的交通信号灯评分来跟踪它们。

结合OKR产品管理的健康指标

为了避免设置太多OKR，健康指标会是一个很好的补充。与其尝试用OKR覆盖业务的各个方面，不如将重点放在真正重要的方面（一个季度/团队很少超过3个）。其他所有内容都可以使用健康指标以较小的粒度进行衡量。

但是，不要把健康指标的“红色”评级与注意力的转移混为一谈。如果你为了改善一个健康指标而停止OKR的工作，它可能应该是一个OKR。影响健康指标的任务应该伴随您的主要重点工作，不要分散您的注意力。

产品经理的OKR示例（OKR Examples for Product Managers）

无论您的组织决定将OKR级联到个人级别，还是在团队级别停止，以下是一些具体的OKR示例，供产品经理参考，以便为您自己的OKR定义过程提供一个起点。

产品执行OKR示例（Product Execution OKR Examples）

目标	使现有企业客户满意，为续签合同打下基础
关键结果1	每个客户发生0起重大事件（例如阻止程序错误或数据丢失）
关键结果2	每个客户端要求的和实现的功能至少要使用一次
关键结果3	为企业客户建立反馈过程，且反馈结果平均分为“满意”

目标	成功启动我们主要产品的版本3
关键结果1	获得超过15种出版物的已发布产品评论
关键结果2	获得10000多个新注册
关键结果3	达到50％以上的试用付费率

产品探索OKR示例（Product Discovery OKR Examples）

目标	我们的用户对我们接下来要构建的东西很感兴趣。
关键结果1	JIRA集成了用户研究、构思和最有前途的想法的验证。
关键结果2	测试三种捕捉用户兴奋点的新技术。

目标	激活用户对我们产品的测试
关键结果1	进行至少21次面对面的用户测试和访谈
关键结果2	从Usertesting.com至少接受15个视频采访

远程团队的OKR（OKR for Remote Teams）

围绕共同的目标调整远程团队可能是一个相当大的挑战。以下是我最近在Hamburg召开的OKR会议上发表的一些最佳实践和建议。在这篇文章中，我分享了我们在iridion的一个完全分布的团队中实现OKR的方法。