[read]这就是OKR-outline


=Start=

缘由:

整理一下最近在家看的《这就是OKR》一书,方便以后回顾参考。

另外顺便多说几句其它的——因为在微信读书中看到有条评价是『这本书的核心内容不在正文,而在附录中』,刚开始没啥想法(甚至还觉得评价得挺对的,因为确实如他所说,本书附录内容的知识密度很高,比如:谷歌公司的内部OKR模板、典型的OKR周期、四大利器、沟通绩效等总结在附录中都有,而且基本没有废话,全都是一些总结性的文字——该怎么样,不该怎么样),但我在快速看完了附录的几个资源之后,再去看网上其它介绍、评价和总结此书的文章时,明显能感受到那条评价的错误之处。我大概写一下我为什么会这样想:

1、首先,这是一句「废话」。因为大多数技术介绍/说明性文章的行文结构就是【总分总】的形式,刚开始来个提纲挈领的总结,帮你把握全书的目标和重点;然后在正文中条分缕析的说明和印证它在开头的结论,方便不同背景的人理解和记忆;最后再来一个整体的总结,再次强化重点和结论。文章的行文结构就注定了在总结形式的附录中存放的就是精华。

2、其次,这句话可能对之前没有看过此书的人「产生误导」。因为对于大多数人来说,可能都没有作者的经历和背景(尤其是在业内属于传奇性的人物),如果一上来你就按别人说的只看作者给出的最后总结(然后还以为自己这么快就get到了该书的精华),按我以往的经验来看,你大概率会有这么一段经历:

  • 看的时候——嗯,说得很对,说得太对了,作者真牛逼,不愧是大佬!
  • 合上书之后——唉,这本书讲的真好,看了此书之后感觉自己有如神助、功力大增,我要像作者一样牛逼了!
  • 过段时间之后——咦,那本书具体讲了些什么(忘的差不多了,也可能从来就没有记得过)?结论是什么(可能还可以想起来一些经典的片段)?为什么会有这样的结论、现实中为什么不是这样(一头雾水,一脸懵逼)?
  • 再过段时间之后——如果有人问起你是否看过这本书,你可能都不知道怎么回答?说看过呢,好像也就重点看了结论,而且现在结论好像也记不清了,别人万一问起来回答不上来就丢脸了;说没看过呢,我当时好歹也是花钱买了书,花时间看了书的。

3、再说说我为什么会有上面的想法。一方面是因为我确实有过上面这种尴尬的经历和经验(翻书而不是看书,重数量而不重质量,只看不实践……),另一方面就是在有过这类经历之后我去反思以往的行为,还有就是看一些和你谈如何阅读一本书/一篇文章的经典书籍和网络问答,想起了以前读书的时候经常听到的一句华罗庚先生留下的忠告『把书读厚,再把书读薄』。按我自己的经验理解就是,经典书籍里面包含的知识量其实是极度浓缩过的,如果你想读透,就必须先逐字逐句的解析,结合作者当时的大环境,同时把自己代入进去感受;再结合当前的环境以及你自己的背景和经验,想想这对当代的启发有哪些(这一步可能会反复多次,因为经典书籍常读常新);这么几个步骤下来,原本薄薄的一本书,你可能会花上很久的时间,同时为了理解书中所写,你还需要不断的参考其它的书和内容,这就是一个把书读厚的过程;之后,你参考了这么多的内容,再结合自己的实际情况,整理总结一下自己从本书中得到了什么知识和启发,写了一篇类似于读后感的文章,然后在日常的生活中不断去实践优化,有了自己的一些心得体会(通常很简短且易于理解),这就是一个把书读薄的过程。如此一个过程下来,周期不短,很少有人会有如此的耐心去做,但一旦真的这么做了,收效也是极大的。

4、最后再说一下我觉得这句话可以改进的地方。因为现在大家的工作生活节奏都很快、都很忙,读书有时候也成了一件比较功利性的事情,这样无可厚非,不同人的目标不一样;但对于那些想多收获一些东西的人来说,前期时间紧的时候,可以先抓书的结论/核心内容,方便自己有个大概的理解,起码能快速上手;后期有实际需要了,再结合正文或是其它一些之前觉得不重要的地方重点研究,这种带有明确目标的读书方式效率也是极高的,效果一般也挺好。

以上是我的多说几句。

正文:

参考解答:

