《OKR工作法》有感

OKR的全称为 Objecttives and Key Results 即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法。它能够让整个团队聚焦于同一个目标。

OKR流程

OKR的整个实现流程如下：

结合公司愿景确认实现有挑战的目标(既不是很容易实现也不是完全没有可能，书中描述的是让实现的人能够发出“我尽力尝试一下”。目标尽量设置为一个，且时间周期不能太短)
依据目标确定关键结果(目标是一个较空泛的概念，但是关键结果却需要是可衡量的，如果实现了关键结果我们就可以这个人认为实现了该OKR)
目标设置一个信心指数（50%），然后每周五同步一下OKR的实现进度，然后每个人上调或下调信心指数并说明为什么，有什么东西阻碍自己。
周五开胜利大会，每个人说说这周对团队OKR做了什么然后小小庆祝一下，让整个团队认识到大家都在为同一个OKR努力。
开季度OKR总结会议，成功和失败的地方都需要找出原因出来，然后下一个季度改正。

经典语录

OKR就是通过实践、总结、不断发现、挑战团队的潜力，而不要把这个过程当作汇报、考核结果。因此，假如团队真的没有完成任何一个关键结果，就要一起思考为什么会这样、怎么改进。如果所有的目标都达成了，那就设置更有挑战的目标、把精力聚焦在学习总结、挖掘潜力和高效执行上，然后每周五为结果庆祝。
当绩效考核驱动目标而不是目标驱动业务绩效时，目标就是为了年度评估而创建的。当员工签了一年有保障的劳动合同后，还谈什么目标，绩效注定是低的。随着业务的增长，员工年度目标和业务实现的脱节会更加严重，水分也会越来越大。
高绩效人士开始每天的工作市都会先审视他们的目标，然后有意识地根据目标分配具体的时间。
只设置一个公司级别的OKR，除非公司有多条业务线。这就是聚焦。
给自己三个月时间去挑战OKR,一周内可以完成的目标绝对称不上挑战。
目标里不要有传统的绩效考核指标，目标需要能够鼓舞人心。
在每周盘点进度时，先从公司OKR开始，然后沟通部门级别的，不需要在会议上沟通个人OKR,个人OKR只要一对一交流就可以，每周必须确认OKR的进度。
鼓励员工对公司OKR提出意见和建议。OKR不只是自上而下的实施，也要自下而上的成分，要让所有人参与其中
周五的庆祝活动对于周一严酷的业务来说是一种调剂，可以让团队保持乐观积极的态度。
很多人都会陷入两个误区：要么是过于高估自己的能力，觉得自己无所不能；要么就是过分谦虚，隐藏自己的真实实力，这都会让管理变得混乱。作为管理者，你要清楚地知道哪些人推一推会有更高的产出，哪些人实际执行情况会出现问题。每周对员工进行跟踪回顾，会让每个人更准确地预测自己的产出。

自身体会

大概走过公司内部的会议流程，感觉整体还是很正规的。不管是sprint会议总结，还是季度OKR会议。但是有一点觉得不好的地方是对于OKR的拆分，团队中有人有OKR，有人没有OKR。我以为这是不好的，会导致没有OKR的人员参与感低，好像和这个项目没有关系。OKR可以分为两种，一种是公司的发展方向的，另一种也应该关注个人发展，个人不断的发展也能正面的反馈到公司的发展。没有一种大家都在为同一个目标努力的感觉，导致团队的凝聚力不足。参与感低导致队员的主观能动性低。我认为每周五适当的庆祝一下是一个很好的主意，适当的激励能够让团队更有激情。

OKR的另一种用法

OKR不仅仅是用于公司的管理，我更理解为它是一种高效的时间管理方式。聚焦，关键成果是我比较深有感触的，我常常在做一件事情的中间，做别的事情，比较难聚焦于一件事。所以我打算自己尝试一下利用OKR实现自己的时间管理方式。因为公司的Android技术栈为Kotlin,但是自己组内使用的是Java。所以我打算学习Kotlin，能够满足于日常的Android开发。

OKR实践

O: 两个月内学习Kotlin满足日常的Android开发
Key Result: 使用Kotlin编写WanAndroid项目
信心初始值: 50%

第一周

基础的网络库已经搭建完成，并使用Junit和robolectric 对API进行联调成功
首页的HomeActivity基本完成
还剩下几个模块没有完成：知识体系模块，微信公众号模块，项目模块，我的信息模块，搜索模块，首页浏览模块
目前遇到的坑： Cookie的复用出现一个Bug,待解决
信心指数：60% 目前已经完成2个模块，后续的UI模块会更加快，预计每周完成两个模块，争取后3周基本完成，然后优化代码
学习到知识：Kotlin的伴生对象，延迟初始化，非空判断，接口和类的定义，构造函数初始化顺序以及主构造函数设置，类模块、函数模版的设置，内部类和嵌套类

