科技界流传的 OKR 系统有用吗？

在过去5年中，我工作过的大多数公司都会使用目标与关键成果（Objectives and Key Results，简称OKR）系统。这个系统诞生于70年代，但是直到最近才受到了Google欢迎，并在科技界流传开来。

这个系统本身很简单：公司负责定义多个目标，而且每个目标都有一个或多个可衡量的关键成果。这些关键成果旨在跟踪目标的进展情况。

例如：

• 目标：提高客户回头率

• 关键成果#1：终身客户价值从$N提高到$N + 5

• 关键成果#2：客户流失率降低10%

我工作过的大多数公司通常都会制定3-5个OKR。

1·OKR对公司有何好处？

OKR的初衷基本上是让公司里的每个员工都有一些直接性的、非常清晰的、可衡量的目标。团队的一切工作都应该与为特定的OKR服务。从理论上讲，这意味着所有人都朝着同一个方向划船。

在某些级别和某些方面，OKR能发挥很好的作用。对于领导团队来说，通常这似乎是一个很好的机制。它可以让所有领导都达成一致，并为每个季度提供一个很好的起点。

然而，当开发团队做出决定时......

在独立团队的决策过程中，OKR并没有用武之地。——Joe Cannatti

最常见的模式如下：

• 团队开始讨论积压的工作，看看哪些需要处理。

• 他们讨论了每一项工作，并制定出了一个按照优先顺序排列的基本清单。他们知道短期内都他们都顾不上剩下的工作。

• 他们遍历一遍清单，并为每个任务/工作项添加标签，指明哪些工作与OKR的关系最为紧密。

• 在大多数情况下，通常他们无需太费神，就可以为每项工作分配一个OKR。

等一下……这个顺序是不是颠倒了？

难道我们不是应该首先通过OKR提出想法吗？为什么现在反过来把这些OKR放入了相应的工作中呢？

然而，我认为这就是开发团队的做法。

2·积压的工作项

在我看来，开发团队采用这种方式的原因通常在于，他们有大量积压的工作需要处理。这些积压的工作大部分都是根据当时的OKR制定的。

因此，在当时的OKR下，这些工作都是有意义的，我们只需要将我们已有的工作融入到OKR中。

这有什么不对吗？

是，但也不是。

在我看来，最大的问题在于，开发团队感受不到实际的工作与OKR之间的联系。例如，在我写这篇文章的时候，我可以告诉你这个季度我们打算尝试的每个项目，但我甚至无法说出本季度的OKR是什么。

我们能够让所有工作都符合OKR，却从来不觉得OKR能够指引我们的工作。也许这没问题，但对我来说，OKR并不是很有用。我认为OKR给领导们提供了一个理由，让他们宣称每个员工都朝着相同的目标努力，但我认为这并不会让开发团队相信这一切是真的。

3·改善OKR运作方式的想法

关于如何让团队在下一个计划周期中更好地工作，我有以下几点想法：

放弃积压的工作

当开始新一轮的计划时，请考虑放弃积压的工作项。不要以团队以前定义的工作为起点，而是应该从头开始。

以OKR为出发点，看看团队能否提出以前没想到的一些想法。或者，看看他们是否能够用有意义的方式重新构建他们现有的想法，让他们真实地感受到OKR的作用。

这不是一件容易的事情。你需要让所有人都远离以前积压的工作，但我认为最终你们可以取得更好的成果。

通过OKR来推动每周的团队会议

在每周的冲刺计划以及其他签到的会议上，以OKR为起点。

一般来说，这些会议会自然地遵循你们正在进行项目和任务所塑造的模式，但是你也可以将讨论引回到OKR上。