JavaDriver JavaDriver
首页
  • 基础
  • 并发
  • JVM
  • 设计模式
  • 计算机网络
  • 操作系统
  • 数据结构
  • 算法
  • MYSQL
  • REDIS
  • Netty
  • Kafka
系统设计
非技术
关于
  • 分类
  • 标签
  • 归档
GitHub (opens new window)

YoungAnn

西二旗Java老司机一枚 致力于社会主义添砖Java
首页
  • 基础
  • 并发
  • JVM
  • 设计模式
  • 计算机网络
  • 操作系统
  • 数据结构
  • 算法
  • MYSQL
  • REDIS
  • Netty
  • Kafka
系统设计
非技术
关于
  • 分类
  • 标签
  • 归档
GitHub (opens new window)
  • 非技术问题
  • 关于空降兵的思考
  • 能力差的人都是什么样的?
  • 如何提升技术水平?
  • 上级让下级干活的4中方式
  • 正确认识Backup
  • 对事不对人 vs 对人不对事
  • 关于如何写OKR
    • 前言
    • 提前退休的Case
    • 各团队如何写OKR
    • 其他
  • 非技术
YoungAnn
2022-12-09
目录

关于如何写OKR

# 前言

接触OKR有几年了,对我自己来说,每个季度或双月都会写OKR,也看了无数次别人写的OKR,但我一直没完全搞懂该怎么去写OKR,所以我每次写的OKR都不一样。最近,我又有新的认识了,用下文记录下来。

# 提前退休的Case

先来个故事吧。故事主人翁叫X姐,假设她在公司身居高位,事业有成,家庭和睦,有老公有女儿。X姐给自己定了个目标:40岁财务自由,提前退休。

一起分析下:财务自由后,就能退休了。但要实现财务自由,需要有一大笔钱,并且投资理财的被动收入大于日常开销,还需要家庭稳固,能抵御家庭风险,比如家人生大病等。

可以轻易写出OKR来:

Objective:40岁财务自由,提前退休

KR1. 赚钱,赚到x千万(或x亿)

KR2. 学习理财,平均年化收益达到 y%

KR3. 家庭稳固,能抵御风险

KR1和KR2,X姐自己就能搞定,但KR3需要家庭成员配合。接下来,可以把KR3拆解成详细的Todo list,或者拆成小目标,可以为每个家庭成员制定一个小目标,也可以写成OKR。

例如,X姐父母(下文称为老人)的OKR可以这么写,

Objective:保持身体健康,减少生大病的几率

KR1. 每天锻炼身体一个小时

KR2. 每年定期体检

KR3. 配置合适的保险,比如重疾险等

如上,这么写OKR,似乎就是我们心目中的理想OKR。

这个Case中,X姐是业务方,俩老人其实是支持方,支持X姐的业务,假设没有他们的支持,X姐的目标可能实现不了。

问题来了:请问老人的目标是”40岁财务自由,提前退休“吗?很明显不是!那他们需要对X姐的目标负责吗?也不用,他们只需要自己身体健康就行了,至于X姐能否实现财务自由,他们不用负责,也决定不了。也就是说:OKR中,你要对Objective负责!

请问:老人的O可以定成共建财务自由目标吗?例如,Objective:【与女儿(业务方)共建】40岁财务自由,提前退休。答:似乎可以这么写,但是有点牵强,这么写,文案确实非常漂亮。

# 各团队如何写OKR

上述例子中,X姐属于业务方,业务团队;老人属于支持方,支持团队。每个业务方的支持团队可能有N个,每个支持团队可能支持N个业务方。

我们能看到如下事实:

  1. 业务方能清晰制定出目标并拆解
  2. 支持方必须依赖业务方拆解的小目标

换句话说,支持方的目标可用一句话来总结:支持业务团队的工作

综上,OKR撰写的过程是:

第1步:业务方制定业务目标,撰写OKR,并拆解成各个支持方的小目标

第2步:支持方根据小目标制定OKR,并进一步拆解成更小的目标,给下游支持方

第3步:下游支持方重复第2步,层层拆解,直到全部拆解完成

(当然,在这个过程中,业务方与支持方、支持方与下游支持方需要提前沟通,盘点资源,看看目标能否实现,若不能,可能会纠正目标。业务目标,可以是老板指定,也可以是部门负责人高瞻远瞩制定,也可以是收集部门内大家的意见后决定,这是另外个话题,本文不做讨论)

以咱们所属的运营研发部为例,来看看各个团队如何写OKR。为了简化模型,假设只有运营部一个业务方(实际上有很多个)。

各方关系如下图:

img

业务方只有一个:运营。

其他团队,产品、设计、前端、后端、QA、数据等团队,其实都是支持方。但由于产品是业务方的接口人,会根据业务需求来设计产品原型,排优先级,所以产品属于一级支持方。设计、前后端、QA、数据等团队属于二级支持方,支持产品团队的工作。也有三级支持方,比如运维、行政、HR等团队。

对了支持方来说,除了支持业务发展,也有些自身能力建设的工作,比如团队建设、服务监控、性能优化、中台抽象等等,这些工作是支持方主R,在这些事上,支持方自己就成了业务方,需要下游团队的支持。

有了对各团队关系的理解,OKR就比较好写了,模板示例如下:

运营OKR:

O1. 打南方,南方各省月活增长xxx

O2. 搞推广,媒体曝光增加yyy

O3. 促生产,生产者产量提升zzz

产品OKR:

O1. 支持运营团队工作

O2. 现有产品优化

O3. 团队建设

各研发团队OKR:

O1. 支持产品团队工作

O2. 系统优化,提升服务鲁棒性

O3. 团队建设

设计团队OKR:

O1. 支持产品团队工作

O2. 团队建设

上面是以运营研发部为例,其他团队依然适用上述模型。

# 其他

有了上述的建模,很多问题就比较好回答了。

\1. OKR可不可以改?

答:不少人认为OKR是严肃不可以更改的,其实不然。对于业务方,制定业务目标,就应该全力以赴去实现,根据实际情况酌情调整;对于支持团队,业务目标变了,就应该立刻变化,而不是认死理,认为该一成不变。

\2. OKR中”支持xx团队工作“,不好听,不好看,对团队成员心理可能有影响,怎么办?

答:文案上美化下,建议把业务方拆解出来的小目标作为O,或者把业务目标复制过来,加上【与业务共建】文案。但无论怎么优化文案,本质上支持。

\3. 研发团队难道都是支持团队吗?

答:不是。风控、推荐等团队对业务结果负责,他们自身就是业务团队。

编辑 (opens new window)
上次更新: 2023/02/17, 17:03:51
对事不对人 vs 对人不对事

← 对事不对人 vs 对人不对事

最近更新
01
电商-商品系统设计
12-17
02
对事不对人 vs 对人不对事
12-09
03
正确认识Backup
12-09
更多文章>
Theme by Vdoing | Copyright © 2022-2023 YoungAnnn | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式