第二周

完成的模块：知识体系模块，微信公众号模块，项目模块，我的信息模块已经完成
未完成的模块：搜索模块和浏览模块
目前遇到的坑：首页加载的时候网络请求过慢，间隔的时间过于久，大概显示空白的3秒(猜测刚进入首页，各个Fragment都在进行网络请求)
信心指数： 80%，只剩下两个模块，可以很快完成，
后期需要对APP进行每个模块的单元测试，以及目前想到的优化方向：内存优化（LeakCanary）, Fragment的懒加载，WebView如何更快加载url
下周做的事情:完成搜索模块和浏览模块，基本完成所有的功能。然后使用Junit和robolectric对项目的单独模块进行功能测试（达到能够较为熟练的使用单元测试）
本周学习到的知识：Kotlin的主构造函数和从构造函数的区别、Kotlin的中的覆盖，函数覆盖，属性覆盖、伴生对象的实质、const的使用界限，多接口若方法名相同如何实现具体实现、Kotlin的扩展函数。见笔记

第三周

项目所有模块已经完成
下一周需要做的模块： 2.1 把原有项目中的RxJava做网络请求部分切换为Kotlin的协程实现 2.2 优化一下代码，实现Fragment的懒加载 2.3 调整一下代码机构，优化优化 2.4 实现顺利的话，就把项目开源
信息指数：90%，整体模块已经完成，下面做些优化的工作，可能难点是切换为Kotlin的协程，以及如何使用Junit和Robolectric的学习进行代码的单元测试
本周学习的知识：初步学会了使用Robolectric模拟进行Retrofit的API测试，WebView的优化：提前初始化WebView(使用对象池),加载时先禁止加载图片，开启硬件加速，开启缓存，替换成腾讯的x5内核，Html模版放置到本地进行加载，数据部分进行刷新(如何操作不会)，最后一个比较好的框架VasSonic（VaSonic在Java可以使用，但是在Kotlin中会报错误Please include Java exception stack in crash report)

第四周

项目完成项目链接
OKR完成
Kotlin项目和Java项目进入维护阶段，如果遇到好的点子，或者之前的处理方式不好的地方进行修改
产出的Kotlin知识图谱还在持续完善中
本来预期2个月完成，实际一个月完成，说明预估Java转Kotlin没有想象中难度高

年末OKR

背景： 学习frameWork层的知识，Android的framework层知识是安卓系统的核心，也正是它被称作为系统的真正原因，目前自己对于framework的知识，只是靠曾经看博客，理解不清晰，只有别人说起这个，才会哦这个我之前看过是这样的，理解不深，为了加强自己的理解对于framework的知识，启动该OKR。
目标： 加深对于framework的知识的理解，主要在于systemservice与普通应用之间的交互，AMS,PMS,WMS,以及View System这几个模块
结果： 构建一个APP，实现APP的热更新Demo,利用AMS,PMS，WMS的知识点，在了解与系统的交互方式之后，达到欺骗系统的作用
大致计划： 首先阅读任玉刚老师的dynamic-load-apk的源码，并且结合aosp上安卓源码理解该框架，然后自己写一套该应用
时间： 3个月，在12月底之前构建一个APP，并产出相应模块的知识图谱
开始时间： 10.8开始

第一周

这一周主要看源码调试dynamic-load-apk的源码，并且生成一个知识图谱完成情况：源码的整体意思看完了，但是整体的协议的设计为什么要这样设计并没有理解清晰，且知识图谱没有完成

第二周

发呆一周
信心指数： 0%
导致原因： 个人认为是一开始没有很细致的想清楚这个项目该怎么写，一步一步怎么搭建，我在写之前制定了一个大体计划，但是每一步过于空泛，没有细致到可执行的地步，为什么没有制定出详细的计划，，个人感觉还是对于Dynamic第三库的理解不深刻，导致自己想写的时候，再思考，然后内心就不愿意写了，写出来的代码整体逻辑性上也非常差。下一周重点设计一下整体框架交互的协议，分成几个部分，各部分之间如何实现交互。

第三周

基本完成可以使用安装的APK的去打开本地APK文件中的Activity，并实现了Intent的数据传输
信心指数： 60%
导致原因： 本周投入的时间较低，大概只有几个小时，受其他因素影响
激励一下： 如果第四周的任务完成比较好，奖励自己一台2K显示器 第四周的任务：

整体设计好整个APK的协议，与本地APK文件之间的交互，完成一个基本框架图
原有的DynamicLoadApk的知识图谱完成
重点理解Resource在什么时候调用，什么时候组装

第四周

DynamicLoadApk的知识图谱完成，Resource的调用流程完成70%(中间插入了一些其他事情浪费很多时间)
第五周任务

Resource的调用流程继续完善
《Android插件化指南》看完一半，并生成知识图谱