閱讀本文約花費: 18 (分鐘)

OKR简史

OKR脱胎于大名鼎鼎的管理大师彼得.德鲁克（Peter Drucker)的MBO，即目标管理框架。这个框架的设计，来源于大家都非常熟悉的一句话：

如果你想要造一艘船,先不要雇人去收集木头,也不要分配任务,而是去激发他们对海洋的渴望。

安德鲁.格鲁夫(Andrew Grove)对MBO的理念非常欣赏，率先在Intel实施了这套框架。 在1987~1998年任CEO期间，把MBO作为管理哲学的关键组成部分。Andrew认为，一个成功的MBO系统，需要回答两个问题：

1. 我要去哪儿？ Where do I want to go? (这既是OKR中的Objective，目标)
2. 我得如何调整节奏以确保我能够达到那里？ How will I pace myself to see if I’m getting there? (or Key Results.)”

第一个问题的答案，对应这OKR中得Objective， 即目标。 而第二个问题的回答，亦即是设置里程碑，即OKR中的Key Results，关键结果。 Andrew成功把Intel发展为全球微处理器的霸主。 而真正把OKR发扬光大的是Google公司。 Google在创建之初就开始使用OKR，并把它作为公司文化的一部分。 随着它在Google的成功实践， OKR逐步开始风靡全球。 这里有一个很长的使用OKR的知名公司名单， 有大家熟知的LinkedIn，Amazon，Netflix等公司。而在国内也有公司也在用OKR。百度这两年也在从KPI转向OKR。 当然，实施OKR最为成功的，当属今日头条的母公司，也就是字节跳动公司。 2017年张一鸣在源码资本的会议上，讲述了如下观点：

我们让管理层的OKR对下属员工保持公开，让大家知道你在做什么，为什么在做这个事情，其他部门的人在做什么。OKR的制定过程也不是自上而下的分解，而是大家互相之间自己对齐。看一下上级的OKR，看一下别的部门的OKR，看一下同级的OKR，了解目前公司最重要的任务是什么，这个季度最重要的任务是什么，我做什么能够帮助他们。季度会也是尽量让相关人多参与，并不是一个非常小范围的高管会。我们还会经常举办CEO面对面，在这个会上回答员工提问，让大家了解公司进展。

“公开”“对齐”“非自下而上”， 这些关键词，对厌倦条条框框的软件工程师而言，无疑是有巨大吸引力的。 关于在公司、部门层面如何制定OKR，不少书籍都有很详细的描述。我比较推荐《OKR：源于英特尔和谷歌的目标管理利器》这本书，把OKR的来龙去脉和制定细节讲的非常具体。 可是，落到研发层面来制定OKR的时候，我们经常碰到的问题是： OKR和KPI有什么不同？既然研发工程师是在完成产品经理的目标，那两者的OKR是不是一样就行？

成败KPI

国内大部分公司实施的还是KPI(Key Performance Indicator)，即常说的绩效考核。 KPI着眼于评估当前项目或者活动的成就。 KPI也有不少类别，或者说门派，每个公司根据自己的领域以及管理上的成熟度会选择合适的KPI类别。 举个例子，比如某公司，以前都是线下销售，在线商品展示。 最近打算搞在线购物。 产品经理N负责这个项目的产品，开发人员M参与某个模块，比如收银台模块的开发工作。 针对这个事件，KPI还是比较容易制定的，产品经理可以定义如下KPI：

2019.4.1日 完成在线购物功能模块上线。

此后，这KPI被按模块来分解，收银台、账户账务、渠道对接（微信、支付宝）、风控等模块。负责收银台的开发人员M，收到的KPI也比较简单：

2019.3.20日 完成收银台模块的上线。

看起来这似乎很完美。一项大工程被分解，任务落实到每个人头上，事事都有人在负责。 但实际执行中，总会有各种意外。

