關於 OKR 的一些方法論

歡迎來個人博客閱讀：關於 OKR 的一些方法論

前言

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 只是一個工具，當你有一個目標，它會給你一種落實目標的方法論。而若是一開始目標沒有想清楚，想明白，那就很容易在錯的路上越走越遠。

每一個團隊都會有不一樣的風格，和不一樣的實際狀況。理解方法和工具的原理，明白這麼作是爲了解決什麼問題，而後再調整定製真正適合此時此刻的團隊，纔是最好的方法。