谷歌OKR指導手冊 (譯)

這是一本關於 OKR 迷你小冊子，名爲《google OKR playbook》，由 www.whatMatters.com 網站發佈。 該網站由John Doerr 團隊經營， 而John Doerr 正是 1999年將 OKR 引入 谷歌的那我的。

本文僅供你們學習參考，雖然文章較長，但值得一讀，歡迎收藏。

文章的末尾有一些 8 道自我測試題，用來驗證你的OKR是否在正確的實施。

若是你正實施OKR，能夠用它們來驗證一下吧～

在實現OKRs方面
沒有人比谷歌更有經驗

隨着公司規模的擴大，它按期發佈 OKR 指南和模板。如下摘錄主要來自內部資源，並經谷歌許可轉載。
（注：這是谷歌對 OKRs 的作法。你的方法可能不一樣，也應該不一樣。）

在谷歌，咱們喜歡大張旗鼓。咱們使用一個稱爲目標和關鍵結果（OKRs）的過程來幫助咱們溝通、衡量和實現這些崇高的目標。

咱們的行動決定了谷歌的將來。正如咱們在互聯網搜索、Chrome 和 Android 中屢次看到的那樣，一個由少許員工組成的團隊，朝着一個雄心勃勃的共同目標努力，就能夠在不到兩年的時間裏改變整個成熟的行業。

所以，做爲谷歌的員工和經理，咱們必須有意識地、謹慎地、明智地選擇如何分配咱們我的與團隊成員的時間和精力。OKR 是這種謹慎選擇的體現，也是咱們協調我的行動，以實現偉大集體目標的手段。

---

咱們使用 OKR 來規劃要生產的產品，跟蹤它們的進度與計劃，並協調人與團隊之間的優先級和里程碑。
咱們也用 OKRs 幫助你們專一於最重要的目標，並幫助他們避免被緊急但不過重要的目標分散注意力。

---

OKR是有野心的，它不是逐步增量式的，咱們並無但願一次性就完成全部這些野心。（若是咱們真的這樣作，那麼，咱們就不會具備足夠的進取性）。

咱們用色階來衡量咱們作得有多好：

• 0.0 -- 0.3 是紅色●
• 0.4 -- 0.6 是黃色●
• 0.7 -- 1.0 是綠色●

正確的OKR制定方法規則

沒有認真實施和管理的OKR，是一種時間上的浪費，是管理上的假大空。與之相反，若是實施得好，OKR將是一種很好的動機激勵工具，它能讓團隊明白什麼是真正重要的，哪些地方須要優化，在平常工做中應當如何去進行利弊權衡。

要寫出好的OKR可不是一件容易的事，但也不是不可能。請遵循以下這些簡單的OKR制定規則：

1. 規則1：O 要回答的是 "What" 的問題，它應當：

• 表達清楚目的和意圖；
• 挑戰且現實可行；
  - 必須真實、客觀，毫不含糊；
  - 旁觀者應該可以明確無誤地判斷出一個O是否達成；
  - O的達成應對Google產生明確的價值和意義。

1. 規則2：KR 要回答的是 "How" 的問題，它應當：

- 清晰可衡量，一旦KR達成了，能有力地推進O的完成； - 必須是產出導向，而非動做導向。若是你的KR包含有像"諮詢"、"幫助"、"分析"、"參與"這樣的詞彙，那麼它描述的其實是動做而非結果。與之相反，若是描述的是這些動做對最終用戶所帶來的影響，例如："在3月7日前公佈6個鉅細胞的平均潛伏期和最長潛伏期"就是一個合格的KR，而"評估鉅細胞潛伏期"則不是。 - 必須能自證其是否已完成。這個證據取消績效是可輕易獲取的和可信賴的，例如，證據能夠是變動列表、文檔連接、已發佈的質量報告等。

1. 規則3：跨團隊OKR

在谷歌，不少重要的項目須要多個不一樣的團隊一塊兒協同方能完成。OKR是幫助致力於這種跨團隊協同的理想工具。跨團隊OKR的責任人應包括全部須要參其中的團隊，每一個團隊都應當將它所負責的跨團隊OKR明確無誤地寫到它本身團隊的OKR中去。

舉例來講，若是廣告開發部、廣告SRE部和網絡開發部三個部門需協同交付一個新的廣告服務，那麼這三個團隊就應該有一個共同的團隊OKR，來描述他們的這項交付工做，指明各個部門在這個項目中所應作出的貢獻。

