小骏是一名管理咨询公司的顾问。接到了一个这样的CASE
现象：一家创业公司在做OKR，却硬生生的把OKR做成了KPI。
背景：为了避免不必要的麻烦。以下简称这个咨询公司为V公司吧。公司的大老板是个互联网技术大牛（一般都说自己老板是大牛，到底牛不牛，小骏非技术出身不得而知。不过据我猜测应该比小骏的好朋友翠花强不了多少），就是那种敢想敢干的那种类型，做事雷厉风行但是做事不够仔细却要执行力的那种。整个公司整体员工的素质其实也比较差的那种。
现场：小骏到了公司之后发现公司推行了OKR之后只是老板说了一句。技术部门的领导……好吧，这个公司没有技术部门负责人。五六个leader都是同级！老板你咋想的？没有负责人。这几个leader不内斗？在你面前装的人五人六的，团队协作。但是遇到涉及到自己利益的事儿没人协调面和心不和。然而，更奇怪的事情还在后面呢。整个公司推行OKR，只有产研部门推下去了。其他部门连个绩效考核标准都没有。不过好在业务销售部门还有KPI。
小骏在各个技术团队中了解到，公司没有对于OKR的培训。几乎每个员工对于OKR的理解不一样。多数人认为OKR的计划就是KPI，不能完成就是绩效不达标。
好的OKR是公司制定OKR，管理层拆分。HR部门制定团队管理等问题。销售业务部门负责卖钱。产品部门负责做出用户满意的产品。研发部门负责产品质量。
结果V公司倒好。产品和研发背负业务指标，研发Leader制订计划。一线员工只负责开发完全没有自主权。而且制订的都是一定完不成的KR和计划，完成不了就要扣除绩效。而且这些研发leader也是够狠，不只对自己手下下手狠，对自己也是下手超级狠。自己定的计划本来就是完不成的计划，而且是只有1%可能性完成。的。。。。
有的部门是以月为单位定的O。而且一个月要完成3个大O！对于每一个OKR的呈现是以一个二维表的形式呈现。表头日期（以周为单位）列头（KR，没有量化指标）以及计划。
例如：
O1：最挣钱的项目交付
KR1：曼哈顿项目的上线（原子弹的脾气啊，有魄力）
P：
第一周：设计接口，评审；
第二周：开发；
第三周：测试；
第四章：上线。
KR2：阿波罗项目的开发（你这是要上天吗）
第三周：设计接口，评审；
第四章：开发。
小骏也不敢说什么，就把之前读的《OKR工作法》写个读后感吧。
OKR要以一个四象限呈现。
第一象限：OKR
第二象限：本周计划
第三象限：本月计划
第四象限：当前状态
例如当时TeaBean公司四个象限定的OKR是这样的
注意的是，
O - 是不能用SMART原则来制定。制定的要点在于能鼓舞士气，却无法评定的；
KR - 制定的要每一项都有50%可能性能完成；
本周计划 - 只列出P1和P2。至于这种奇葩的互联网公司居然非得让我说P0和P1我也忍了；
最终小骏放弃了这单生意。这活干不了，不会干。我觉得我还是找我好朋友翠花学学前端吧。小骏要转行了！
图片来源于网络，其实小骏这个CASE完成的很出色，为了戏剧性才会说这样的结局。还有就是这个CASE已经得到公司同意。切勿对号入座
