谷歌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

標籤：其他

上一篇：gitlab-runner的安裝

下一篇：自我介紹+軟工5問