這是一本關於 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：O 要回答的是 "What" 的問題，它應當：
- 表達清楚目的和意圖；
- 挑戰且現實可行；
- 必須真實、客觀，絕不含糊；
- 旁觀者應該能夠明確無誤地判斷出一個O是否達成；
- O的達成應對Google產生明確的價值和意義。
- 規則2：KR 要回答的是 "How" 的問題，它應當：
- 清晰可衡量，一旦KR達成了，能有力地推動O的完成； - 必須是產出導向，而非動作導向。如果你的KR包含有像"諮詢"、"幫助"、"分析"、"參與"這樣的詞彙，那麼它描述的實際上是動作而非結果。與之相反，如果描述的是這些動作對最終用戶所帶來的影響，例如："在3月7日前公佈6個鉅細胞的平均潛伏期和最長潛伏期"就是一個合格的KR，而"評估鉅細胞潛伏期"則不是。 - 必須能自證其是否已完成。這個證據取消績效是可輕易獲取的和可信賴的，例如，證據可以是變更列表、文檔鏈接、已發佈的質量報告等。
- 規則3：跨團隊OKR
在谷歌，很多重要的項目需要多個不同的團隊一起協同方能完成。OKR是幫助致力於這種跨團隊協同的理想工具。跨團隊OKR的責任人應包括所有需要參其中的團隊，每個團隊都應當將它所負責的跨團隊OKR明確無誤地寫到它自己團隊的OKR中去。
舉例來說，如果廣告開發部、廣告SRE部和網絡開發部三個部門需協同交付一個新的廣告服務，那麼這三個團隊就應該有一個共同的團隊OKR，來描述他們的這項交付工作，指明各個部門在這個項目中所應做出的貢獻。
- 規則4：指令性OKR和挑戰性OKR
通常，存在兩種類型的 OKR（指令性OKR和挑戰性 OKR ），有必要對他們進行區分：
指令性 OKR 指的是那些我們必須承諾達成的OKR，我們必須調度充足的資源在指定時間內確保達成它。
對指令性 OKR 而言，目標分數是 1.0 ；如果得分低於 1.0 必須做出相應的解釋，因爲這意味着計劃上或者執行上存在偏差。
與之相反，挑戰性 OKR 則意味着即便在我們對未來一無所知，或者在無法獲得必要資源支持的情況下，也依然應該去探索的那些事。挑戰性 OKR 承載的是我們改變世界的夢想。
挑戰性 OKR 的目標分數是 0.7 分，因爲它存在高度的不確定性。
OKR寫作常見錯誤與陷阱
- 錯誤1：把指令性 OKR 和挑戰性 OKR 混爲一談
把指令性 OKR 當成是挑戰性 OKR ，會增加 OKR 達成的風險。團隊可能不會去認真對待挑戰性 OKR ，確保高優先投入其中以成功交付這些 OKR 。
另外一方面，如果把挑戰性 OKR 標記成了指令性 OKR ，就會出現優先級倒置情況，一方面，真正的指令性 OKR 沒有資源去完成，而另外一方面，挑戰性 OKR 又不能真正的獲得必要的資源支持，這會在團隊中製造牴觸心理。
- 錯誤2 ：OKR 只是在例行公事
所制定的 OKR 都是些團隊無須做任何改變即可輕而易舉完成的工作，而不是團隊或者客戶真正想要實現的那些事情。
- 錯誤3：挑戰性 OKR 並不挑戰
如果在制定挑戰性 OKR 時的基本假設是："假如有額外的人力支撐，或者再幸運一些，那麼我們可以做點什麼？"，這樣制定出來的 OKR 還不能算做是挑戰性 OKR 。更好的做法是，在制定挑戰性 OKR 時，問我們自己這樣一個問題："如果我們解除了絕大多數限制，那麼我或者我的客戶的世界看起來應該是什麼樣的？"
對挑戰性 OKR 而言，當它最初被制定出來的時候，你並不知道如何才能實現它，這纔是挑戰性 OKR 的真正要義。但如果你不去理解和描繪這種最終狀態，你就必然實現不了，這和知道目標但不知道如何實現它是有本質區別的。
你可以做一個小測試：問你的客戶他們真正想要的是什麼，然後看看你定出的挑戰性 OKR 是否達成或者超越了他們的預期？
- 錯誤4：OKR 不敢於挑戰
毫無疑問，一個團隊的指令性 OKR 會消耗他們大多數可用資源和精力，但不是全部資源和精力。指令性 OKR 和挑戰性 OKR 合在一起所消耗的資源量，應當是超出團隊目前的可用資源範圍的，不然這個團隊的 OKR 就全部都只是指令性 OKR ，因爲指令性 OKR 是要求必須在現有資源範圍內要能全部達成的 OKR 。
如果一個團隊只使用部分人力/費用就能達成他們所有的 OKR ，那麼這個團隊事實上是在浪費資源，或者說團隊一把手沒有管理好他們的團隊成員。這意味着上層管理團隊需要重新分配其人力和資源，把它們調配給那些真正可以做得更好的團隊。
- 錯誤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 。
- 錯誤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