前言<a id="orgheadline1"></a>
Github 对于软件开发者的重要性不言而喻，但是其实大部分人仅仅用到了其冰山一角。本文尝试介绍一套通过 Github 进行 OKR 实施以及企业协同的方法。OKR 的介绍见文章最后的参考链接。
如何管理 OKR？<a id="orgheadline3"></a>
OKR 的特点<a id="orgheadline2"></a>
OKR 管理制要求公司每年、每季度都要确定一套 OKR，而且数量有严格的限制，最多有 5 个 O，每个 O 最多 4 个 KR。OKR 除了在公司进行 Review 时会稍作调整，其他时间基本上是不需要再进行修改的。
由此可见，OKR 有几个特点：
- 有限性，整个公司一年产生几个文档足已
- 公开性，所有的 OKRs 对公司内部所有人可见
- 稳定性，OKRs 不会频繁被修改
基于上述特点，在 Github 上建一个企业内部的公共仓库，把 OKRs 作为 Wiki 录入到该仓库中再合适不过了。
如何管理 Review<a id="orgheadline5"></a>
Review 的特点<a id="orgheadline4"></a>
OKR 要求公司以及每个员工要定期 Review，公司每月一次即可，而员工每月、每周都要 Review，Review 的内容包括“目标，进度，遇到的问题，问题原因，下一步计划”。由此可见，Review 的特点如下：
- 数量大，每人每周产生一个 Review
- 可讨论性，周 Review 的发起人是员工，但是针对其中所描述的问题，可能需要其他同事参与进行讨论
- 变化性，基于问题讨论之后，应该对下一步的计划有所影响，所以 Review 中的“下一步计划”可能需要修改几版后才能稳定下来
- 通知性，Review 的提交以及问题的讨论都要求相关同事及时得到通知
- 知识性，员工以及公司的 Review，不管对员工个人还是公司，都是累积的知识，不应该用完就被完全废弃
- 时效性，过期的 Review 应该被归档保存起来，避免浏览时过度影响当前的 Review
- 便于追溯、检索，凡是积累的知识都应该能够追溯和检索，否则没有意义。
基于这些特点，我认为 Github 里的 Issues 是一个完美的选择。
每周五的时候为每个员工分配一个 issue，员工以评论的形式提交自己的周 Review，并@ 相关的同事予以关注（当然也可以让员工自己发起 issue，并分配给自己）。
相关的讨论可以在下面肆意的进行。确定好了下一周的计划后可立即修改。
到了下一周的周五，如果上周五 issue 中计划的任务全部完成，则 close 掉该 issue。如果没完成则继续保持 open 状态。
同时，本周五还会生成一个新的 issue。多个 issue 在身，员工的压力自然就来了，OKR 的目的也就顺利成章地达到了。
如何掌控进度<a id="orgheadline6"></a>
还有个问题是：管理层如何对全局的进度进行掌控？这个时候，Github Issues 里另外一个好东西要派上用场了，那就是 Milestones。
我的方法是为每个周建立一个 Milestones , 将其截止时间定到下一周的周末，并把本周所有的 issues 都关联到此 Milestone 上。
这样到了下一周，管理层通过查看 Milestones 的状态即可完全掌握全局的进度，并且能很方便的通过查看 open 状态的 issues 追踪到出现问题的相关人员。
如何关联产品的需求<a id="orgheadline7"></a>
研发团队的工作是基于产品需求的，这些产品需求同样以 issues 的形式存在，但是可能会散落在一个个不同的代码仓库中。而我们的周 Review 是在一个公共仓库中进行。
显然，将不同产品的需求 issues 放在公共仓库里是不合适的，而且也不便于关联相关的代码。更不能在两边将相同的 issues 重复写一遍。
好在 Github 里每个 issue 不仅有一个相对于本仓库的内部链接，而且有一个全局的 URL 与之相关联。
有了这个前提，我们就可以轻易的解决这个问题了。只需要在周 Review 里把下周即将要开发的 issues 以链接的形式写进去即可。
由于 Review 是每周写一次， 而且每个周每个人能开发的 issues 一般也就三五个，因此写 Review 以及编辑其中的 issues 也不会成为什么负担。
总结<a id="orgheadline8"></a>
上述就是我们正在实施的 OKR 计划中涉及实际执行层面的的几个问题的总结，是针对前期遇到的一些问题的重新思考，随着执行的深入可能还会遇到其他问题，相应的解决办法也会持续更新到此文档。
<a id="orgtarget1"></a>
