倾听来自专家的OKR建议

OKR实施建议

OKR建议

使用Scrum修复“OKR戏剧”

本文讲述了如何借鉴敏捷Scrum的一些原则来解决OKR的问题,只是把OKR当作戏剧在徒有形式地表演,而没有贯彻敏捷精神的问题。

 

 

 

OKR反模式

 

我遇到过许多试图用OKRs框架(目标和关键结果)改善战略与执行之间一致性的组织。这是好的意图,但我经常看到反模式(错误的模式),如:

 

- OKR看起来更像是任务而不是战略目标——特别是当它们到达工作团队的时候

- OKR过去常常对团队和个人进行微观管理,而不是赋予他们权力和能力。

- 太多的OKR的设定没有考虑到,在人们还要处理组织中发生的其他工作的同时,如何以可持续的方式实际交付这些OKR。

- 定义“OKR”,然后忘记它们,直到给它们评分的时候。(更糟糕的是,一些组织甚至不去认真考虑他们为OKR做了什么……)

 

 

 

 

OKR戏剧

 

这些反模式不是OKR的固有问题,它们可以被称为“OKR戏剧”。当你开始专注于操作方法,而忘记最初使用这些方法的原则/精神/原因时,你便会出现这样的问题。OKR戏剧有潜力成为一个大家庭的一员——Scrum戏剧、敏捷戏剧、SAFe戏剧、精益戏剧、六西格玛戏剧,你明白了吧。当一个好方法传播得太广泛,而实施它的人缺乏最初从业者所拥有的深度和经验时,就会发生这种事情。这就是已故的杰里·温伯格所说的“覆盆子果酱定律”——“你把它抹得越宽,它就越薄。”

 

 

 

 

处理OKR戏剧

 

这种戏剧将会存在下去。我们能做什么呢?似乎有帮助的一个步骤是试着回忆我们为什么要做某事——在这里是OKR——以及它们是否达到了我们预期的结果。我们用OKR制定的要实现的目标是什么?预期的关键结果是什么?我们是否看到了朝着正确方向发展的迹象?

 

 

 

 

OKR(和Scrum……)在复杂领域蓬勃发展

 

接下来,我们需要反思我们在什么样的环境下运作。我们的一些工作发生在一个简单或复杂的空间,我们可以设置OKR,想出一个计划,成功地执行它,并庆祝。

 

OKR通常是在挑战现状。超越“运营业务”。这可能需要开发新产品,打开新市场,释放效率,改变我们的组织,数字化转型,或者扩大现有业务或产品的规模。通常情况下,这些都是复杂的问题,我们知道的与我们不知道的相比显得微不足道。

 

这正是Scrum蓬勃发展的环境。这是否意味着我们需要Scrum来实现OKR ?当你可以围绕某个目标组织一个多职能的团队时,Scrum绝对是解决复杂问题的好方法,也是实现OKR的好方法。但它还不止于此。我们可以从应用Scrum的基本理论中获益,从OKR戏剧转移到更有效的OKR操作系统。

 

OKR的设置和管理应遵循经验主义、自我管理和持续改进的原则。

 

 

 

 

让我们来看看Scrum价值观在尝试有效实施OKR时是如何发挥作用的:

 

- 组织应该限制要求人们专注的OKR的数量。在OKR工作中,也应该具有“暂缓开始,聚焦完成”的心态。应考虑如何建立团队,使人们能够专注于一个OKR,而不必在复杂目标矩阵上工作,不必接触组织中的许多团队。

- 开放性——可以让为某OKR工作的人找到并提出比最初计划更好的方法,来实现预期的关键结果。或者他们可以建议瞄准不同的关键结果(KRs)。甚至他们能有勇气回来说,应该重新考虑这个目标。

- 实施OKR的组织应该承诺将OKR作为一个对齐框架,而不是伪装的微观管理工具。每个人都应该承诺去试验如何对工作进行组织,如何设置OKR,如何跟踪和评分OKR,所有这些都要符合在不确定和大规模的环境中实现战略对齐的意图。

- 这需要尊重框架。它要求团队尊重由领导设定的OKR所提供的方向。它要求领导者尊重各个团队找到有效方法来实现既定目标的能力,即使这不一定是他们实现目标的方式。

 

现在让我们转向我之前提到的特定的反模式,看看一些Scrum概念是如何帮助我们的:

 

 

 

 

你的团队的ORK是否有看起来更像是任务而不是战略目标?

 

从战术型的OKR后退一步,问问为什么?这里的意图是什么?我们想要完成什么?这才应该是你的目标。

 

就像一个好的Scrum产品待办列表/目标一样,一个专注于“为什么/是什么”的目标,会让团队根据在战壕中发现的现实情况来决定细节。多年来,我们在制作好的Scrum产品待办事项列表、Sprint目标和产品目标中所学到的东西,在制作OKR时可以派上用场。(嗨马OKR将Scrum与OKR集成起来,在OKR详情页需要制定里程碑,也就是Scrum的产品待办,这就“逼迫”着OKR不能制定成任务,因为接近任务性质的东西已经由里程碑区域负责了)

 

 

 

 

