谷歌OKR指導手冊 (譯)

這是一本關于 OKR 迷你小冊子，名為《Google OKR playbook》，由?www.whatMatters.com?網站發布。?該網站由John Doerr 團隊經營，?而John Doerr 正是 1999年將 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 分，因為它存在高度的不確定性。

關注《持續交付2.0》

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 完成之后，按目標優先級去進行資源調度。

譯者：喬梁 來源：《持續交付2.0》公眾號

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。