1. 規則4：指令性OKR和挑戰性OKR

一般，存在兩種類型的 OKR（指令性OKR和挑戰性 OKR ），有必要對他們進行區分：

指令性 OKR 指的是那些咱們必須承諾達成的OKR，咱們必須調度充足的資源在指定時間內確保達成它。

對指令性 OKR 而言，目標分數是 1.0 ；若是得分低於 1.0 必須作出相應的解釋，由於這意味着計劃上或者執行上存在誤差。

與之相反，挑戰性 OKR 則意味着即使在咱們對將來一無所知，或者在沒法得到必要資源支持的狀況下，也依然應該去探索的那些事。挑戰性 OKR 承載的是咱們改變世界的夢想。

挑戰性 OKR 的目標分數是 0.7 分，由於它存在高度的不肯定性。

OKR寫做常見錯誤與陷阱

1. 錯誤1：把指令性 OKR 和挑戰性 OKR 混爲一談

把指令性 OKR 當成是挑戰性 OKR ，會增長 OKR 達成的風險。團隊可能不會去認真對待挑戰性 OKR ，確保高優先投入其中以成功交付這些 OKR 。

另一方面，若是把挑戰性 OKR 標記成了指令性 OKR ，就會出現優先級倒置狀況，一方面，真正的指令性 OKR 沒有資源去完成，而另一方面，挑戰性 OKR 又不能真正的得到必要的資源支持，這會在團隊中製造抵觸心理。

1. 錯誤2 ：OKR 只是在例行公事

所制定的 OKR 都是些團隊無須作任何改變便可垂手可得完成的工做，而不是團隊或者客戶真正想要實現的那些事情。

1. 錯誤3：挑戰性 OKR 並不挑戰

若是在制定挑戰性 OKR 時的基本假設是："假若有額外的人力支撐，或者再幸運一些，那麼咱們能夠作點什麼？"，這樣制定出來的 OKR 還不能算作是挑戰性 OKR 。更好的作法是，在制定挑戰性 OKR 時，問咱們本身這樣一個問題："若是咱們解除了絕大多數限制，那麼我或者個人客戶的世界看起來應該是什麼樣的？"

對挑戰性 OKR 而言，當它最初被制定出來的時候，你並不知道如何才能實現它，這纔是挑戰性 OKR 的真正要義。但若是你不去理解和描繪這種最終狀態，你就必然實現不了，這和知道目標但不知道如何實現它是有本質區別的。

你能夠作一個小測試：問你的客戶他們真正想要的是什麼，而後看看你定出的挑戰性 OKR 是否達成或者超越了他們的預期？

1. 錯誤4：OKR 不勇於挑戰

毫無疑問，一個團隊的指令性 OKR 會消耗他們大多數可用資源和精力，但不是所有資源和精力。指令性 OKR 和挑戰性 OKR 合在一塊兒所消耗的資源量，應當是超出團隊目前的可用資源範圍的，否則這個團隊的 OKR 就所有都只是指令性 OKR ，由於指令性 OKR 是要求必須在現有資源範圍內要能所有達成的 OKR 。

若是一個團隊只使用部分人力/費用就能達成他們全部的 OKR ，那麼這個團隊事實上是在浪費資源，或者說團隊一把手沒有管理好他們的團隊成員。這意味着上層管理團隊須要從新分配其人力和資源，把它們調配給那些真正能夠作得更好的團隊。

1. 錯誤5：低價值O（戲稱"沒人在乎"型 OKR）

OKR 必定要體現清晰的商業價值，不然，就不值得浪費資源去作它們。低價值O（LowValued Objective, 簡稱 LVO ）指的是那些即便你百分百完成了，得分達到1.0 了，也沒有人會真正注意到的 O 。

一個經典（也頗有誘惑力）的低價值 O 示例："將 CPU 利用率提高 3 個百分點。"

這個 O 自己對用戶和谷歌並不能帶來什麼幫助。然而，若是將 O 描述成這樣："在不改變質量/延遲/...的狀況下，將峯值查詢所需內核數量減小 3 %，並將多餘的內核返回空閒資源池。"則清晰地描述出了經濟價值，就是一個好的 O 了。

