研发团队如何使用OKR

研发团队如何使用OKR

閱讀本文約花費: 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。

Rate this post

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注