Day 26 KPI还是OKR？Vol.2

欢迎光临Python百货，我是楼管 小笠宏树，祝各位客人今晚都能挑到你要的商品～

来个我喜欢的团
Foo Fighters. Walk.

OKR

定义

OKR(Objectives and Key Results)全称为“目标和关键成果”，是企业进行目标管理的一个简单有效的系统，能够将目标管理自上而下贯穿到基层。（from MBA智库百科）

以软件来说就是不定细节，而是定义大方向，然後从上至下去各自定各自的目标，只要下层的目标跟上层的目标是一致的就好，举个例子来说，整个专案的Ｏ可能是要让程序码更简洁，因此KR可能就会是将专案的Kotlin比例提高，减少程序码的数量或Size，而接下来不同的Class会订出自己的作法，比如有的较旧的Class就很直接，就会是将Java转成Kotlin，而另外一些更改过多次的Class可能就是要将没删乾净的地方删掉。

失败案例

KR太过模糊

有时候老板在定OKR的时候会不知道怎麽下手，但又为了能符合每个部门的
情况，所以就给了一个很模糊的OKR，比如：O是要做出个好的产品，KR是带来更多的顾客，这种情况下面的部门也会无所适从，不知道该如何定义自身的OKR。

软件版举例：「O要写Clean Code，KR让看得懂的程序码增加」，工程师表示谁先来给我定义「看得懂」先，谁「看得懂」，怎麽叫「看得懂」？

太过明确

当老板订了一个过於限缩的OKR的时候也会是一场灾难，一开始设计O的目的就是为了可以有模糊的空间（这个是为了因应KPI由上层去订下层KPI容易考虑不周的缺点），让下层的部门可以自由地去选择他需要前进的方式，举个例子：今天假如公司订了一个OKR是让业绩量变两倍，那全公司大概只有业务部门知道自己的OKR是要定什麽，其他部门大概就是定业务不需要什麽就支援什麽。

软件版举例：「O要让程序变得更小，KR是让拔掉User可以更改头像的功能」，这....就没有定的意义了，太精确了已经失去了原本定OKR的好处，不如直接当Task来做

O跟KR没有绝对关系

有时候会订出O跟KR没有实际相关或者是KR定的不够准确，举个例子：O可能是想要增加产品的知名度，KR是增加付费用户的数量，这个时候其实O跟KR不一定有直接相关，因此很容易造成下层的部门定自身OKR时会产生价值混乱，比如行销部门会想说我到底是要纯粹撒广告增加来客数就好，还是也要符合KR的冲付费用户的条件。并且在最好要确认完成的品质的时候也难以判断是否有确实得达成目标。

软件版举例：「O要让程序跑得更快，KR让程序码减少一半」，这两者之间是没有完全的正相关的，因此很容易会不知道该照什麽准则去订各自的OKR

明天会来讲个大胆的系列“微服务”