okrs是什么(OKRs 和 KPI 的区别到底在哪里)

Q1：OKRs 和 KPI 的区别是什么？

这个问题我还是有些发言权的，因为我在微软的时候，有一项工作是和 Global Reporting Team 对接，进行 KPI Report 在大中华区招聘团队的落地。每个月我要提交我们的数据，并且能看到所有国家地区的 KPI 完成情况的汇总和排序。

有 KPI 相比于什么都没有肯定是更好的。至少我们知道要关心哪些指标，这些指标作为一个明确的准则，可以来帮助我们优化自己的工作。

但 KPI 在当时确实没有满足我的工作需求，我经常干的事情就是不断地追问为什么。

KPI 里有一条我很感兴趣，就是新员工入职两个月内的离职率。设置这条 KPI 的目的是为了保证招聘质量。

如果只盯这个 KPI，其实有很多办法去实现它，比如，我可以设置一笔入职 3 个月后才能发放的入职奖金，我还可以设计周期较长的入职体验来降低 2 个月内考虑离职的可能性，甚至我还可以靠个人关系请求同事不要影响我的 KPI——显然，这些办法看起来都不能保证招聘质量。在 KPI 体系里，其实不是没有 O，而是 O 被隐藏了，如果没有人知道或者没有人去沟通，这个 O 很可能就不能被实现。

另外一个我关心的问题是：「为什么所有国家和地区要使用一样的 KPI？」 比如，KPI 里有一个最常见的指标——招聘完成率。假如是在业务成熟稳定、招聘量不大的国家，填补岗位是为了填补工作量，而不是要解决业务的难题，那么招聘完成率是个合理的指标。

但当时中国的部门在业务和团队上都处于高速发展。一方面业务是需要一些关键人才的；而另一方面招聘部门每个人的招聘压力非常大，如果为了让招聘完成率的 KPI 更好看，很有可能的做法是先把量大好招的岗位先填了，但这又不一定能最优地满足关键人才的招聘。所以，虽然 KPI 看起来和 OKRs 中的 KR 很像，但由于 KPI 的 O 是隐藏的，我们往往很难准确地判断 KPI 的设置是否是对的。

那么，OKRs 和 KPI 的区别，就是多了一个 O 吗？KR 相当于 KPI 吗？并不是。

我们思考 OKRs 的过程，不是先去想 KPI，而给它按一个 O。是要先定下 O，再从 O 出发去想，描述这个 O 实现时的 KR 是什么。

以刚才「新员工入职两个月内的离职率」这个 KPI 为例，我们试写一个 OKRs。

Objective：保证新员工质量满足公司发展的需求

• KR：入职一个月内，新员工能够按照预期职责开展工作，并表现出积极的工作态度

• KR：入职后的第一次绩效考核中，新员工符合绩效标准

• KR：入职后的半年里，新员工体现出来的行为符合公司的文化

这里我们会发现，KR 不是单一的，而且和之前的 KPI 不一样。还有很重要的一点是：KR 并不一定是个量化指标，它只需要「有时间限制」、「可衡量进度」即可。

Q2：什么情况下适合用 OKRs，什么情况下适合用 KPI 呢？

OKRs 和 KPI 本身都是工具而已。工具的最大价值在于提高效率。

那么，首先我们要考虑的是：公司有没有「目标管理」上的效率问题？比如，很多人做的事情跟公司策略没关系；每个人做了很多事情，公司业务却没有进展；员工不知道自己做哪些事是有用的，要做到什么程度是有用的。这些都是「目标管理」上的效率问题。有效率问题，引入工具就会有所帮助。

从前面一个 QA 里，我们可以看到，OKRs 相比于 KPI，提供了一颗清晰可见的北极星，帮助我们尽量专注并且不跑偏。长期来看，OKRs 可以避免更多执行中的弯路和无用功。

但另一方面来讲，工具的使用也存在时间成本。OKRs 使用的时间成本，在引入初期一定是比 KPI 高的，因为它要求思考的过程更细致、沟通的过程更充分。

所以，当业务非常成熟稳定的时候——预期的结果是确定的，实现结果的方法也是确定的，只要将既定的方法执行到位就一定能达到预期的结果——这时候，依靠经验制定的 KPI 大体是不会错的，使用 KPI 其实就能发挥很好的作用了。使用 OKRs 的效率反而可能没有 KPI 高。

相反的，如果我们在做一件不确定性很大的事，或者解决问题的方法不确定的时候，比如做创新业务的创业公司（e.g. Google），探索新方向的大公司（e.g. Intel），KPI 很有可能会把我们带偏，或者约束我们的创造力。这时候我们就应该考虑引入 OKRs。

Q3：OKRs 和研发流程的管理会有重复或者冲突吗？刚开始使用会不会带来很麻烦？

有不少科技公司在咨询时会提到，产品和技术团队本身已经有一套管理研发项目的流程了，使用 OKRs 对他们来说是不是要使用两套并行的工具。

这里需要指出的是，研发流程的管理，是过程管理，而 OKRs 是目标管理。简单的说，OKRs 决定了哪些工作应该进入研发流程，以及研发流程的周期长短，而不会干涉研发流程中的管理。

至于引入 OKRs 会不会很麻烦。我想必须搞清楚的一点是：思考目标是什么，拆解目标，按照目标优化工作，评估目标实现的进展，是本来就应该做的事情，而不是因为我们要使用 OKRs 才要来做的事情。OKRs 作为工具，是来帮助我们提升做这些事情的效率的。

如果我们认为做这些事情是一种「麻烦」，那么当然，引入 OKRs 会很麻烦。如果我们想要把这些事情做好，那么引入 OKRs 就是一件事半功倍的事情。

我想引用之前去华为做分享的时候，华为的一位经理说的：

「OKRs 并没有增加我的沟通成本，它反而大大减少了我的沟通成本。因为我一旦制定好、沟通好 OKRs，我的团队就能主动地、高效地跑起来，不像以前需要在执行的时候反复沟通。」