前言<a id="orgheadline1"></a>
最近开始在公司内尝试使用 OKR 的思想进行管理，收获了不少心得，也遇到了不少困难。现在进行一个简单的总结。 OKR 的介绍见文章最后的参考链接。
我理解的 OKR 的益处<a id="orgheadline6"></a>
对整个公司的灯塔效果<a id="orgheadline2"></a>
OKR 管理制要求公司每年、每季度都要确定一套 OKR，而且数量有严格的限制，最多有 5 个 O，每个 O 最多 4 个 KR。这意味着它确立了公司一整年的最核心的战略，避免了做那些与核心战略无关的事，提高整个公司做事的效率。
公司战略的重要性无论如何强调都不过分，很多创业公司失败最主要的原因就是战略方向一开始就错了，战略错了战术上再怎么努力也无济于事，甚至会加速失败的过程（不过对于创业来说，快速失败也是一件好事）。
对于公司的核心管理层来说，这一点尤为重要，创业路上诱惑太多，哪个方向看起来都很好，如果不能找准自己的位置和方向，别人做什么你也跟着做什么，失败是 100% 的。
而对于员工来说，这一点也很重要，有很好的主动性的员工本来就很少，而具有主动性同时又能很好地规划和执行自己工作的员工更是少之又少，这种情况下花点时间好好地制定出一份 OKR，不管对于员工还是公司，都是有百利而无一害的。
挑战性<a id="orgheadline3"></a>
OKR 要求目标要有野心，有时候甚至要有些不舒服（按照谷歌的说法，Achieving 65% of the impossible is better than 100% of the ordinary）。中国古人说“生于忧患，死于安乐”，也是类似的道理。
其实，很多人也有亲身的体会，往往在适度的压力面前，自己的潜能就会被激发出来。而一旦长时间很舒服，回过头来看，往往没什么成绩和成长。
主动性<a id="orgheadline4"></a>
OKR 建议 60% 以上的目标是自下而上提出的，100%的目标都是协商并同意的，不能是命令。也就是说更多地鼓励员工自己找到问题，解决问题。这个做法有两个好处：
- 找的过程本身就是一个学习、提高的过程，只会执行的员工其实并不缺，缺的是能发现问题并主动去解决的员工；
- 如果这个目标是自己主动想要达到的，那么往往更容易达到；
公开性<a id="orgheadline5"></a>
所有的 OKRs 都是对所有人开放的，开放意味着最低的沟通成本、最容易形成合力（多人抬重物的时候要喊着号子也是同样的道理）。开放还意味着时时处处都能看到，不断的刺激你的神经，就像千篇一律的新闻联播一样，不知不觉我们就被洗了。当然，与他们不同的是，我们的目的和结果都是双赢的。
问题<a id="orgheadline9"></a>
OKR 虽好，但不是那么简单就可以实施得起来的，我们在执行时就遇到了一些问题，
OKR 的量化问题<a id="orgheadline7"></a>
我们是这样执行的，提前一两天让大家看了一下 OKR 的资料，周五下午开会讨论公司存在的问题，会上很多人都准确的指出了问题所在，说明员工都是非常具有观察力的。
就着这些问题，我们紧接着分析了 OKR 对于解决这些问题的意义，从而达成了全面启用 OKR 计划的共识。
下一步就是如何实施了。大家利用周末的时间自己总结个人的 OKR，等到周一上午陆续收集上来之后发现一个非常普遍的问题，那就是几乎所有人都没有将 KR 定量。
我曾试图着帮助几个员工重新梳理他们的 OKR，但是最终发现，对于研发团队成员来讲，梳理出来的称之为“OKR”的东西其实更像是产品需求，我认为好的 OKR 不应该是这样的，需要重新思考一下这个问题：
- 在个人季度 OKR 里勉强地把一个个具体的“产品需求”定为目标显得很牵强，因为非常不容易定量，这种感觉肯定不是 OKR 的初衷
- 具体的产品需求本身应该只存在在产品需求文档里，OKR 应该是对产品需求的实现结果进行量化的评估，而不是对需求本身做要求。
周 Review 的形式问题<a id="orgheadline8"></a>
OKR 里只说需要定期的 Review，并描述好“目标，进度，遇到的问题，问题原因，下一步计划”这 6 个方面的问题。除了第一个“目标”问题不太确定其意义，其他问题从字面上可以理解和回答。
但是以什么形式汇报并没有讲。没有更好的方案前，我们先用 Excel 表试验了一个周。很快发现这种方案有几个问题：
- 不够开放
- 不方便集中浏览
- 不方便基于问题进行讨论
- 不方便反复修改
那如何解决这个问题呢，我搜索了一遍相关的 APP 工具，协同工具（Worktile、明道之类的），但是似乎都不怎么适合，而且上一套新的协同工具是要非常慎重的，它带来的是所有员工的学习成本。
那能否从我们现在正在用的工具方面想想办法呢？我们目前正在用 Github 做代码管理，众所周知，Github 的作用并不仅限于代码管理，它在团队协同、需求管理、bug 管理、文档管理等方面都有不错的实践。
经过一番摸索，果然找到了一套逻辑上非常吻合的 OKR 实施方法。我的下一篇文章基于 Github 的 OKR 实施方法以及企业协同方法将详细解释。
<a id="orgtarget1"></a>