1. 开发人员M是一位牛人，收银台模块对他来说，没有什么难度，加上自己喜欢加班，周末也都在干活。 3月10日左右，就把事情做好了。然后呢？ 如果开发人员B负责的模块碰到困难有延迟，M是否应该出手相助？ 那这一块的KPI，算M的还是算B的？ 领导选择衡量什么指标，员工就死盯着那些指标，如果这些指标并不能为最终目的服务，公司整个方向就会跑偏！
2. 在渠道对接上，选择微信和支付宝，仅仅是产品经理拍脑门认为这两个应该是主流支付方式。而实际上，这个产品的单笔订单额高，用户群更习惯于通过银行卡来执行大额支付。 开发人员B发现了这个问题，但对接这两个支付方式的任务已经落到KPI了。KPI反应迟钝，难以适应市场变化。如今，市场要求更多的个性化产品，需要灵活直接对接市场才能取胜，以往的KPI体系很容易显得迟滞和笨拙，也容易牵扯过多的注意力在僵硬的目标上，并扼杀员工的贴近现实要求的主创精神。
3. KPI是自上而下来制定的，以确保公司、部门或者团队的目标是一致的。 对员工来说，缺乏参与感，更缺乏认同感。 还有一个问题，在制定KPI方面，到底是领导专业，还是员工更专业？
4. 在实施KPI的公司，我们经常听到的一句话是： 过程不重要，我们看重结果。 这导致有些员工为完成KPI不择手段。在使用编码行数来统计工作量的公司，直接复制开源软件代码来充数的，不在少数。这往往和企业愿景背道而驰。过程不到位，结果必然有问题。

关于KPI的问题，可以列出很多很多。绩效与目标计划管理脱节、和价值导向脱钩，只关注结果，而忽视过程，忽略结果获取的正义性，必然导致目标跑偏。 而OKR要解决的问题，是弥补公司战略和价值观、个人追求和绩效之间的空隙，使得组织的运作沿着正确的轨道前进。

OKR是什么

在《OKR：源于英特尔和谷歌的目标管理利器》这本书中，OKR被定义为：

OKR是一套严密的思考框架和持续的纪律要求，旨在确保员工紧密协作，把精力聚焦在能促进组织可成长的、可衡量的贡献上。

• 严密的思考框架： OKR是一套框架，而不仅仅是几个冰冷的指标。执行人员需要不断的思考它的涵义，并严谨、规范地执行；
• 持续的纪律要求： 这就需要不断（以双月或者季度为单位）地评估OKR达成情况、总结经验教训，并刷新OKR。 -确保员工紧密协作： OKR必须被设计为最大化协作，并在组织内部对齐。
• 精力聚焦： OKR不是任务清单，不能涵盖所有的任务，它的主要目的是用于识别最关键任务的业务目标，让执行者知道做什么和不做什么。
• 做出可衡量的贡献： 也就是要求，所有的结果必须是定量的，避免模糊、主观的描述。
• 促进组织成长： 判断OKR成功与否的最终标准，还是的用结果说话。

这就是OKR定义的六大要素。 那具体来说，怎么订制目标和关键结果呢？

目标

目标是驱动组织朝期望方向前进的定性追求的一种简洁的描述。 主要回答：我们想做什么。 目标设置要求简洁、定性、在给定周期内是可以完成的。 注意，目标是定性的，不是定量的。 从软件项目角度，一般目标的安排分为两种：

1. 新功能或者新项目开发；
2. 现有功能升级改进。

对新项目/功能的开发，目标设定一般比较简单，可以参考的目标案例：

1. 完成收银台功能上线；【可以】
2. 完成手机端收银台功能上线，支持主流支付渠道。【略好】
3. 实现一个简单易用的收银台来提升转化率。 【推荐】

目标应该是积极向上，能够鼓舞人的，同时又要强调关注的价值。 在设置目标的时候，不妨不断的询问自己： 做这个事情的目的是什么？ 它和公司的战略是什么关系？ 这问题的回答，有助于制定一个符合公司战略方向的目标。 如上案例，都是要完成收银台功能，第3个目标，明确把要做这个事情的直接目标写起来，这样在确定关键结果，或者其他决策的时候，可以以这个objective作为准则来判断其优先级以及是否有必要。 对于功能改进的，可以参考的目标：

1. 提升收银台的渲染速度；【可以】
2. 提升收银台的渲染速度以提升转化率。【推荐】

关键结果

关键结果是对目标达成情况的定量描述。 注意，目标是定性的，而关键结果是定量的。 比如对 实现一个简单易用的收银台来提升转化率 这个目标而言，这里的描述有不少模拟两可的地方，比如 简单易用、提升转化率等。这些元素的定量化，就通过关键结果来描述。 比如针对简单易用，可以通过多种途径来衡量。 一种方法是看客户在这个页面的跳出率，这样对应的KR就是“客户在收银台的页面跳出率低于千分之一”。 或者在这里发起在线求助的客户量，对应KR是”发起在线求助的客户量不超过10位”。 而在提升转换率上，如果没有对比数据，可以简单定义一个转化率目标，如“转化率超过20%”, 如果有对比目标，则相对目标来制定“转化率相对于xxx提升20%”，诸如此类的。 当然，这些指标主要是产品角度来提的。 那除了产品目标外，开发工程师还可以制定那些关键结果？