如果你不知道目的地在哪里,你可能永远无法到达。

想法很容易,执行最重要。


OKR的四大“利器”:聚焦、协同、追踪和延展。

FCTE:
Focus and commitment
Cooperative and connection
Tracking
Extend

利器1——对优先事项的聚焦和承诺(第4章、第5章和第6章):高绩效组织应该聚焦重要的工作,同时清楚什么是不重要的。领导层面临艰难抉择时,OKR可推动其做出选择。对于部门、团队和个人来说,OKR是一种精准沟通的工具,能消除困惑,让我们进一步明确目标,聚焦到关键的成功要素上。

利器2——团队工作的协同和联系(第7章、第8章和第9章):OKR具有透明性,上自首席执行官,下至一般员工,每个人的目标都是公开的。每个员工都将个人目标与公司计划紧密地联系起来,进而明确两者之间的依赖关系,并与其他团队展开通力协作。这种自上而下的协同,将个人贡献与组织成功联系起来,为工作赋予了特定的意义。自下而上的OKR,则通过加深员工的主人翁意识,促进了个人的参与和创新。

利器3——责任追踪(第10章和第11章):OKR是由数据驱动的。定期检查、目标评分和持续的重新评估可以让OKR充满生机——所有这一切都是基于客观、负责的精神。危险的关键结果会引发某些行动,应使其回到正轨,或者在必要时对其进行修改或替换。

利器4——充分延展进而挑战不可能(第12章、第13章和第14章):OKR激励我们不断超越之前设定的各种可能,甚至超出我们的想象力。通过挑战极限和允许失败,OKR能够促使我们释放出最具创造力和雄心的自我。


上 篇

第1章 当谷歌遇见OKR
第2章 OKR之父

目标管理的先驱
量化产出
英特尔的命脉
格鲁夫:OKR的实践者
格鲁夫留给我们的

第3章 “粉碎行动”——英特尔公司的故事

转瞬之间
更高的目标

第4章 利器1:对优先事项的聚焦和承诺

在一开始的时候……
清晰沟通
关键结果:关心和支持
做什么、如何做和何时做
匹配关键结果
完美与优秀
少即是多

第5章 聚焦:Remind的故事

推特教育
利用种子资金扩大规模
成长目标
OKR留给我们的

第6章 做出承诺:Nuna医疗科技的故事
第7章 利器2:团队工作的协同和联系

保持协同
伟大的层级与关联
沙滩独角兽公司:梦幻橄榄球队
激活基层
跨职能协调

第8章 协同:减肥宝的故事

跨团队融合
未确认的依赖和增强
对准北极星

第9章 连接:财捷集团的故事

来自云端的实时数据
全球协作工具
横向连接

第10章 利器3:责任追踪

OKR导师
时时追踪
总结:清零与重复

第11章 跟踪:盖茨基金会的故事

使目标具体化

第12章 利器4: 挑战不可能

我们需要挑战
“10倍速”原则
挑战性目标的调整

第13章 延伸:谷歌浏览器的故事

新的应用平台
重新定位浏览器
升级目标
深度发掘
尝试失败,尝试成功
下一个前沿

第14章 延伸:YouTube的故事

当你不能打败他们时……
巨石理论
更好的衡量标准
“观看时长”是最重要的衡量标准
制定不可思议的“数字”目标
设置挑战性目标的规则
加快进度
相互支持
学会宏观思考

下 篇

第15章 持续性绩效管理:OKR和CFR

重塑人力资源管理
“友好”分手
对话
反馈
认可

第16章 抛弃年度绩效评估:Adobe的故事
第17章 每天烘焙得更好一点:Zume比萨的故事

设定能够实现的目标
更严肃的纪律
更积极地参与
更高的透明度
更团结的队伍
更优质的对话
更开放的文化
更卓越的领导者

第18章 文 化
第19章 文化改变:Lumeris的故事

人力资源变革
OKR的“复活”
透明度是“毋庸置疑”的
“推销”未完成的目标

第20章 文化变革:波诺的ONE运动

向自己挑战
与OKRs一同成长
以客户为中心
衡量热情
OKR是一种思维方式

第21章 未来的目标

致 敬

资源1 谷歌公司的内部OKR模板
资源2 典型的OKR周期
资源3 沟通:绩效对话
资源4 总结
资源5 延伸阅读

参考链接:

这就是OKR
https://book.douban.com/subject/30396635/