你的KR看起来像是可交付物的清单而不是结果?

 

这是一个不好区分、理解的概念。难道交付物不是我们想要的吗?在某些情况下,可交付物是可以的。但请记住——当我们试图实现使用OKR设定的那种目标时,我们经常在复杂的领域中操作。在这些环境中,我们并不一定知道什么可交付物会真正实现我们想要的结果!

 

我们可能会遇到这样的情况,我们完成了可交付物,但没有实现我们的目标(可交付物往往是你做出的东西/产品/服务,结果是你要达到的影响,你做出的东西/产品/服务,并不一定能达到你要的影响)……

 

因此,关键结果应该来自于这个问题的答案“我们如何知道我们真的实现了这个目标?”,它们应该参考一些基于证据的结果测量,或者至少是高度一致的领先型指标。

 

 

 

 

OKR过去常常对团队和个人进行微观管理,而不是赋予他们权力和能力。

 

我不能忘记很久以前有个客户告诉我:“说实话,我认为Scrum是一种微观管理我的团队的方法。”。他是唯一一个开诚布公地说出来的人,但我看到周围都有类似的行为。有些人意识到他们正在以这种方式使用Scrum。有些人就是无法摆脱他们的微观管理思维,通过这个棱镜来看待Scrum。

 

不幸的是,类似的模式也发生在OKRs上。领导者可能意识到,也可能没有意识到,领导者可能会也可能不会意识到,他们正在以一种过度约束团队和个人的“隧道”方式来设置OKR。

 

让OKR关注“为什么/是什么”,让KR关注结果而不是可交付物,这是授权团队解决问题的良好的第一步。

 

确保团队理解更宽广的使命/OKR,然后提出他们自己的OKR是重要的下一步。欢迎领导者询问,甚至建议团队设置什么样的OKR。但一个领导者最好不要过多地介入任何进一步的细节。

 

看看Scrum中类似的结构。Scrum团队让领导者作为利益相关者来参与产品目标的设定。有时候一个团队是围绕一个产品目标建立起来的。

 

领导者是可以对Scrum产品待办事项列表和团队完成的冲刺增量透明查看的利益相关者。冲刺评审是一个检查两者并提供反馈的机会,这些反馈将被考虑,并可能反映在影响未来工作的产品待定事项中。但是计划和监督工作是Scrum团队自己负责的。利益相关者信任并尊重Scrum团队创造价值和朝着目标前进的能力。他们让团队专注于工作。

 

在实施OKR时,应该考虑类似的结构。

 

 

 

 

太多的OKR的设定没有考虑到,在人们还要处理组织中发生的其他工作的同时,如何以可持续的方式实际交付这些OKR。

 

 

在Scrum中,团队在计算他们在Sprint中能做多少工作时,会考虑他们的历史吞吐量、他们的容量、他们的工作方式。他们计算在这个冲刺能做多少工作的预测。

 

同样地,当设定OKR时,参与实现这些OKR的人应该制定一套现实的、可持续执行的、在一个时间周期可以聚焦的OKR。

 

 

 

 

定义“OKR”,然后忘记它们,直到给它们评分的时候。(更糟糕的是,一些组织甚至不去认真考虑他们为OKR做了什么……)

 

 

OKR通常按季度或年度设定。在许多情况下,团队在一周又一周地计划他们的工作时,努力将这种高层级的指导牢记在心。

 

我们已经了解到,保持产品目标和产品待办事项列表的透明度,并始终可供Scrum团队和利益相关者掌握,有助于协调和考虑什么是团队关注的重点。

 

类似地,在OKR上下文中,OKR应该是透明的,并且对使用它们的每个人都是可用的。

 

如果使用Scrum来做这项工作,OKR实际上可能会成为产品待办列表中的待办事项,甚至在某些情况下成为产品目标。它们应该在冲刺评审中被考虑。团队应该问问自己,在OKR方面是否取得了适当的进展,工作或OKR是否有任何需要改变的地方。(嗨马OKR将Scrum与OKR集成起来,在周会/冲刺评审会,需要同时评审本冲刺完成的小目标和OKR,保障你不会忘掉OKR。)

 

 

 

 

处理OKR戏剧的第一步是认识OKR戏剧……

 

 

修理OKR戏剧并非小事。除了上面提到的反模式之外,还有其他反模式。为成功、健康地实施OKR创造条件,需要有重点的领导力,即使不是几年,也需要几个月的时间。这一切都始于识别OKR戏剧并将你的目光投向更好的东西的能力。

 

我们正在利用我们在敏捷/Scrum/Flow方面的丰富经验,帮助我们的客户超越OKR这个流行词,将OKR作为一种实现战略对齐的方式,利用经验主义、自我管理和基于证据的测量。如果你需要帮助来实现OKR的潜力,或者帮助你的团队识别OKR戏剧,有效地工作,也许我们应该谈谈……

 

本文由hmOKR.com翻译自agilesparks,转载请注明译文来自于hmokr.com

 

 

logo2x6.png
嗨马OKR软件是摩卡软件的自主版权产品。本网站中部分摄影照片版权属于Unsplash
© 2022, 摩卡软件

Search