• 工程目标
  • xx月xx日完成预定义功能功能上线，无重大故障
  • 系统访问量从xxx/天 提升到 xxx/天
  • 订单量从xxx/天提升到xxx/天
• 质量目标
  • 系统上线无重大线上事故
  • Bugs率从xx%减少到 xx%；
  • Sonarqube Bugs 从 xx 减少到 xxx；
  • Sonarqube单元测试覆盖率 从xxx 提升到 xxx ;
  • Sonarqube Bad smell 从 xxx 减少到 xxx
  • xxx接口响应时间从xxx 减少到 xxx；
  • xxx接口每秒支持的访问量从 xxx 提升到 xxx ；
  • 重大Bug不多余X个，普通Bug不多于XX个。
• 影响范围
  • 客户投诉从xx起/周 降低到 xxx起/周
  • 客户满意度从xxx提升到xxx
  • 系统日均访问量从xxx提升到xxx
• 性能目标
  • 接口响应时间控制在 xx毫秒以内；
  • 接口相应时间从XX毫秒减低到XX毫秒。
  • 页面渲染速度从xx毫秒减低到xx毫秒。

从哪些角度来定义关键结果，需要和产品经理一起协商对产品成功的最重要的因素。 一般来说，每个Objective的KR控制在3~5条左右。 过多的KR会使得目标分散。 接下来的问题是，KR的值应该如何设定？ 比如我们希望提升一个接口的性能，现在这个接口响应时间100ms。从需求情况来看，提升到50ms是可以基本满足需求的， 在技术上做简单的改进即可达到。 技术人员在评估后，认为在现有技术上最多就能提升到40ms的。 产品也认为，40ms是可以接受的，但30ms的话，我们就会领先客户。 那最终KR应该定多少？ 30ms或者更低。 这就涉及到KR设置的一个原则： 要设置一个需要跳起来才能达到的目标，而不仅仅是踮起脚尖就能达到的目标。KR的制定，要激发人的创造力和激情，不断超越自己。 这样，一个典型的研发研发类型的OKR：

Objective： 实现一个简单易用的收银台来提升转化率
KR1： 客户在收银台的页面跳出率低于千分之一
KR2：上线后无重大Bug，普通Bug 少于2个
KR3： 页面响应时间控制在30ms以内

评估

OKR的评估周期多长比较合适？ 一般是2个月或者3个月（1季度）。对于迭代快的互联网公司，2个月是比较好的一个选择，和大部分项目发版的周期相符。 每2个月需对上一个周期的OKR进行评估，也就是打分，总结，对下一个周期的OKR做制定。这里重点说OKR的评估。知道怎么评估OKR，就能够更了解如何制定OKR。也即是KR必须是可以评估的。 首先说对KR的评估，一般来说，我们对每一项内容，使用0-1的分数来打分。有几个典型的分值：

• 1.0 ： 即实现了这个有野心的目标；一般来说，这个目标基本是很难、不可能实现的。 需要通过天才的努力才能搞定的。比如上述的30ms， 不仅仅需要依赖团队的努力，还需要推动其他团队的帮助才能达到。比如，推动基础设施团队把数据库的磁盘全部升级为SSD来提升数据库的访问性能，从而提升接口的性能。
• 0.7： 虽然很难，但还是可以达到的。比如上述的40ms，技术同学评估后认为还是有可能达到的目标。
• 0.3： 在现有基础上，正常地进行即可达到的目标，比如上述的50ms

当然，我们还需要对每个KR设置权重，最后计算出这个objective的分值。 那如何评估Objective的分值区间？

1. 如果你大部分的Objective分值都在0.7以上，那需要考虑目标是不定的太低了？
2. 如果大部分Objective分值都在0.3以下，是不对自己过于自信了？
3. 大部分Objective应该在0.3~0.7之间。

考核

再次强调，OKR不是KPI，不作为考核的依据。 它可以作为考核的参考，但不能被列入考核指标，否则会影响OKR的制定。

当然，不是所有的公司都适合引入OKR。一个公司或者团队也不可能引入OKR即可变成谷歌或者今日头条。 它需要全公司范围的支持，需要持之以恒的执行，需要全员对规则的重视和尊重。只有负责人能够亲自参与、能够把只有0.3分的KR在全公司公开，才有可能成功实施OKR。