概念
MOKRA 是 Mission，Objective，Key Result，Action 的缩写，在传统 OKR 和 MOKR（Mission + OKR） 的基础上增加了 Action 放到日常执行里。
先梳理一下实体和实体关系：
Mission：我对一个项目/事情的使命，比如对于“工作”这件事情，我的使命是“提高全体人类的工作和生活效率，在相同条件下，创造更多的物质和精神财富”；
Objective：1个使命是由多个目标组成的，要实现上述使命，我应该设置哪些目标 或 检查点，要尽量量化，比如“人们在出行时间上，每100公里能够把时间缩短到2分钟”；
Key Result：1个目标是由多个关键结果组成的，要实现上述目标，我应该通过什么方式去做，也要尽量量化，比如“生产200台时速1500公里的飞行汽车”；
Action (todo)：1个关键结果是由多个行动组成的，要实现上述目标，我要做什么行动，比如“完成飞行汽车的发动机设计图纸”；
为什么要引入 Action (todo)
OKR 目前多用于组织管理，互联网企业中比较常见。Bytedance 的 OKR 实践是很好的，也有成熟的管理工具。
但是我发现一个有意思的现象，越是高层的管理者越能用好OKR，对于双月的 Objective 和 Key Result 写得准确清晰。越是一线执行者越不好写 OKR，很大一部分一线员工是不写OKR的，或者写得非常像 todo，就连 Objective 都是1个todo，比如“完成 xx 系统 v1.1.x 版本后端开发”，然后 Key Result 分别写上这个版本里的一些功能。
在 OKR 管理系统里，有一句 slogan “不要把OKR写成todo清单”，但是一线执行者不可避免把 OKR 写成 todo。
OKR 继承了 彼得·德鲁克 目标管理（MBO）的管理哲学，强调自我管理，弱化各级管控。在实际工作中一线执行者是很难有自我管理灵活性的。管理层可以在 N 个战略目标中选择 2-3 个作为本期重点，但是一线执行者不可以随意挑选，要想实现管理层的这些目标，他们不得不做大量被安排好的基础工作。不积跬步无以至千里，这样一来一线员工的 OKR 里写都是 完成 xx 需求开发就不奇怪了。
那么管理层只需要提出 Objective 和 Key Result，不需要做任何基础工作吗？答案是否定的。很多管理者每天都忙碌在各种沟通和协调之中，比如“召开xx会议，跟小组负责人敲定xx方案”。这些行动也是可以被计划 和 复盘的，它们可以被结构化。如果它们不经过计划推敲，那就很难量化每一步行动的意义和效果。
很多人都会在 Objective 下面写 Progress，我觉得它不能完全替代 Action，因为 Progress 是事后记录，不是事前计划，当你写出来的时候，已经是一个客观事实了。
所以我引入了 Action 的概念，对于管理层来说，除了制定 Mission 和 OKR，也要列举自己的 Action，也就是自己的下一步行动列表，这个列表最好也是全员公开，充分传递信息，也充分接收评价和反馈。对于一线执行者来说，也许他们不用写 OKR，只需要写自己的 Action，每一个 Action 对齐上一级的 Key Result 就好了。
Mission 一定要宏大吗
有一个容易引起误解的地方，就是 Mission 一定非得是宏大的使命。其实它可以被通用地表述为一个 Project 的 Mission，Project 可大可小，有的 Project 甚至可以小到没有 Mission，多个Project 可以嵌套，可以相交。
比如 “A 和 B 婚姻”可以是一个 Project，而“A 和 B 幸福美满过一辈子”是 Mission，这个Mission下的 Objective 可以有 “抚育2个健康聪明的孩子”，其中一个 Key Result 可以是“建立良好的家庭教育氛围”，KR 对应的一个 Action 是 “A 和 B 每周三去早教机构学习育儿课程”。
也可以存在另一个 Project，叫做“A 和 B 婚礼”，它也可以有自己的 Mission，Objective，Key Result，Action。甚至还可以有一个 Project，叫做“A 和 B 拍摄婚纱照”，它可以没有 Mission，也可以直接拿“A 和 B 幸福美满过一辈子”来做 Mission。
我经常把一次从北京回老家的短暂旅程当做一个 Project，当然这个 Project 比较小，小到可以没有 Mission，可以直接写 Objective 和 Key Result。也就是说 1个比较小的 Project 可以没有书面的、正式的 Mission，但是其实它存在，你不需要写出来也可以。
但是一个复杂的事情一定要有 Mission，Mission 是你长期坚持下去的动力，比如学英语，很多人都学英语，但是坚持不下去，因为学英语要做的 Action 太多了，可能是几万个 Action，仅仅有 Objective，Key Result，Action，很多人都坚持不下去。因为“我不知道我到底为什么要学英语”，这里就是缺少了 Mission，如果一个人学英语的使命是“我是一个中东战乱地区的人，需要学习英语争取移民到一个安全的英语国家”，那我觉得他学会英语的概率会大很多。
学习一门语言的途径
相反我学英语使命不清晰，或者使命是“大家都在学 / 老师强迫我学 / 工作中总用得到一点点”，这些使命的 ROI 太低了，付出几百上千小时的努力学习，回报却是滞后的、不确定的，我觉得在大家自己的潜意识里就会自然放弃掉。同样 健身、学习艺术 都会有这个问题。
在团队中 Mission 更重要，一个团队所有人的最大公约数就是对使命的认同。这个使命越清晰，认同感越强，那么这个团队的战斗力就越强。我们可以看到很多公司没有凝聚力，就是因为提不出一个全公司上下认可的使命，不同部门 和 层级各自为战。
MOKRA 层级关系
传统 GTD 工具 Omnifocus 的模型是非常灵活的，它有 Folder、Project 和 Action，其中 Folder 可以无限嵌套，可以层层分解一个巨大的任务，比如“制造1个火星登陆飞船”，通过无限分解，也许下一步行动仅仅只是“去超市买一个 #5 *6 的螺母”。
MOKRA 没有那么灵活，它是有梯度的，M 下一级就是 O，O 下一级就是 KR，KR 下一级就是A，Action 是一定要具体到行动的，这也意味着更容易操作，对模型抽象的要求不那么高，我们可以直接开始操作。
我们制定的 Mission，Objective，Key Result，Action 都是基于特定时间、特定环境提出来的。在不同的时间 和 环境下它们有可能是错误的，这种错误还存在杠杆效应，Mission 一旦错误，那么导致错误的后果是很严重的。
随着环境的变化，事物不同发展阶段，Mission，Objective，Key Result，Action 都有需要随机应变。所以我们需要随时检视，对于 Mission 来说我觉得双月是一个比较好的检视时间段。但是对于 Objective 和 Key Result 来说， 每双月检视一次又太少了，所以 Mission，Objective，Key Result，Action 分别需要定期检视，比如这样
Mission 使命，每 2个月检视一次，可以修改、删除、完成；
Objective 目标，每 2周检视一次，可以新增、修改、删除、完成；
Key Result 关键结果，每周检视一次，可以新增、修改、删除、完成；
Action 行动，每天检视一次，可以新增、修改、删除、完成；
这里要注意，四个层级存在继承关系， Mission 一旦修改，那么下面的 Objective，Key Result，Action 基本都得修改，Mission 一旦删除，下面的 Objective，Key Result，Action 都要思考存在的意义。
但是不存在严格的向上继承，比如完成1个 Mission 下所有的 Objective，不代表 Mission 就完成了，因为 Objective 只是最初对 Mission 的预判，不一定是完全等同的。
基于单个 Project 的 MOKRA 实践方式
现代生活中我们都不是单线程运行，每1个时间节点面临很多事情，比如创业、恋爱、装修、亲人过生日、朋友借钱等等。
如果我们只处理1个事情/Project，我相信很多人会处理得很好，比如给我1年时间好好办婚礼，那肯定没问题。我们先假设我现在只面临1件事情，我会怎么做，我会计划、实践、检查、再计划，其实就是 MOKRA。
我们在任意一个时间节点都会这个 Project 的 Mission，会有这个双月内制定的 Objectives，会有随着 Objective 制定时写的 Key Result，并且每周会检查一次，还会有一对 Action 清单。比如我写了 5个 Objective，每一个 Objective 有3个 Key Result，每1个 Key Result 都需要20步 Action 才可以完成，那么我一共要做 5x3x20=160个 Action 才可以实现 Mission，完成这个事情。
每1个 Action 都需要花时间和精力去做，有比较复杂的 todo，比如画一个建筑的结构图，可能要15个小时，1个工作日还无法完成，也有比较简单的 todo，比如去把文件打印出来，5分钟就好了。Action 除了有时间长短，还有精力投入度的要求高低，也就是常说的难和易，比如“画建筑结构图”比“打印1份文件”要难。
人们会有一种“先做简单的，不做复杂的，延后做复杂的”倾向，这是天性使然，因为容易的事情风险低、反馈及时。但是如果我们要完成1个复杂的事情，不可能全是简单的 Action，这里就要用那句古话，大丈夫当有所为，有所不为，做事情不问难不难，要问应该不应该，怎么判断“应该”呢？就看这个事情是不是 直接有效促进 Key Result 的达成了。
还有一个值得注意的是判断 Action 的优先级，假如有100个 Action 要做，它们又不全是串联的关系。我在同一个时间可以在 30个事情中选择一个先做，那到底该选择哪一种呢？
其实没有绝对的正确，我们也不应该追求绝对的正确路径，真正工作生活中很难有那种“不可逆转的选择”，很多事情都是非线性的，比如有学生考上国外大学，未来打算在当地工作，这是“不可逆转的选择”吗？其实不是，随时都可以再回国就业。就像你开车错过了路口，往前走再掉个头回来就好了，所以当面对优先级选择的时候，首先要消除“纠结”的心态，遗传算法的启示 篇就说明了这个问题。
但这也不意味着我们随便选就行，“四象限法”是一个很好的思维。我们先做重要和紧急的，再做重要且不紧急的，紧急不重要的可以委托他人去做，不重要不紧急的就直接不做。
柯维时间管理“四象限法”
依照“四象限法”我们可以把 100 个 Action 按照顺序排下来了，成为1个 Action feed 流。在往前做的过程中我们的 OKR 甚至 Mission 会发生变化，对事物有了新的认识，那么这100个Action 的 feed 流其实也需要有一个动态更新的过程。
那我每天做多少 Action 比较好呢，其实 Project 168 可以解决，这是来自 Ted 的一种时间管理方法分享，1天有24个小时，一周有7天，每周有168个小时，这些时间使我们的时间资本，我们的“钱”，我们可以用它来买东西（做事情），不论我想“买”多少东西，都只能从 168 里面扣除。
我们每天睡觉休息8个小时，那么168-7x8=112，吃饭3个小时，112-7x3=91，一周剩下91个小时，其实非常多了。足以容纳下很多工作和生活的计划，比如每天学英语1小时，也就消耗7个小时，仅占到7.7%，但也不是说每周 91 小时都要 all in 在工作或者某个事情上，保持好长期平衡就好了。
总结一下，如果我们只需要做1个项目/事情，它在可见的未来有100个Action，我们需要先把它们按照优先级排序，然后再按计划处理，我们每周有91个小时可以投入到其中。其实仔细算下来，几周就搞定一个大事情了。
多个 Project 并行
但是事实上我们要同时处理多个 Project，比如生活中、工作中会同时面临 5 个事情，有主动想做的，比如双十一购物计划，也有被动要做的，比如老板要我提升公司 10%的 DAU。
每一个 Project 都有自己的 Action，甚至不同的 Project 会有依赖关系，是一个很复杂的模型。但其实还好，可以用一个方式处理：我们把这 5 个事情的 MOKRA 写出来，形成 5 个Action feed，这个不难，上一个章节就说明了，只要做 5 次就好了。
但是第二步难，要把 5 个 feed 合并成1个 feed，根据四象限法把 500个 Action合并到1个feed 里，同样要注意“不纠结，不畏难”。
这个 feed 的难点不仅仅在于 Action 多，还存在非常复杂的 Action 变化。我们需要随时检查、调整，但我们的时间还是 P168，也许每周整理这个列表就需要花十几个小时。这样每周 91个小时就不那么够用了，时间虽然多，但是Action也很多，即使你硬着头皮上，也很难坚持很久。
砍掉一些 Project
很多人说在大城市工作一天，获得的成长相当于小城市一周甚至一个月，我觉得有道理，而且不仅仅是量变的区别，我觉得还会有质变的区别，比如一个小县城大概率不会有音乐厅、美术馆、游乐园。北京孩子认识“恐龙”也许直接是在中科院古生物博物馆里进行的，所以有可能在大小城市工作和生活的带来的差别是“永远也无法追上的”。
那我们在大城市每周疯狂工作/学习，用掉91个小时，会是一个好的选择吗？我觉得不是，这个其实涉及到人生观了，不做过多赘述。
重点是人（特别是在自驱力强的人，比如在大城市的工薪阶层）都会有“对资源/信息的贪婪”，希望面面俱到，什么都强，这是符合趋利避害天性的。但是想法好，结果不一定好，物理上人的精力和能力有限，即使 MOKRA 或者别的项目管理方法论用得再好，也不可能在1个月内学会20种语言。
“对资源/信息的贪婪”其实是好事，但是不要忽视“时间的力量”，人均寿命达到80岁的今天，只要把时间拉长一些，是可以完成“学会20种语言”的。
另外我们也需要思考“做这个事情有意义吗？”每个人的人生观都不同，但是大体上是比较通用的，因为我们的文化和成长环境不会差太远，很多 Project 看起来很有吸引力，但是实际上可能并不适合每个人，比如“做一个网红”、“练出8块腹肌”等等，也许我们还可以通过别的方式达到“成为值得别人尊敬和喜爱的人”，所以想清楚每一个 Project 对自己的意义，果断砍掉一些不合适的 Project 是必要的。
所以在 OKR 理论里，作者也会建议在我们 Objective 和 Key Result 不要超过5个，靠长期迭代去实现宏伟的目标。即使我们急于实现许多宏伟的目标，但最好的方案还是长期作战，劳逸结合。