21张思维导图读懂《这就是OKR》
https://book.douban.com/review/10233539/

https://www.whatmatters.com/

=END=


《“[read]这就是OKR-outline”》 有 1 条评论

  1. 技术开发人员如何制定自己的OKR
    https://mp.weixin.qq.com/s/KIqFe2SGtJM58CyPZPRTPw
    `
    最近是Q2刚开始,又到了制定季度OKR的时候了,我发现很多技术开发小伙伴依然不知道怎么制定自己的OKR。要么就写“持续做每个迭代”,要么就“持续维护某个系统”,要么就是“积极响应产品需求”。

    前提:这里假定你对OKR已经有了一定的认识,假定你已对OKR制定要遵循的通用原则SMART比较熟悉。

    # 技术OKR为什么难写?

    好多技术主要是跟迭代做需求。这时候想的是我只要按时把需求完成就可以了。但日常迭代本来就是你应该做的事情,你应该去想你如何才能更好地更快地完成你的工作。由于技术OKR不像业务OKR有明确的业务指标且最终是指向用户价值的,久而久之技术OKR有时候就会沦为形式。这些形式化的OKR其实没有任何的指导意义,反而浪费大家时间,这样的OKR要趁早删掉。

    # 全程“虚词”,没法衡量

    技术OKR和通用OKR一样不能只有虚词,要有可衡量的指标或者数据。全程“持续、大力、全力、快速”的话,复盘的时候你自己都不知道怎么衡量“全力”是使出了多少力气。这些虚词可以有,但也要附带可衡量的内容。要么是上线个什么功能,要么是把目前存在的什么问题给解决掉,要么把某某的xx率提高到多少?要么是持续做某件事几次。总之得有个实际的内容可以衡量。

    # OKR制定原则

    * 设置O的原则
    O要制定的有挑战性,要有远方的感觉。

    * 设置KR的原则
    1. 能量化尽量量化 :就是要有数字指标。
    2. 不能量化要细化:不能量化的你就写工作内容本身。
    3. 不能细化要流程化:有的工作内容是重复性很高的工作。程序员有时候会时不时的接到一些类似取数据的工作,那么这些工作怎么体现在OKR里呢?这时候你可以把这个取数工作给流程化、文档化,这样就能体现出你的价值了。
    4. 明确完成时间。最好明确完成时间,这样你的关键结果更具体。比如:4月5日前完成xxx项目上线。

    # OKR参与原则

    本着自下而上和自上而下相结合的原则。有的公司的OKR完全是自上而下对齐结果,这样就会让一线员工没有参与感,也不鼓舞人心。所以自下而上的OKR比例至少占到40%。先让每个员工自己去盘点当下遇到的问题,我们要去往哪里,然后把这些写入自己的OKR。这样做的另外一个好处就是,往往一些细节上的问题只有操作者自己才知道的,通过这样的方式让整个企业运作在Deep Dive的层面。

    # 日常类重复工作怎么写入OKR

    这个是很多人经常提到的问题,所以这里专门说一下。对于日常持续重复的类似取数等工作,自己可以写把脚本文档化之类的,总之就是让重复的事情变得尽量不去重复,甚至提供一个通用的能力让这些事情花的时间更少,对于这类日常工作可以考虑遵循DRY原则来制定你的OKR。

    # 可以参考的几个OKR制定方向

    下面给大家提供一些不同方向的技术OKR思路供参考:
    1、功能交付类。比如上线某个项目或某个功能等;
    2、性能优化类。比如当下你的项目某些API性能较差,可以写降低某某API响应时间从300ms到200ms等;
    3、代码优化类。比如完成xxx模块的重构,抽离xxx组件供所有模块使用等;
    4、代码质量类。比如线上bug小于1个等;
    5、迭代交付类。比如迭代交付平均周期小于8天;
    6、技术文化类。比如至少输出5篇技术博客,至少做3次技术分享;
    7、指标完善类。比如增加bug来源字段到bug统计中等;
    8、组件开发类。比如至少20个业务方接入;
    9、团队管理类。比如至少3人轮岗,每周与一位技术小伙伴对话,培养1-2位自驱闭环的产研负责人等;
    10、规范标准类。比如制定CodeReview规范。

    总之你就记住一个原则:当下存在哪些问题,你要去往哪里。这样你就不愁你的OKR写不出来了。
    `

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注