前言

这篇跟工程师其实没那麽有关，适合给新手leader定OKRs的时候看看。

演讲总结

今天要讲的主题是关於设定OKRs的一些trick。

OKRs是google在…开发的一套目标设定的系统，不清楚的同学可以看看原google官方介绍。

透过OKRs基本上可以达到以下目标：

• 设定目标
• 与团队达成共识
• 量化进度

而设定OKR看起来并没有很困难，你可以想像就是个填空题：「我们目标是，以 」

例如：我们目标是「code coverage从35%提昇至50%」，以「增加产品品质」。

看起来设定OKR是如此的轻松写意，但是实际上做起来却爆炸难。因此讲者在此演讲讲了三个建议（特别是对於那些刚使用OKR的团队）：

1. 无须设置个人OKR

   个人OKR通常会降低成员的效率，而且还没有不会有带来任何价值。甚至往往会变成一些实际的任务或micromanagement的工具。

   因此最好的解法就是不要设置OKR。

2. 忽略数字

   对於刚使用OKR的人，往往会遇到两个难题：

   1. 觉得重要的事情没被计算到。
   2. 大部分的KR的数字都是SWAG（a sophisticated wild-assed guess，一乱串复杂粗暴的乱猜）。没人知道为什麽是从预计提昇至50%，都只是乱猜乱估计。

   也因此数字在初期一点都不重要，应该更聚焦於产出（outcome）而非数字。

3. 避免由上而下的目标

   很多人会觉得应该OKR应该由上而下让整个组织有一致的目标，但为了做这件事其实会花费非常多的时间align。再者这件事其实往往会扼杀创意，大家会低估自己能带来的价值。管理阶层往往容易膨胀自己的价值，而员工阶层往往会忽视自己意见的价值。

   所以更好的作法其实是由下而上（bottom-up）的设计OKR，让员工们自己设定团队目标，也可能同时可以当成empower的工具。

个人心得

这篇因为是短篇所以没有讲太多的内容XD，而我自己也没有太多好的经验，如果有人知道有好的资源还请麻烦推荐给我m(_ _)m。

我自己是有不少感触可以理解订OKR到底有多困难，因为在我离职前一阵子公司有尝试开始订OKR。先姑且不论公司是如何执行这件事情，但我个人是遇到蛮多问题的XD。就像上面所说的数字订法要怎麽订真的是非常困难，例如到底test coverage应该要提升到70还是80真的完全是乱猜。

关於订OKR到底要由下而上还由上而下，我自己遇到的状况是，因为组织策略其实不是很透明，所以由上而下的意义不大，这走的好像也只是个形式而已。但当我们想由下而上来订时，却又被要求要与组织的align。或许就像讲者说的其实应该要直接是由下而上，而不完全需要与组织align是比较好的选择。

而自己也遇到了蛮多问题例如OKR到底是不是代表一种评监方式？OKR订太多还有意义吗？如果上层的OKR订的不好该怎麽办？等等其实我也不知道怎麽样做比较好的事。或许这还是需要多一点的实际经验看其他公司的正确使用姿势，才会比较会有帮助。