勾哥：头铁的勾哥在平安夜放弃了约会，转而搞起 JVM 学习，最终被媳妇儿暴力问候。圣诞节，是必须要出去吃（pai）饭（dui）的。
时间宝贵，今天不搞技术，搞绩效。
我们很多团队，包括我司，都在搞 OKR，可能更多人都像我一样有困惑：大领导定好了 O，我怎么往下分 KR。今天分享的这篇文章就聚焦于 KR——「关键结果（Key Result）」。
本文来源于公众号：勾勾的Java宇宙（微信号：Javagogo），莫得推广，全是干货！
原文链接：mp.weixin.qq.com/s/OE1zTMUBm… 作者：Lisa
关键结果：用来描述目标达成的必要条件，它是具体的、可度量的。通过追踪关键结果的进度，我们能够知道目标的进度。
如何正确理解呢？首先要区分“关键结果”和“任务”。
关键结果 vs 任务
关于“关键结果”，有一个常见的错误认知，那就是把它和“任务”混为一谈。
关键结果是一种反馈机制，它告诉你，你是否正在接近你的目标，而任务则不一定能达到这样的效果。
举一个例子，春节期间，你因为暴饮暴食身材走样，迫切地需要在假期结束前恢复原来的身材。那许多人制定出来的 OKR 可能是下面这样的。
O：假期结束后恢复原来身材
- KR1：每周跑 5 公里
- KR2：每天摄入量减少 300 卡路里
- KR3：每天做 200 个仰卧起坐
- KR4：每天做 3 分钟平板支撑
这种关键结果，就是任务式的关键结果，也是书写关键结果时最常见的错误。而正确的关键结果应该是这样的。
O：假期结束后恢复原来身材
-
KR1：减少身体脂肪 5%
- 任务1：每周跑 5 公里
- 任务2：每天少摄入 300 卡路里
-
KR2：腰围减少 4 cm
- 任务1：每天做 3 分钟平板支撑
- 任务2：每天做 200 个仰卧起坐
对比一下，第一个例子里的关键结果，并不是结果，只是一些任务，完成这些任务不代表一定能实现目标。而第二个例子里的关键结果，则是结果，如果都能完成，我们也能确认目标实现了。
再举一个 K12 机构的例子，他们的目标是“成为最有影响力的 K12 教育辅导平台之一”。
而他们之前制定的 KPI 有一条是“完成 40 项初高中类教学教研项目”，完成这个 KPI 并不能准确告诉该机构是否正在接近目标。
修改成 OKR ，选择了课程访问量、销售额，以及与业界高声誉的合作方的合作数量作为关键结果，关键结果的达成显然可以更好地体现目标的进度。
所以说，关键结果能体现出目标的进度。而任务以及任务的进度，其实并不能正确、精确地体现目标的进度。
如果目标是我们要获取的最终价值，关键结果则是价值的子集。每完成一个关键结果，应该意味着你收获了目标价值的一部分，完成所有关键结果后，目标代表的价值也全部达成。
目标和关键结果，是我们要达到的目的地，而任务是到达目的地的手段。正确地区分关键结果和任务，是发挥 OKR 作用的关键。
理解了关键结果之后，需要在使用关键结果时关注另外两个问题，一个是关键结果的质量，另一个是关键结果的数量。
关键结果的质量
一个好的关键结果应该符合以下条件。
1.与目标实现有直接的因果关系
就像我在前面所举的例子，因为每周跑 5 公里，所以脂肪减掉 5%，从而身材会恢复到假期前的样子。在这一过程中，“身材恢复到假期前的样子”与“脂肪减掉 5%”是直接相关的；而与“每周跑 5 公里”则是间接相关的。
所以当我们写完关键结果之后，要回看一下，完成关键结果是否也意味着目标的进度有直接的变化？如果存疑，那么这个关键结果就不是一个好的关键结果，需要继续提炼。
所以当为目标创建关键结果时，你需要时刻思考这样两个问题：
- 我如何知道，我正在达到我的目标？
- 我如何知道，我没有在错误的事情上浪费时间？
2.有一定的挑战性
一个关键结果应该是有挑战性的。
要能适当地满足团队或个人的野心，并能鼓励大家尝试更多新事物，激发创造性思维。
同时挑战也不宜过大。
合适的挑战，是让团队或个人感觉稍微有点难度，但是还是有信心能克服它。它不应该让人因挑战过大而感到气馁，从而放弃。
有的书中观点认为，有挑战性的关键结果应该比正常水平能达到的结果高出 30% 左右，也有的书说团队或个人倾力能完成 70% 的目标的挑战性是合适的，这两种说法本质上差不多。
但我在辅导团队的过程中观察到，“恰到好处的挑战”对不同团队来说差别是巨大的，它取决于团队的工作性质，以及团队成员、企业文化等一系列因素。你需要经过多轮的观察和调整，才能基于经验找到适合自己团队的“恰到好处的挑战”。
最后，切忌以设置有挑战的目标为名，变相地给员工施加压力。
从心理学上来讲，“恰当的挑战”激发的是人们的内在驱动力，带来的是主动性和积极性；而“变相施加压力”的手段，则带来的是被动接受和消极抵抗。两种情绪作用于同样的目标，产生的结果显然是有很大不同的。
3.是可衡量的，最好包含量化指标
量化的指标让我们更容易追踪关键结果的进展情况。
如果关键结果中只写着“提高在线课程的销售量”，那么别人就难以直接评估它的进展。如果关键结果写成“卖出 1000 节在线课程”，而到目前为止已经卖出了 700 节，那么我们很容易知道关键结果完成了 70%。
以下是一些衡量标准模糊的关键结果案例，也是我们在实际操作中需要避免的。
- KR：在新品发布之前优先介绍给老用户和合作伙伴
- KR：帮助产品市场团队检查产品规范文档
- KR：添加一个好看的跳转页面
- KR：向用户宣讲新上线的课程
而以下则是一些可衡量的关键结果案例，你可以将其与以上的错误示范对比着看，体验它们的区别。
- KR：将每个活跃用户的平均周访问量从 X 提高到 Y
- KR：将单个客户获取成本维持在 Y 以下
- KR：提高参与度（完成完整档案的用户），数量从 X 到 Y
- KR：将客户回购率从 X 提高到 Y
关键结果的数量
很多时候，我们团队使用 OKR 的是想提高专注度。要想专注，就要尽量避免同时兼顾多重工作。
对于团队来说，一周完成 1 个关键结果是比较合理并可持续的速度。所以，一个团队的季度 OKR，它的所有关键结果数量最好不要超过 12 条。
换一种说法，如果你有两个季度目标，那么每个目标的关键结果则不超过 6 条；如果有三个目标，那每个目标的关键结果则不超过 4 条。这两种情况在实践中都是合理的。
如果季度 OKR 的关键结果的总数超过 12 个，要么就要试图兼顾过多工作，使得团队难以集中精力，最终反而影响效率；要么就是工作量并不大，但是关键结果分解得过于细化，导致数量看起来很多。
但这样只会耗费关键结果的分解和追踪上的时间，并不会带来明显的好处。
想把关键结果限制在有限的条数内，以达到聚焦的效果并不是一件简单的事。
我在辅导团队制定季度 OKR 时，经常发现团队会列举非常多的关键结果，而且每一个关键结果似乎都有必须要达成的理由。
然而在时间和资源有限的情况下，过度的求全责备反而是保持专注和提高效率的敌人。要想专注，就意味着对一些事情说“不”。
如果团队实在觉得很难舍弃任何一个关键结果，我会为他们推荐 MoSCoW 优先级排序法。
-
Must have：必须有。如果不包含，则目标肯定不能完成。
-
Should have：应该有。这些结果很重要，但时间、资源紧张的情况下也可以放弃。
-
Could have：可以有。重要性不是那么高， 但实现了可以给目标增光添彩。
-
Won’t have：这期不会有。考虑放到下期或更远的未来。
通过该方法将关键结果排序，按照优先级从上至下截取合适数量的关键结果，其余关键结果作为备份，当主要关键结果完成后仍有时间的情况下，可以考虑从备份关键结果中选取合适数量的关键结果继续完成。
通过这样的做法，我们能最大程度上帮助团队实现了专注度，并且始终优先交付最重要的事，从而提升了效率。
掌握了前面提到的“数量”和“质量”相关的技巧，就可以写出非常不错的关键结果来了。除了这些常见问题外，在辅导组织实践 OKR 的时候，我还常被问到以下两个问题。
谁来制定关键结果？
OKR 中的目标是源自公司战略的，但是关键结果最好由经理、团队成员，以及其他每个和目标相关的人一起协商制定的。
协商制定有两个好处，一方面让我们不会漏掉关键结果。
举个例子，开发一个手机 App，它应该是能满足某种用户需求的、用户体验是友好的、功能是稳定的。这三方面是衡量它成功的必要（Must have）条件，所以这些必要条件需要产品经理、设计人员、技术人员三种角色共同定义，缺一不可。
另一方面，协商制定 OKR 的过程可以增强人们的参与感，参与感是 OKR 激励员工的一种方法。
关键结果与 KPI 指标有何不同？
关键绩效指标（KPI）和关键结果都是可量化的指标，很多组织之前使用 KPI，在引入 OKR 后，发现很多的关键结果与原来的 KPI 指标类似，因此有了困惑。
关键结果有时候可能与 KPI 的某些指标相重合，但是二者有着本质的区别。
-
关键结果一定是达成了某种结果，该结果是有价值的，能用来验证目标的进度，人们为了实现关键结果，可以制定任务并调整任务。
-
而 KPI 的指标更类似于任务，而且指标一旦制定，就轻易不能改变。这种系统下，人们对任务负责，以完成任务为目标。但是任务的结果是否对公司产生最终价值，人们则很少考虑，他们认为那是制定任务的人的责任。
本质上来讲，KPI 是一种静态思维。KPI 诞生的时代是行业成熟、需求相对稳定的时代，业务逻辑和业务结果是可以预测的。管理主要就是计划和控制，人要按照组织要求来运转。
OKR 则是一种动态思维。OKR 所对应的环境，是动态变化的，目标相对明确。但是执行过程中的方式方法，以及可产生的结果，有时候无法准确预测，需要经过实践去验证和调整。
这便是两者的根本差异。
其实业务需求的确定性越高，使用 KPI 和使用 OKR 的区别也就越小，这是一种正常的现象。 但是如果业务需求的不确定性高的情况下，把 OKR 制定得像 KPI，则是一种完全错误的做法。
欢迎大佬们关注公众号 勾勾的Java宇宙（微信号：Javagogo），拒绝水文，收获干货！
