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是一个很有用的工具，希望大家都可以很好的掌握这个工具。
