最近又刷到 RSS的一些讨论，然后又说起 Google Reader 这个陈年往事。

Google Reader是谁杀死的呢？准确的说是个三哥 Vic Gundotra。默许这件事的是女高管 Marissa Mayer。（Mayer 后来去 Yahoo 当了CEO，干得最牛逼的事儿就是收购了 Tumblr，后来还有更抽象的从 teen 手上买了一套 Summly）

Mayer这名字让我想起之前看有本讲netflix的书提到过，是OKR推崇者。所以杀死Google Reader的凶器是 不是OKR或者launch culture呢？

我决定探究一下 OKR 的由来。这玩意的鼓吹群体，最后都指向 Intel出身的风投 John Doerr，他写了一本书叫 《Measure What Matters》，书其实不用看了，直接去他家官网，3分钟就能了解OKR的核心理念：

https://www.whatmatters.com/resources/a-typical-okr-cycle

我之前也经历过OKR，再次看这个东西有一些不同的感触：

• 管理层是不会全体公开自己的OKR的。因为管理层不用担责，也不想担责，也不敢担责。有一些 DAU 之类的指标能公开说吗？所以图里的第二步就是没有的，全靠下属去猜，猜错了才好挨板子嘛。
• 部门OKR或许可以公开，但是跨部门呢？保护得更严实了。子部门和小组之间就有样学样，最后OKR成了村骗乡，乡骗县，一级一级往上骗，一直骗到国务院。OKR里强调的跨部门整合，冲突协调，我没太见着，可能是level太低了。但是人性者东西嘛，既然都分部门了，井水不犯河水，为啥我部门有牺牲收益顺着你部门的指标走？有啥好处啊？你几个人几条枪，凭啥我就不能更少的人更小的代价完成同样的事？
• key result 强调客观指标，但是可观测性很多时候就是个取悦上级的play。记得有一次帮别的团队算“周均”指标，感觉基础数据查起来很麻烦，结果对方团队说，直接把日均加起来除以七就好了。而且必须得这么做，因为都是这么算的。后来咨询了下做SaaS的师兄，结果业界大概三七分，一大半都是拿日均直接套。给我吓尿了。
• Google的OKR实践开头就说一句话，不能直接套用，要按实际情况调整，你能套上去说明你做错了
• OKR里很强调 contributor 这个概念。啥意思？牛马就是执行者，不要多想。不要把自己当公司 partner 了
• committed 类型的OKR得分为1,必须达到1。aspirational的平均分应该是 0.7。但是实践中这挂靠很多待遇福利，使得如何设 OKR 成了一门花活儿
• Doerr 这名字起的好啊，行者。哈哈。
• 反对 Business-as-usual OKRs。万事万物都必须从用户需求侧推导。我觉得这一点很好
• 胆小aspirational OKR问题：愿景性OKR会倾向保守，出发点是，如果尚有余力，加一点运气，完成blah。实际有一个简单衡量标准(The litmus test)，如果你完成这项OKR，会不会大幅度超出用户预期？多年以后用户会不会因为这项OKR受益？
• Sandbagging。正如前面提到的和薪资福利挂钩，很多人会消减 committed OKR 目标。按照 Doerr 的说法，承诺性OKR是需要几乎耗光团队所有人力财力时间的目标才对。承诺+愿景 加起来应该超过团队能支配的资源。OKR这一工具是用来摸索团队执行力边界的。Doerr甚至说到如果每次OKR都能漂亮完成那说明团队在 hoarding resources or not pushing。我寻思，这也太资本主义了。哈哈哈。
• Low Value Objectives (LVOs) 不要追求“把CPU尖峰降低3%”。而是要反推，如果你这指标 1.0 完成，对 enduser 或公司效益有什么直接的促进作用吗
• 所有的KR合起来，需要构成对O的充分条件。如果所有 KR 都 1.0 分完成，那么 O 必将实现。这一点很要害啊，实践中很多KR也就是一些对自己有利的必要条件而已。估计很多团队也是对 硬骨头 避而不谈。OKR 这一工具的目的就是发现公司层面缺乏对“房间里的大象”的关注和投入的
• committed OKR以达到1.0为宗旨。如果团队达不到，那么需要尽早升级。升级不仅是常见的，还是必须的。无论是你对OKR不认同，优先级问题，还是有冲突，还是资源不够，管理层的义务是尽可能在OKR周期内发现问题并投入解决。
• 达不到 1.0 的committed OKR需要postmortem。Doerr说这样做不是为了惩罚团队，而是看到底是计划环节，还是执行过程中出了问题。但往往OKR更多的被用成敲打的工具？哈哈
• Aspirational OKR 可以长期保留，成为下一个周期的基础。如果没有进展就丢弃，说明要么你这目标设定有问题，要么优先级设定有问题，要么资源调度有问题，要么对事物的认知出了根本问题。
• Aspirational OKR在团队之间平移是OK的。manager不应该假设它们得到的支持永远是非常充足的。
• 简单衡量(The litmus test)：如果每个KR都是季度末最后一天完成，那么说明压根没计划。
• 如果重要团队职能没能在OKR里体现，就添加更多的OKR

