【原创】技术应该如何写OKR

5个月前 (12-07) 0 点赞 0 收藏 0 评论 13 已阅读

OKR理论

首先需要明确的是,OKR是一个工具,不是一个考核,他最重要的目的在于协作,以及提高自己的能动性,学好OKR,不但工作会更有成效,生活中也是一个非常好的工具,他可以指导你如何更好的完成一个任务。

OKR三大特点

1、透明:公司目标,上下同欲,左右对齐
2、野心:通过沟通设置具有挑战的目标
3、绩效评估解耦:绩效评估通过经理对下属做整体判断。OKR完成不作为绝对指标。

O设置的要点

1、关联公司目标,上下同欲,左右对齐。
2、有意义,明确,能激发人的野心。
3、不用数字,除非数字很能打动人。
4、O不要超过3个

KR设置的要点

1、作为O实现路径,是充分条件,也即KR完成了O就实现了。
2、应该能够具体衡量,通过具体数字说明完成程度。
3、每个O的KR为3-5个为宜。

实时细节

1、每个O和每个KR,有commited(承诺)指标和stretched(进取)。
2、每个O和KR对齐时候,能够填写完成进度、信心指数。
3、OKR按季度设置,周会,月会和作为对齐的节点。
4、经理对下属做整体判断。okr完成率横向不可比。

失败案例

1、搞不清楚O,搞不清楚市场与对手。
2、基层员工不理解ORK的一样无法形成有效沟通。
3、KPI一样的OKR。
4、制定完后就放一边,后期工作没有和ORK关系。没有做好ORK的周、月、季review。

人性

1、不用KPI,绩效考核时候对上级要求高。要求上级实际上了解下属工作与挑战性。
2、ORK可以当作当作人生的思考框架和工作习惯。有目标有路径才能做成事情,更好提高产出。

OKR的实施

OKR 实施过程中,起草、制定好目标和关键结果是非常重要的一环,有效的 OKR 制定,需要满足 SMART 原则——

明确的:
可衡量的:
可实现的:
有相关性:
有时限性:

目标(O)

回答的是:我们想做什么,是定性的,要求能够鼓舞人心,激发团队共鸣。

关键结果(KR)

回答的是:我们如何知道自己达成了目标要求,是定量的,设计 KR 最具挑战的部分是如何把目标中定性的描述抽象为定量的表示。

目标:对项目实施清理,使代码易理解,好维护,性能高,健壮性强

? 关键结果一:XXXX时间按照规范完成工程文件的整理。
? 关键结果二:XXXX时间按照规范提取200个工具方法,消除重复代码。
? 关键结果三:XXXX时间按照规范消除2个5000行代码的业务类。
? 关键结果四:XXXX时间按照规范提取2个公共业务到组件库中,供其他项目使用。
? 关键结果五:与产品和负责人沟通,确定重构计划。

目标:保持头脑清醒,让工作更加出色,为他人做出更多贡献。

? 关键结果一:XXXX时间分享3次。
? 关键结果二:XXXX时间调研某某平台SDK,并输出其功能的文档,以及应用场景。
? 关键结果三:XXXX时间完成10篇高质量的文档沉淀。
? 关键结果四:做10次Code Review
? 关键结果五:为他人解决一个业务难题。

我的3月OKR回顾

O1 :整体规划核心业务组件底层技术实现方案,并且实现一个组件的应用。
KR1: 技术选型的确认及文档输出
KR2: XXX模块组件化,给出一个Demo或接入一个产品进行验证成功

O2: 规划内容运营和管理平台并落地
KR1: 整理内容和运营平台需求,需要考虑各方的工作量,2月底交付中台负责人。
KR2: 在重要节点负责跟进,保证符合需求,预期3月底交付

O3: 核心项目的业务支撑及优化
KR1: 解决项目严重影响产品指标的性能及体验问题
KR2: 有效支撑业务版本迭代,稳定性维持现有水平

O4: 研发团队整体提升
KR1: 在整体的流程规范下,确定开发人员的开发流程规范,并促成开发人员按照新的流程进行开发工作,保证项目整体的流畅。
KR2: 技术组每月至少分享2次,知识库内容沉淀至少每人每月一篇。
KR3: 公共组件库的维护,至少保证每月增加一个通用功能组件。

反思

从O的角度看

最大的问题在于,没有什么能量,激发不了自己的野心。感觉就是个陈述句,无法激发野心,工作中可能自己关注度就会降低。
O1: 整体规划核心业务组件底层技术实现方案,并且实现一个组件的应用。

是否可以改成:

回顾已有业务的核心技术实现,规划合理的、通用性强的、性能高的新技术架构,达到行业内80分位。

修改后的目标更符合业务线整体目标,如果这么写会有几个关注点:

回顾已有业务的核心技术实现,这不得不迫使我去进行拉会讨论以下问题:

1 现有的核心业务是什么?
2 他们分别的技术实现是什么?
3 技术实现的优缺点是什么?

规划合理的、通用性强的、性能高的新技术架构

1 通过上边对已有技术的分析,才能通盘规划和设计。
2 使注意力集中在是否合理,是否通用,是否性能很好。
3 这是一个新的技术架构,而不是在做一个功能。

达到行业内80分位

1 什么是行业内的高标准?
2 他们是如何实现的?为什么人家的好?
3 我们是否能做到?如果用人家的技术实现,时间成本是多少?如果不用,是为什么?不用的话能达到多少分?

从KR的角度看

KR1: 技术选型的确认及文档输出
KR2: XXX模块的组件化,给出一个Demo或接入一个产品进行验证成功

这里有一个问题,KR如果都达成了,是否O就达成或O的进度就会往前走?回过头来思考,他们的关联性太弱。

KR1: 技术选型的确认及文档输出

明确的:我觉得现在看来,这个KR非常不明确,靠什么做的技术选型?输出什么文档?技术架构文档,后边就变成了组件集成文档。
可衡量的:如何评估你的技术选型是正确的?
可实现的:这个我不想评价。
有相关性:你的技术选型符合整体规划吗?我把这项工作的决定权都交给了别人,开始是计划做一个好的架构,后来变成了实现一个XXX模版的组件,这就已经脱离的目标。
有时限性:需要多长时间完成这项工作,实际上也确实没有定义这个时间,因为草草讨论后就定了下来,着手开始写代码了。

KR2: XXX模块的组件化,给出一个Demo或接入一个产品进行验证成功

这个KR是我最想说的,感觉整个3月,这个KR更像一个O,我们终于完成了一个XXX基础组件,并上线验证了。这和我们的目标不符。

最后

OKR是一个很有用的工具,希望大家都可以很好的掌握这个工具。

雪堂_幸福猪


雪堂-儒家国学经典|雪堂-道家国学经典

幸福猪的雪堂书屋 - 连载

会员通道


【原创】技术应该如何写OKR

本文收录在
0评论

登录

忘记密码 ?

切换登录

注册