前言

OKR 是由前 Intel CEO，安迪·葛洛夫 構建的基本框架。

全稱是：「Objective - Key Result」，既強調「目標」與衡量目標的「關鍵結果」

它是一套管理目標，讓目標能落地的工具。
它在硅谷科技公司中廣為人知，并被世界各地的許多組織采用。
它可以應用在組織中，也可以應用在個人的生活中，就像一種思考的模式。

過去兩年多的 OKR 實踐，有一些體會。
作為一個程序員，會自然的去尋找一個工具的最佳實踐。

于是，有了這篇文章。

基本原理

OKR 原理很簡單。

要用好 OKR，我的理解，需要把握三個核心：

• 目標
• 關鍵結果
• 過程管理

它們分別回答了三個問題：

• 應該做什么？
• 如何衡量做到了？
• 怎么落地？

然后，思考 OKR，我認為還需要 cover 到兩點：

• 看得到的結果
• 說得出的價值

先拋一個不好的例子

來自于我曾經定過的一個 OKR：

O: 持續學習，提高自身戰斗力

• KR1: CSS3 學習，閱讀《CSS揭秘》產出閱讀筆記。
• KR2: 提高英文閱讀能力，閱讀《Security Your NodeJS Application》，產出一篇譯文。
• KR3: 對 Eggjs 或 Vue2 框架的源碼進行解讀，產出一篇源碼解析。

我想先按順序來講講「目標」、「關鍵結果」、「過程管理」。
然后，再回過頭來，看看這個例子為啥糟糕，可以怎樣修改。

目標 Objective

欲望讓我們起航，但只有專注、規劃和學習才能到達成功的彼岸

組織的誕生

回到最初的時候，一個組織的誕生，絕大多數情況是由于一兩個人的想法，然后以此為中心，開始聚攏更多有共同目標的人加入進來。

1976年，喬布斯成功說服沃茲尼克組裝機器之后再拿去推銷，他們的另一位朋友韋恩隨后加入，三人在1976年4月1日成立蘋果電腦公司。最初，Apple 僅僅是在賣組裝電腦。

1996年，佩奇和布林在學校開始一項關于搜索的研究項目，開發出了搜索引擎 PageRank，后續改名 Google。最初，Google 僅僅是一個搜索引擎。

組織的使命

隨著組織發展，人員壯大，這個能聚攏人的目標，必須要看得遠。然后這個目標提升到用另一個詞來形容 —「使命」。

Apple 的使命：「藉推廣公平的資料使用慣例，建立用戶對互聯網之信任和信心」
Google 的使命：「整合全球信息，使人人皆可訪問和收益」
阿里巴巴的使命：「讓天下沒有難做的生意」
有贊的使命：「幫助每一位重視產品和服務的商家成功」
以及最近我們團隊的前端技術委員的使命：「以極致的技術高效支撐業務」

使命描述一般都很簡潔，并且容易記憶，像一句廣告詞，能深深的刻在腦海里。
在工作中遇到問題的時候，這個使命就會一下子從腦海里蹦出來指引你找到答案。

其實在某個市場閑逛都有可能讓你意識到這個市場有某個問題需要解決，而幫市場解決這個問題，就是一個使命。

階段性的目標

為了一步步的達成「使命」，我們需要有目標。相對于使命，它粒度更小，且有時間限制。

所以，目標（Objective）應該：

• 是階段性的
• 是有優先級的
• 它需要能明確方向且鼓舞人心

目標，是 OKR 中最重要，最需要想清楚，最首要確定的。
在這里，需要回答：你有什么？你要什么？你能放棄什么？

重要與緊急

「魚與熊掌不可得兼」，所以我們要有所取舍，事情排個優先級。
「重要-緊急象限」是一個不錯的指導工具，第一次看到它是在柯維《高效能人士的7個習慣》中的第三個習慣「要事第一」。

重要-緊急

但在實施的過程中中很有可能會遇到這樣一個問題，緊急不重要的事情很緊急，總需要花時間和精力去處理它。然后重要不緊急的事情，會常常分配不到時間和精力。

那么就讓重要不緊急的事情也變得緊急起來。

目標需要自上而下的關聯

如果基礎的商業問題沒有解決，不論實現多少產品功能，團隊整體的績效一定會大打折扣。

在一個組織中，如果沒有充分的理解上一層的目標，就很容易跑偏，沒有真正在刀刃上使力，造成效率上的浪費。

達到充分的理解目標，是有難度的，對人的眼界、目標理解能力有很高的要求。這不僅僅是執行者責任，更是管理者的責任。

關鍵結果 Key Result

衡量目標是否達成

目標定下來了，如果不去執行和落地，那么它永遠就只是一個目標。如何去衡量目標是否達到了，就是「關鍵結果」的任務。

在互聯網產品中，通常可以量化的條件有：用戶增長、用戶激活、收入增長、產品性能、產品質量。

作為技術團隊，會更加集中注意力在產品性能和產品質量上面，那么如何去找到這些方向的衡量指標，就要從實際出發了。

