谷歌OKR案例:深度解讀《谷歌OKR員工手冊》（谷歌的okr）

谷歌okr案例:深度解讀《谷歌OKR員工手冊》（谷歌的okr）

在開始閱讀正宗版的《Google OKR員工手冊》之前，請允許譯者再啰嗦幾句。我們都知道，OKR源于Intel，光大于Google，也因此，在我們試點OKR的時候，總是試圖去弄清Google的OKR是什么，運作效果如何，以及為什么能取得這樣的效果。但令人遺憾的是，一方面，Google是一家極其自由和開放的公司，另外一方面，它也是一家極其封閉的公司。其開放性體現在它對內部員工是開放的，所有員工只要跨入Google公司的大門，公司內部幾乎所有文檔和代碼的權限，無特別聲明時對他們都是開放的，也即是說，開放是Google的默認選項。然而，這個開放僅止于Google內部，你甚至無法在外部找到Google公司內部的哪怕任何一個OKR示例。也難怪，搜索引擎是Google自己做的，它如果不想開放，誰又能搜索得到呢。

好在，2015年前的幾年里，Google的前CEO施密特和Google前CHO拉茲·博格，相繼出版了2本書，一本叫《How Google Works》，中文名《重新定義公司》，一本叫《Work Rules》，中文名《重新定義團隊》，分別介紹了Google的整體業務運作和人力資源運作，可算是部分滿足了外界對如日中天中的Google的獵奇心理。但高層主管出版的書，通常焦點在道的層面，很少聚焦到術的層面，其結果就是，你看得很興奮，然而回到工作崗位上后，發現理想很豐滿，現實很骨干，并沒有什么卵用，離真正實操還有十萬八千里。

下文翻譯的這篇《Google OKR員工手冊》，源于Google內部（已公開），是實實在在地瞄準員工層面的OKR指導手冊，你可以通過它，真實地感受到Google是如何要求它的員工開展OKR的。這寥寥數頁文字，幫你去除身上的高貴氣，真正地趴在天間地頭上查看OKR的生長規律。請君鑒賞。

《Google OKR員工手冊》

在谷歌，我們喜歡從大處著想（Think Big）。因此，我們采用了一種叫做OKR的方法來幫助我們溝通、衡量并達成那些遠大的宏偉目標。我們的行動決定著谷歌的未來。就像我們一再看到的那些案例那樣，我們在搜索團隊、在Chrome瀏覽器團隊、在安卓團隊，通過緊密協同，只用了很少量的公司人力，就取得了輝煌的業績。因此，對谷歌的員工和經理來說，很重要的一點是我們要有意識地、謹慎而明智地選擇如何分配我們的時間和精力。

我們用OKR來規劃我們要做哪些事，跟蹤這些事的進度開展情況，在員工之間以及團隊之間協調工作的優先級和里程碑點。我們還用OKR來幫助大家聚焦在那些最重要的目標上，避免他們被那些重要但不緊急的目標分散精力。

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，而“評估巨細胞潛伏期”則不是。

必須能自證其是否已完成。這個證據取消績效是可輕易獲取的和可信賴的，例如，證據可以是變更列表、文檔鏈接、已發布的質量報告等。

跨團隊OKR

在谷歌，很多重要的項目需要多個不同的團隊一起協同方能完成。OKR是幫助致力于這種跨團隊協同的理想工具。跨團隊OKR的責任人應包括所有需要參其中的團隊，每個團隊都應當將它所負責的跨團隊OKR明確無誤地寫到它自己團隊的OKR中去。舉例來說，如果廣告開發部、廣告SRE部和網絡開發部三個部門需協同交付一個新的廣告服務，那么這三個團隊就應該有一個共同的團隊OKR，來描述他們的這項交付工作，指明各個部門在這個項目中所應做出的貢獻。

指令性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：

如果你只用了5分鐘就寫出了一個OKR，那么它通常不會是一個好OKR。請重寫。

如果你的O超過2行，它很可能就是不清晰的。

如果你的KR描述中充斥著內部團隊術語，例如“發布 Foo 4.1”，它們通常就不是好的OKR。真正重要的不是“發布”這個動作，而是其所造成的影響（Impact）究竟是什么。為什么Foo 4.1很重要？更好的表述是這樣的：“發布Foo 4.1系統，促使注冊用戶數提升25%。”或者簡單地寫成這樣：“提升注冊用戶數25%”

使用真實日期。如果所有的KR的截至日期都是季度的最后一天，你制定的計劃就很可能是有問題的。

確保你的KR是可度量的：KR必須是每個季度末可以進行客觀評分的。“提升注冊用戶數”不是一個好的KR，“在5月1號前提升日均注冊用戶數25%”則是一個好的KR。

確保度量指標是清晰的。如果你說“一百萬用戶”，你要指明這指的是全時段用戶，還是只是7天活躍用戶。

如果你發現有些重要活動或者重要活動的相當一部分工作量沒有包含到OKR中，請把它加進去。對大型團隊來說，可以對OKR進行分層，采用OKR級聯的方式去對OKR進行分解：上層團隊關注大顆粒度OKR，下層團隊關注小顆粒度OKR（大人吃大饅頭，小人吃小饅頭——譯者注）。

確保那些需要橫向協同的OKR在每個支撐團隊都已制定相應的KR在支撐它。

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

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