环界云计算是一家做开源的公司,核心产品是 sealos 基于 kubernetes 云内核的云操作系统发型版。 laf 是我们开发的函数计算项目。 欢迎大家赏星~
下面开始介绍我们是如何实践 OKR
这是整个公司长期做的事的总结抽象和提炼,为 OKR 的制定提供战略指导意义,OKR 制定周期大概三个月,这三个月中的目标制定的依据是什么?所以一句话定义公司长期要做的事就非常重要。
例子:sealos 是以 kubernetes 为内核的云操作系统发行版,让云原生简单普及
团队所有成员都必须把这句话刻在脑子里。
流程是组织内每个人先写自己关于公司下个季度 OKR ,然后对焦,确定了公司的 OKR 之后再拆解到组织中每个人。
OKR 是什么意思 O 目标:可以抽象概括一点 KR 关键结果:衡量目标是否达成的几个关键点
很多人写一大堆目标给老板看的觉得我厉害吧 充实吧 其实犯了 OKR 大忌!
比如在参加奇绩创营的时候我们定的 OKR:
O : 完成 [sealos]( https://github.com/labring/sealos) 市场匹配验证
KR1: 完成 3 家企业客户签单,合同额 100w
KR2: 函数计算 500 注册用户
KR3: github star 总数突破 12k
再看下我们执行结果怎么样:
完成了 1 家签单,45w 合同 (有点定高了,高估了自己,没关系)
完成 500+ 注册用户(最终做到了 600 用户,定低了,应该定 1000 用户)
github star 11k 的样子 (完成 70% 80% 正合适)
高估或者低估自己是很正常的事,多实践就会越来越准确。 很多人担心定高了完成不了怎么办?从而不敢把目标定高,这里就误解了 OKR 。
重点:** OKR 用来帮助聚焦的而不是考核工具 **
最重要的目的首先是团队目标对齐,其次是自己在工作的过程中知道什么重要什么不重要。 考核是需要制定 KPI 的。
所以我通常是感觉自己能做到 100 ,那就定到 150 的样子,不要不敢定,别搞大跃进异想天开就行。有些目标努力一下还是有可能的,比如 laf 的小插曲,我们定的目标是月增长 50%,结果最终做到了 150%,严重低估了自己的实力。
还有就是看到一个目标上来就觉得吓人,先否定一下不可能完成,这也是不对的,应该先思考怎样才能完成,论证一番,想想路径,最终再对焦的过程中再看是不是真定高了。
这是一个极其重要点,很多了定完 OKR 往那一扔就不管了,那就废了。 两周这个心跳节奏非常好,因为通常取的一些可观的小进展一周时间太短,一个月时间太长。
对焦需要做三件事:
OKR 是否需要调整
先看组织的目标是否需要调整,这个过程也会加深团队成员对组织目标的印象。 再看个人的目标是否需要调整,防止做了三个月才发现自己目标都不对。
如我们的目标:
O : 打造公司雏形
KR : 完成天使轮融资,xxxxw xxxxw 人民币
KR : sealos & laf 发展 4 名外部活跃贡献者, 公司招聘 5 名优秀核心员工
KR : 签约 x 家企业客户
O : sealos 公有云上线
KR : 100 名注册用户,启动 30 个 sealos 集群
KR : laf 突破 1600 注册用户
KR : github star 总和突破 15k
就两个目标,一是打造公司,一是打造产品。被划掉的 KR 就是在双周对焦时调整过来的。 比如我们一开始的融资目标比较高,后来觉得现阶段市场行情太差,还融那么多会丧失太多股权,最终决定少融,这样随着外部市场变化而变化。
关于 OKR 的调整,如果只是数字上的调整还好,如果每个双周都有非常大的调整,那说明对自己做的事情大目标没完全想清楚,是需要好好反思深刻探讨的。
回顾上双周目标完成情况与制定下又周目标
8.15 目标 | 完成情况 |
---|---|
务必完成 1 名前端人员招聘 | 完成一位实习生招聘 9.1 入职 |
cloud init 应用具备 demo 能力,完成公有云最小功能闭环 | 可以通过 kubectl apply aws 服务器,剩下 UI 部分 |
SMS 邮件 driver, 微信登录支持,充值能力 | 支持 SMS 和邮件,微信登录审核中,充值能力为开发 |
cloud terminal 能力具备 demo 能力 | 支持 kubectl apply terminal @zzjin @Abingcbc , 剩下与 UI 对接 |
8.31 目标 | 完成情况 |
---|---|
招聘 5 名实习生 /应届生 | |
计量控制器开发完成 | |
cloud init 功能完全闭环,UI 创建 /计费 /充值等 | |
+ *总需要重写 PPT 和商业计划书,提供高管能看懂的版本 |
下两周最重要的事,这里也不要写一大堆显得自己充实,我觉得 3 ~ 5 个目标即可,太多了起不到聚焦的效果了。
也有可能会出现一些不可预期的重要事情发生,那就补到表格里,如果不可预期的太多,那就要想想目标是不是有问题了,以及应该放弃哪些事了。
三个月结束时复盘的几个要点:
KR | 做的不好的原因 | 做的好的经验总结 |
---|---|---|
完成 3 家企业客户签单,合同额 100w | 团队缺少专门的市场合作人 | 技术硬实力服务好了客户 |
函数计算 500 注册用户 | 技术上经历数次大调整,缺少文档和博客的宣传力度 | laf 一篇文档影响力巨大让社区和注册用户爆发式增长,产品仍然是核心 |
github star 总数突破 12k | sealos 自然增长没达到预期 产品文档建设和宣传力度不够 | laf 实现爆发式增长 在产品上得到认可很关键 文档很重要 |
这个会议通常非常重要,建议可以花半天一天的时间去做,比如半天复盘,半天脑爆论证,对焦。
KPI 是决定公司和成员的年终绩效怎么样的,OKR 通常不与利益挂钩,是帮助组织目标对齐和个人工作聚焦的工具,可以更好的帮助组织和个人拿到更好的成果和绩效。
如公司 KPI:
比如营收 KPI 对应的是现金奖励:
营收 | 绩效系数 | 奖金(月) |
---|---|---|
< 50w | 0.4 | 0 |
[50, 100w) | 0.6 | 1 |
[100, 200w) | 0.8 | 2 |
[200, 500w) | 1 | 4 |
[500, 1000w) | 1.2 | 6 |
[1000w,) | 1.5 | 8 |
用户 /社区增长 KPI 对应的是股权奖励:
star | 绩效系数 | 股权 |
---|---|---|
< 17k | 0.4 | 0 |
[17, 20k) | 0.6 | 1 |
[20k, 25k) | 1 | 2 |
[25k) | 1.2 | 4 |
注册用户 | 绩效系数 | 股权 |
---|---|---|
[0, 500) | 0.4 | 0 |
[500, 1k) | 0.6 | 1 |
[1k, 4k) | 1 | 2 |
[4k) | 1.2 | 4 |
这样的话个人在制定 OKR 的时候就可以抛开 KPI 的负担了,至于个人 KPI 如何衡量我更倾向 80% 数据衡量 + 20% 主观判断,这个比例主要看你的数据有多准,越准就可以越相信数据。 比如 sealos 是开源项目,我们有人工智能每个月分析所有人的贡献情况,来决定个人绩效,未来我们希望 100% 让人工智能来决定,只是当前确实还不能完全做到。
** 目标对齐 **
** 帮助聚焦 **
最终你会发现最高效的做事方式其实就是在正确的方向上聚焦再聚焦! OKR 会防止你走偏,会让你在不知道干啥时及时把你拉回来。
你会发现钉钉飞书不用频繁点开,甚至半天不看对你 OKR 也没影响,很多会议也可以不开,群里消息不回也不会死人,对你 OKR 没贡献的事都可以通通靠边站。在你想分心时刻意克制一下就重新聚焦回来了,如果每天 8 小时做的事对你 OKR 都是有推进作用的那很难做不出成果的。
1
xlsepiphone 2022-08-25 12:31:08 +08:00 3
之前还在公司上班的时候,年中年末最烦的就是 OKR 。
对于一线工程师来说,这玩意儿和 KPI 没有任何区别。 |
2
lameleg OP @xlsepiphone 那是管理者有问题,学的四不像
|
3
Mark24 2022-08-25 14:05:59 +08:00
结果导向没啥用。推广 OKR 这是 HR 的 KPI 而已
|
4
civetcat 2022-08-25 14:10:23 +08:00
嗯。OKR 作为复盘工具,自己也是能够采用类似的机制的。尤其是对我这种自律性不够的
|
5
GP1 2022-08-25 14:15:41 +08:00
以前推崇 KPI ,现在推崇 OKR ,换汤不换药,你问问有多少公司真正的懂什么 OKR ?而不是套个皮的 KPI ?
|
6
lameleg OP @Mark24 东西是个好东西,执行起来确实不容易,需要组织成员对 OKR 都有比较深入的认知,很多管理者自己都没搞明白导致结果就是为了 OKR 而 OKR ,就本末倒置了。
|
7
lameleg OP @GP1 是的 很多公司执行不好的,即便公司执行的好 公司内部的很多组织和个人也执行不好,这个东西需要不断对焦碰撞探讨,发现本质才能执行的好。 我们也踩了将近两年的坑才觉得真的帮到我们了。
对焦的时候其实应该加一个问题 就是自己是否发自内心觉得 okr 帮到自己了,没有的话就得和懂的人多沟通对焦学习。 |
8
amon 2022-08-25 14:56:57 +08:00
想起剑宗和气宗了,OKR 和 KPI 这种工具是剑,管理思想是气。
最终还是要看使用的组织和人。 |