OKR这一套的的祖师爷 是Intel 老总，匈牙利Holocaust难民 Andy Grove 。我看了下其实老爷子没把这一套说得那么玄乎，就是 8085 处理器当年需要每个季度出货，就搞了一套分摊生产的机制。这也解释了为啥OKR往往都是年度、季度为单位的。因为财报也是这个节奏嘛。他举例说，O是Intel芯片占领中端市场，那么KR就是8085 处理器 10个 新设计。我寻思这也不能必然支撑“占领”这一目标啊？万一市场不认帐怎么办？老爷子又说了，KR可以是 milestone，这一波不行下一波继续加码不就行了🤣 主要是“占领”这一说法是可以argue的，但是10个就是10个，结果只会是达成是否yes/no，可以 measure 的。

这篇讲OKR渊源的文章里，有一句话说得特别好

OKRs overturned the top-down management system. Suddenly, workers were valued by what they accomplished, not by their background, degree, or title. With OKRs, execution is more important than mere ideas,
OKR改变了人们马首是瞻的管理模式。员工的价值衡量以完成目标为准，而不再是背景、学历、职衔。OKR体系下，执行比畅想更重要。

那么话说回来，为啥OKR 杀死了 Google Reader？

因为 Larry Page 给全公司定的 O 是：亿级用户用户，越多越好。要做 google-scale 的产品

Google Reader受众是一小撮核心用户，虽然 engage 很高频，但是小众爱好的增长就是慢。当年 Google+ 势头被三哥吹上天，显然更有前途。Marissa Mayer是G家老人了(工号#20) 做 OKR 有一手，Google Reader显然是一个 business-as-usual 成熟产品了，所以开发团队都被挪用了，人都跑光了，据说它代码还不能跑在新款Google软件架构上（borg之类的），所以越来越没人关心。因为没人能靠Google Reader升职加薪，所以成了弃子。

说 OKR 🔪 了 Google Reader ，不是说 OKR不好，而是OKR作为一个框架，一套工具，它是中立的。

OKRs help you hit every target — except the one that matters.
OKR确保你命中目标，至于是不是重要目标就不得而知了

或许Google Reader真的对于Google不重要。但是反过来，没有 Google Reader 真的对Google那么重要吗？G家还做了那么多 arts project 怎么就不砍掉呢？

所以我琢磨下来，OKR这套工具，在蓝海市场，销售向的行业里是非常有用的。它能聚焦业务，保持各团队对齐，排查执行环节问题是非常有效的

但前提是，你只缺执行吗？

另一个方面，对于 SRE 安全这类部门来说，它们的成功不在于本部门 执行有多好，而是在于其他部门的「下限」有多烂。有哪个敢给自己定一个全年100%不出漏洞不出问题的O？

这类 support, maintanence 和 backoffice 部门，本来就就是降低负收益，处理烂摊子的，它们存在的意义，就是把公司的潜在损失尽可能降低到最小

这个出发点来说，是不是应该把OKR设置成默认 -1.0 分，然后擦屁股得越干净越好？

胡思乱想又水了一篇，大家别当真