迈金科技 OKR 实施以及企业协同办法
前言<a id="orgheadline1"></a>
经过分析公司的特点以及梳理初步试用 OKR 遇到的问题，现整理 OKR 实施以及企业协同办法如下：
流程<a id="orgheadline2"></a>
- 周五下午四点前所有员工提交自己本周的 Review(以 Github issue 的形式，在 company 仓库 提交)。Review 标题和内容示例见[附录 A：Review 标题与内容示例]
- 周五下班前管理层审阅所有员工提交的 Review，有不明确的地方可在 Review 下讨论或者当面讨论，但是问题明确后必须更新 Github 上的 Review， 以确保该信息符合最终达成的共识。
- 周五晚至周日，管理层选择合适的时间对所有员工的 Review 进行讨论，协调各种问题，制定出下一周的计划。
- 周一上午开周会，根据上一流程制定的计划，协调和分配任务。
管理层如何分配任务？<a id="orgheadline8"></a>
集中式<a id="orgheadline3"></a>
每周一上午周会期间，管理层根据上周大家提交的 OKR Review，统一协调好本周的任务，然后立即录入到企业协同系统（本文所说的企业协同系统对于迈金科技来说就是 Github 的 Issues 模块）。
分散式<a id="orgheadline7"></a>
除了周会时统一分配任务，管理层也很有可能会根据实际执行时遇到的突发问题，临时增加、撤销或者调整任务，这时应根据任务属性的不同采取不同的处理策略：
非紧急任务<a id="orgheadline4"></a>
所有的非紧急任务必须录入到企业协同系统。
紧急且一两个小时可以完成的任务<a id="orgheadline5"></a>
这种任务从时间上来说不会对员工的正常工作流产生太大的影响，因此可以不录入企业协同系统，但是如果有记录的价值或者与代码仓库相关，还是建议录入到企业协同系统，以便于记录。
紧急且需要耗时三小时以上的任务<a id="orgheadline6"></a>
这种任务往往会对员工现有的工作流产生较大的影响，如果频繁的有这种任务产生，而且又不录入企业协同系统，那么企业协同系统的存在就没有意义了，也不会有任何效果。
录入到 Github 时，需要注意以下几个问题：<br />
- 如果该任务存在对应的 Github 代码仓库（假设仓库名为：repo），那么就把该任务作为 repo 仓库的 issue 来添加<br />
- 如果该任务不存在任何对应的 Github 代码仓库，那么就把该任务作为公共仓库（company）的 issue 来添加<br />
员工的任务来自哪里？<a id="orgheadline12"></a>
单纯自上而下地看“任务”并不能看清其全貌，我们需要换一个维度再来看任务的分配问题。那么，从员工的角度来看，任务都来自哪里呢？
产品需求<a id="orgheadline9"></a>
对于研发团队成员来讲，大部分的任务来自于产品需求，当然，后期还会有 BUG 处理，但是这个流程是比较清晰的，无需赘言。
管理层分配的任务<a id="orgheadline10"></a>
管理层分配的任务可能来自于上一章节中的“集中式”或“分散式”分配。
自己的 OKR 目标<a id="orgheadline11"></a>
有时候员工可能很快地完成了上面两种任务，这时候应该抬起头看看自己的 OKR 目标，思考一下要想达到那个 OKR 目标，自己还能在哪些方面进行改进？
员工在写自己下一周的计划时，需要注意以下几个问题：
- 下一步计划本质上是“任务”的汇总<br />
- 仔细的从上述三个角度思考下一周应该执行哪些任务<br />
- 计划里的所有任务都应该以任务链接的形式存在<br />
- 如果某个应该执行的工作没有被录入到企业协同系统中，那么应该首先将它录入后再写到下一步的计划中<br />
生成任务的几点注意事项<a id="orgheadline16"></a>
粒度<a id="orgheadline13"></a>
任务的粒度必须足够小，小到能够大概评估出其工作时间，这样就能很快确定一周能完成几个任务
一个任务只对应一个人<a id="orgheadline14"></a>
不应该出现一个任务对应多个人的情况（Github 里的 issue 也只能分配给一个人）
任务应该有标题和内容<a id="orgheadline15"></a>
任务的内容应能让所有与之相关的人读懂，切不可为了一时省事，写一个谁也看不懂的任务描述。
而标题应该只有一句话，它是对内容的高度总结。
总结<a id="orgheadline17"></a>
简单来说，这一套制度有以下几个益处：
- 提高了效率，同样的时间我们可以做更多的事了<br />
- 时间更自由，Github 里最成功的那些项目，他们的开发者不需要每天面对面，不需要限定上班时间，但他们仍然是成功的项目<br />
- 愉悦了心情，如果工作中的一切都井井有条、配合默契，工作起来一定是愉悦的<br />
- 好的制度本身是一种科学，身处其中，耳濡目染，时间长了不知不觉便掌握了一门新技能<br />
- 好的制度会吸引更多优秀的人，与优秀的人一起工作，自己也会变得更加优秀<br />
- 当然，每一个员工更加优秀了，整个公司也必然会创造更好的业绩，双赢的事才是值得我们付出的事<br />
但是不可否认，一个制度的实施将面临重重困难，需要从管理层到员工所有人一起努力，互相支持。我们曾经试过 Worktile，但是始终没有用起来，究其原因，最主要的还是作为管理层没有想清楚如何执行，仅仅是在别人划定好的框框里生硬的照猫画虎。
而这次，我看了很多文章，进行了深入的思考和实践，也写了几篇文章，目的就是让自己想清楚所有环节该如何处理，不要有不确定的因素，唯有如此才能有信心去执行。而即便如此，我仍然对未来有所敬畏。
但是不急，我们不是要做一个三五年的企业，短期来看，对员工的工作增加了负担，造成了干扰。但是长期来看，这种付出是值得的，最终受益的不仅是公司，也是每一个与我们共同成长的员工。
<a id="orgtarget2"></a>
参考链接<a id="orgheadline18"></a>
<a id="orgtarget1"></a>
附录 A：Review 标题与内容示例<a id="orgheadline21"></a>
Review 标题示例<a id="orgheadline19"></a>
标题形式为：英文名-月.日-Week Review。例如：Frank-01.16-Week Review。
Review 内容示例<a id="orgheadline20"></a>
内容的示例 1：
# 当前进度 上周的任务全部完成 # 遇到的问题 无 # 问题的原因 无 # 下一步的计划 开发以下任务: 1. [模型建立](https://github.com/docker/docker/issues/10) 2. [模型实现](https://github.com/docker/docker/issues/8)
内容的示例 2：
# 当前进度 上周的任务 1： [模型实现](https://github.com/docker/docker/issues/8) 完成 80% # 遇到的问题 导入 xxx 失败 # 问题的原因 xxx 软件版本不兼容 # 下一步的计划 开发以下任务: 1. [FOO](https://github.com/docker/docker/issues/11) 2. [BAR](https://github.com/docker/docker/issues/9) 3. [XYZ](https://github.com/docker/docker/issues/4)