這裏有一個小測試能夠幫到你：OKR 可否在沒有直接最終用戶參與，或者產生經濟收益的狀況下就獲得 1.0 分？若是是，那麼你須要從新組織你的 OKR 描述，讓它顯性地體現有形收益。好比："發佈X" 就沒有道出成功的標準。更好的描述是："將 X 發佈到 90% 以上的集羣管理器網元，使集羣 Y 容量翻番。" 則是一個不錯的 O 。

1. 錯誤6：KR 不足以支撐 O 的達成

OKR 包含 2 個部分：O 描述的是指望達成的結果，KR 是達成這個結果所要經歷的步驟。於是，關鍵的一點就是，若是全部 KR 的分數都是 1.0 了，那麼與之相關的 O的分數也應該是 1.0 。在制定 OKR 時，一個常見的錯誤是，全部的 KR 都是必要但卻非充分的，也即當這些 KR 都完成了，卻沒法支撐 O 的實現。這個錯誤頗有多是故意形成的，由於這讓團隊躺在溫馨區，不去作必要的資源/優先級/風險等承諾，這比交付"困難"的 KR  要容易得多。

這一陷阱極其有害，由於它拖延了發現達成 O 所需資源的時機，沒有及時暴露 O 不能按計劃達成的風險。

能夠作一個小測試：若是把全部 KR 的得分都標記成了 1.0 ，是否仍沒有達成所但願的目標或意圖？若是是，那麼請增長 KR ，或者從新組織 KR ，直到 O 下全部KR能完整無誤地支撐其達成爲止。

OKR查閱、解讀和實施：

指令性OKR

要求團隊要及時調整其餘事項的優先級，以確保這部分 OKR 能按計劃 100% 交付，這部分 OKR 的得分須爲 1.0。

若是團隊不能承諾在指令性 OKR 上達成 1.0分，團隊須適當地將這一風險及時進行升級上報。這一點很關鍵：這種情形下的升級不只是合適的，並且你必須這麼作。不管是由於對 OKR 的分歧、對其優先級的分歧，仍是因爲沒法分配足夠的時間/人員/資源而致使沒法按承諾達成 OKR ，都應對之進行升級。這讓管理層能提早思考應對策略。

推論：這意味着每一個 OKR 都會涉及到適度升級，由於它須要基於已有優先級或者承諾作出改變。一個不須要作任何修改的 OKR 只是一個例行性 OKR ，即使之前沒有被明確制定成 OKR，它們也不多是新的 OKR。

不能按時達成 1.0 分的 OKR 都應進行過後回溯。這不是要懲罰哪一個團隊，而是要弄清楚究竟發生了什麼，是計劃制定不合理？仍是 OKR 執行上出現了問題，找到真正的問題所在，持續提高團隊能力，以便將來更好地完成指令性 OKR。

指令性 OKR 的示例有：

- 確保服務達成 SLA（服務水平協議）。 - 發佈預先定義好的特性，或者在指定日期提高基礎設施系統的性能。 - 以必定成本製造並交付必定數量的服務器。

對挑戰性OKR

挑戰性 OKR 被設計成須要團隊在某季度付出額外的努力才能達成的那些 OKR。挑戰性 OKR 的優先級指明瞭團隊成員在完成了指令性 OKR 後，還須要在哪些地方進行額外的時間和精力投入。當團隊有多個挑戰性 OKR 時，團隊應優先完成高優先級挑戰性 OKR ，而後再完成次優先級挑戰性 OKR......依此類推，以確保資源和精力的聚焦。

挑戰性 OKR 及其優先級，一樣應該出如今一個團隊的 OKR 列表上，直至其完成爲止。若有必要，這些 OKR 能夠持續多個季度，並不斷推動其進展。僅僅由於一件事情進展不佳就將其從 OKR 列表中刪除是不對的，這是在掩蓋問題而非真正解決問題。

推論：若是另一個團隊既有充足的專家資源也有充足的時間投入，那麼把一個挑戰性 OKR 轉交給這個團隊去作會更合適。

團隊管理者須要每季度按期評估挑戰性 OKR 的資源知足度，履行其職責確保業務的已知需求得以知足。管理者不是要接受全部的資源需求，而是應在團隊全部指令性 OKR 完成以後，按目標優先級去進行資源調度。

關注公衆號
回覆 "OKR" 獲取《OKR小測試》，
檢測一下你的組織OKR狀態吧。

本文首發於 Bob Jiang的博客 ，轉載請聯繫 Bob Jiang