参考
https://baijiahao.baidu.com/s?id=1625996281431874863&wfr=spider&for=pc
没有谁更完美
说到这儿,你可能会问:OKR这么好,为什么大家还用KPI?
事实上,KPI和OKR都只是绩效工具而已。并没有孰优孰劣。
如果你的工作时在一个客户服务电话的呼叫中心,你的工作绩效就是一分钟接几个电话,热线接听率,客户投诉率等等。在这种情况下:KPI就是最适合的绩效工具,即便是制定个人目标OKR,也并没有很大意义。
而对工程师来说,用KPI衡量工作未免有些可笑,算码多少行代码吗?把项目做出来才是王道。
KPI强调的是“要我做的事”。而OKR致力于是“监控我要做的事”。作为绩效工具,KPI和OKR并无孰优孰劣之分,业务单元适合,我就用,不适合,就不用。
OKR比KPI 好的不只是Bigger!
其实站在员工的角度,KPI无非就是:
在指定的时间段内,我要完成哪些任务;
这些任务,我分别要完成到什么程度;
根据完成了哪些、各自完成的程度来拿钱。
说得再简单一点就是,完成了KPI拿钱拿奖励,完不成爱干嘛干嘛。
于是乎领导KPI一定,员工振臂一呼,大家拼命干活。
为什么要用OKR呢?
OKR能让我们抓住主要矛盾,找出对企业发展真正重要的事。
让我们能聚焦优势资源在最重要的事上,可以很大程度的减少资源浪费,这对创业企业尤为重要。
能让团队成长的迭代周期更短。
能让每个人都有清晰的目标感,都能盯在重要的事情上。
能让每个人对目标的理解都是一致的,从而同心协力,避免因为方向分散带来很多内耗。
1)目标(O)设定要做到少而精
目标(O)的数量需要控制,不能设置太多。太多了就导致年度无法有效的聚焦,一般情况下OKR操作建议目标(O)最多不要超过五个;
2)每季度通过评价KRs来检验目标的完成情况
每个季度末对关键结果KRs进行评价,完成60-70%就算好,如果100%完成,说明你的目标(O)设定过于简单。
3)遵循“自下而上再自上而下”的程序
首先要“群策群力”,充分听取底层员工对目标(O)的意见,再滚动修订战略并确定年度目标(O),季度目标(O)。
4)目标务必是具体的、可衡量的
例如不能说笼统地说“我想让我的网站更好”,而是要提出诸如“让网站速度加快30%”或者“融入度提升15%”之类的具体目标;不能说“使gmail达到成功”而是“在9月上线gmail并在11月有100万用户”。
5)目标(O)要是有野心、挑战并让人不舒服
目标(O)设定不能是现在做成什么样就是什么样,一定要可实现并具有挑战性。这样你才会不断为你的目标而奋斗,而不会出现期限不到就完成目标的情况。员工通常每季度会制定4到6个目标,目标太多也会令人焦头烂额。
6)目标(O)必须充分沟通达成共识
目标(O)必须是在管理者与员工直接充分沟通后的共识。没有达成共识的目标不能算作目标,目标的设定以达成共识为终点。
所谓的KR就是为了完成这个目标我们必须做什么,KR是必须具备以下特点的行动:
-
必须是能直接实现目标的;
-
必须具有进取心、敢创新的,可以不是常规的;
-
必须是以产出或者结果为基础的、可衡量的,设定评分标准;
-
不能太多,一般每个目标的KR不超过4个;
-
必须是和时间相联系的。
目标既要有年度KRs,也有季度KRs:年度KRs统领全年,但并非固定不变,而是可以及时调整,调整要经过批准;季度KRs则是一旦确定就不能改变的。在这里要切记可以调整的是KRs,而不是目标。目标不能调整,措施和方法(KRs)可以不断完善。同样KRs的设定也必须是管理者与员工直接充分沟通后的共识。
https://baike.baidu.com/item/OKR/2996251?fr=aladdin
看一下上级的OKR,看一下别的部门的OKR,看一下同级的OKR,了解目前公司最重要的任务是什么,这个季度最重要的任务是什么,我做什么能够帮助他们。季度会也是尽量让相关人多参与,并不是一个非常小范围的高管会。我们还会经常举办CEO面对面,在这个会上回答员工提问,让大家了解公司进展。
https://www.processon.com/view/5abb6be6e4b027675e44369c#map
研发绩效评估表
https://www.docin.com/p-2218940557.html
我们是如何在技术部门引入OKR的
https://blog.csdn.net/Philm_iOS/article/details/81200731
公开透明,目标明确
每个同事的OKR都是公开透明的。这样带来的好处是,你可以借鉴别人的计划,为自己指定目标做参考,另外,自己的目标被别人了解之后,无形中会有一个同事之间的压力,促使自己关键成果的达成。一个团队的Scrum Master虽然有推行轮班制的计划,但是之前基本上由Team Lead来兼任。在一个季度的OKR设定时,一个同事在自己的OKR中设定了一个目标,要更多的参与到团队敏捷站会的组织中来。在每日站会的时候,别的同事字在了解到他这个目标时,就推荐他来做Scrum Master,整个过程的沟通非常清晰。
另外一个例子是我们的一个同事给自己设定了一个更加充分了解和掌握所有团队新产品特性开发的目标,为了帮她更加容易的实现这个目标,我跟产品经理沟通,要求产品经理在发起新产品特性开发评估会的时候,确保邀请她参会;跟Team Lead沟通,当评估会没有邀请她的时候,确保及时纠正,并把她的工作安排进行了适当的调整,以便她有时间来参与到这些评估会中。这些活动快速的发生,都是因为OKR对目标的明确化,减少了沟通成本。
我们的OKR系统已经推行了半年多,现在很难说成功,但是,像敏捷开发一样,我们都是本着反馈,迭代的方式来发展的。随着更方便的工具的引入,工程师二次开发的OKR自动计算功能,以及OKR协调员制度的推行,我们认为OKR系统正朝着一个正确的方向发展。
okr管理工具
https://www.teambition.com/organization/5dfa15482f86bb00012a3b91
Worktile
https://www.zhihu.com/question/41897952
Tita用的多目前
研发岗位OKR的设计与激励 - 管理角度(附部分岗位样例)
https://blog.csdn.net/zgdwxp/article/details/93969892
OKR理论中有一些关键的描述,简单概括几点:
“OKR是一种沟通方式,而不止是一个绩效工具。”
“目标是以达成一致为标准,没有达成一致的不是目标”;
“KR是可衡量的,KPI是可量化的:这其中有微妙的区别,意味着KR并不一定是某个数字,也可以是里程碑或其他可直观衡量判断的DoD”。
持续迭代者的OKR与敏捷开发
https://www.jianshu.com/p/873da02ab5ac
软件开发的过程,就是一个制定目标(OKR)与持续行动(敏捷开发)的典型案例。
软件从立项、风险评估、开发,测试,发布是一个严谨并且井井有条的过程。
每个项目在立项之后,技术人员都会做技术调研,风险评估,之后会根据需求,对每个模块做精细的分工,细分到每个人天,然后做精细的排期。
开发进行中,大部分互联网公司采用敏捷开发的工作方式,每天的站会,同步进度与遇到的问题和风险点,及时抛出问题并解决。
就按照这样的方式,大家用的产品就形成了,当然之后还是会有大量的测试迭代过程。
我想说的重点是,按照这种方式,工作过程可以做到如此的自律,那自己的生活中,是不是一样能做到。
研发团队如何使用OKR
https://new.qq.com/omn/20190119/20190119B15FT500
性能目标
接口响应时间控制在 xx毫秒以内;
接口相应时间从XX毫秒减低到XX毫秒。
页面渲染速度从xx毫秒减低到xx毫秒。