比如我們團隊會用「質量系數 = BUG數/估時」，來感受一個項目的質量情況。雖然它會有些漏洞，但如果建立在互相信任的基礎上，可以提供一定的參考價值。

有些挑戰性

當達到成結果的時候，我們應該是歡呼雀躍般的興奮，而不是理所應當的淡定。

定下一個關鍵結果之后，問一下自己，有多少信心可以完成。如果信心爆棚，就把目標定高些。如果信心不足，就把目標調低些。因為 OKR 的意義不在于完成目標，更重要的是它能挖掘團隊以及個人的潛力。

如果覺得有必要的話，我們可以建立一個「信心指數」，用來幫助確定結果有足夠的挑戰性而不會讓人失去信心。這個指數的開始值最好是 50%，然后通過過程管理來動態變更和追蹤。

比如去年我負責的一個「優化微信小程序加載性能」項目中的關鍵結果：

• 首屏加載時間 3s 內

未優化的加載時間是 6s+，回顧當時對目標的信心指數的話，大概是 20%。雖然最后因為部分不可控因素沒有達到這個目標，只能維持在 3s-4s 之間。但是這個過程中能讓人費盡腦汁的找到各種方法，大幅的提升了除首屏加載以外其他方面的加載體驗，這也是額外的收獲。

作為管理者，你要清楚的知道哪些人推一推會有更高的產出，哪些人實際執行情況會出現問題，要能看得到看得懂目前組織的目標和進度，并與成員進行同步。

過程管理

OKR 定下來了，在期限內，就要奔著目標努力奮進。盡管中途發現問題，也盡量不要在中途更改 OKR，讓我們盡力跑完計劃的階段再回來總結。我們也可以把時間維度切小，比如把年度切分為半年度，把半年度切分為季度。

并且，目標定下來之后，要經常定期共同回顧，共同看見。而不是定下來了，就放在那里，否則過程中團隊發生了問題，成員遇到了困難，很大可能會不被看到。

比較好的形式是每周都一起坐下來看看，每個人分享一下成果，或者說說遇到的困難，看能不能得到其他人的幫助。這個過程，能及時的看到問題，也能讓成員對目標有更強的參與感。

那么，OKR應該以什么方式來呈現？《OKR工作法》一書中提供了一種參考：「四象限呈現形式」

四象限呈現

• 第一象限：本周3-4件最重要的事情，并且進行優先級的排序
• 第二象限：把OKR內容羅列出來，關注和更新每一項KR的信心指數
• 第三象限：未來中長段時間中的計劃，能讓我們稍微看遠一些。
• 第四象限：關注那些影響目標的關鍵因素會不會掉鏈子，例如團隊狀態，系統狀態等。也可以用紅藍黃顏色表示出來。

回過頭看看那個糟糕的例子

糟糕的例子：

O: 持續學習，提高自身戰斗力

• KR1:CSS3 學習，閱讀《CSS揭秘》 產出閱讀筆記。
• KR2:提高英文閱讀能力，閱讀《Security Your NodeJS Application》，產出一篇譯文。
• KR3: Vue2 框架的源碼進行解讀，產出一篇源碼解析。

這個例子的背景是我 2017 年 4 月份加入到有贊，當時定的試用期內的其中一個目標。那時是我第一次認識和使用 OKR，只是單純的把自身的技能提升計劃給羅列了出來，看起來更像是一個 Todo List

現在回過頭來看這一份 OKR，有不少問題：

1. 目標沒有描述出來價值，提升了自身戰斗力，然后呢？并沒有自上而下的關聯團隊和組織的目標。所以從目標上，就已經走偏了。
2. 假設目標正確，KR 也沒有起到能衡量目標是否達成的作用。例如 KR1 完成了，對目標的推進，并沒有說服力。
3. 最后把 OKR 用成了 Todo List。

那么我們從目標開始分析，當時作為一個新人加入到一個新的團隊，對團隊的技術棧和項目都很陌生，需要填補部分空白，快速上手。所以提升自身實力的底層訴求是：快速上手，勝任開發工作。

然后怎么衡量目的達到了呢？我們可以通過項目質量直接衡量，通過項目的熟悉程度來間接衡量。

修正后：

O: 快速上手，以專業的姿態勝任開發工作。

• KR1: 質量系數平均在 0.3 以內。（質量系數 = BUG數/估時）
• KR2: 代碼評審評分平均 3.5 以上。（我們有 Code Review 機制，并且有評分環節）
• KR3: 所參與項目評分在 4 以上。（項目也有評分環節）
• KR4: 進行兩次的項目分享。

那么如果達到這些關鍵結果，要通過學習框架，還是研究項目，還是熟悉業務，那就是根據實際迎刃而解的事情了。

最后

凡事預則立，不預則廢 ——《禮記·中庸》

最后要注意的是，OKR 只是一個工具，當你有一個目標，它會給你一種落實目標的方法論。而如果一開始目標沒有想清楚，想明白，那就很容易在錯的路上越走越遠。

每個團隊都會有不同的風格，和不同的實際情況。理解方法和工具的原理，明白這么做是為了解決什么問題，然后再調整定制真正適合此時此刻的團隊，才是最好的方法。