三木生 | OKR：做最重要的事

那年，我遇見的OKR 

2017年，第一次聽到 OKR，是從來自美國 IDEO 的朋友口中的介紹的『 OKR 是一套Google 一套公司目標設定方法。』，他也將這個制度分享給公司 HR 並設計了一個 prototype 。
去年年底，擔任公司 CTO 的朋友送我了一本書『OKR：做最重要的事』，過年期間認真的讀了這本書之後，省思了當時過程 prototype 的過程。

當時的我也是一名參與者。起初設定制訂個人年度 OKR， 且由個人將自己對於年度任務進行拆解，但因為缺少了定期檢視以及當偏離當時目標時快速調整等機制，最後導致自己年度 OKR 以失敗收場。

我們重新了解一下什麼是 OKR ?

目標與關鍵結果（OKR，Objectives and Key Results），前面的『目標』表示是你想要完成的事情，而後面的關鍵結果代表的是你如何達成他。當 OKR 落實在公司組織中，將達成公司上上下下都知道要做什麼事情，且了解做這些事情是為了達成某個目的，會讓大家在做的過程中不會偏移方向。

OKR 是由目標管理（MBO，management by objectives）理論演變而來，MBO 將目標告訴大家，而怎麼做這件事情，並沒有明確定義下來，這樣的方式需要自動自發的組織，自行定義任務達成目標，但缺點會在於執行過程中會造成大家在做的過程中，無法確認作這這件事情是否正確。所以 OKR 基於 MBO 調整增加了關鍵結果，進而達到整個團隊了解怎樣做。

大家以前常聽到的 KPI ，我認為是衡量目標最後的完成效果，會是 HR 或是 管理職與高階主管回報事情成效時使用，而 OKR 是管理者與團隊溝通的工具，確保大家對於事情上面的要作的事情可以一致。

OKR ，就如剛說明的組成內容分成兩部分：
1.  目標
2. 可量化的關鍵結果（時間以及數量）

OKR 需要將以下心法搭配操作：
1. 少即是多：精心設定的目標是為了傳達一個明確的信息，他是團隊中做事準則，已經告訴大家作哪些事情以及哪些事情不作，且每個目標都應該最多制定5個關鍵結果。

2. 至下而上設定目標：為了促使員工參與，鼓勵團隊和個人與管理人員進行協商制定 OKR。

3. 共同參與： OKR 已確定修先事項，但在關鍵結果中，可以商討並與團隊達成共識。

4. 保持靈活：在執行過程中，由於環境以及資源的變化，會使得目標或是關鍵結果看起來不切實際，在過程中彼此溝通下是可以調整以及捨計某些關鍵結果。

5. 敢於失敗：制定目標任務時，需要設置調戰性目標，此目標讓團隊推向新的高度。

6. OKR 是工具，不是武器：OKR 必須與激勵分開。

7. 耐心以及堅定：由於起初在制定 OKR 時，大家會無法拿捏標準，過程不斷試錯。隨著多次的嘗試後，團隊將會更加適應。一個組織至少要經歷過 4 至 5 個季度，才能完全適應OKR。

怎樣開始 OKR 

在制定 OKR 時，需要有最高領導者做最高原則的承諾，確立計畫目標後，讓團隊了解從那邊開始並確定什麼是最重要的事情。 OKG 並不是除了口頭與團隊溝通達成目標方向之外，必須樹立榜樣以身作則，否則團隊中沒有人會在意目標。領導者說清楚為什麼做某件事情，以及怎麼作。而員工不僅需要以里程碑的方式獲得動力之外，也必須要了解這工作背後做事情的意義，且了解自己的目標與公司使命的關聯。

目標與關鍵結果，相當於原則與及實踐抑或是願景與執行。目標會鼓舞人心，而關鍵結果使的目標更加了解如何被實現。關鍵指標是拉動目標實現的槓桿以及實現目標的過程中的每個節點，通常三至五個關鍵指標就足以確保目標能達成，且每個關鍵指標對於個人都是一種挑戰。

有些企業制定 OKR 會是只以年度為週期，並拆分至小團隊至個人，將目標拆分至不同關鍵指標後，不同團隊對於負責的關鍵指標制定，使得目標設定自上而下，更具有協作性。OKR 制定過程中，有明確的時間框架後，會預防工作中的拖延症。時間週期可以團隊進行協商，確保每件事情在都是彼此可以掌控的。

OKR 必須是可以追蹤了解進度，一旦關鍵結果或是目標變得過時或是不切實計時，就需要當機立斷的結束他，一旦 OKR 調整時，必須要告知相關人員。為了讓 OKR 可以更加貼近真實，團隊必須每季對 OKR 進行檢視溝通，其溝通內容可以分為:

1. 客觀評估: 針對當時制定的關鍵結果，評估目前執行狀況

2. 主觀評估: 目標制訂者對於目前 OKR 的執行過程中產生的客觀數據提出調整說明

3. 反思: 回顧過去，展望未來。

重新思考 OKR

起初，在讀OKR 的時候，我了解的內容是：大任務制訂任務項目後，分發給不同專案小組去自行拆分小任務，而後定期追蹤任務狀況。其中，最重要的是做到團隊的所有人了解目標方向，在做的過程中才能更以方向去執行任務。但經過輸出此篇文章後，讓我回想到去年專案執行敏捷式開方模式與 OKR 有相似的流程。

敏捷式開發，由產品負責人制定專案大方向後，由產品經理收集所有工作待辦事項後，在每次Sprint Planing 過程中，專案的所有人制訂此次Sprint 工作任務安排，並自行拆分子任務並安排其工作時間。並於每天開始以站會的方式去回顧所有任務的進度，並於完成的時間點進行Sprint Review 找相關人進行任務展示驗收。最後會執行 Sprint Retro 回顧這過程中大家遇到的事情，哪些是可以改進的。

讀完此書之後，目前思考著除了在工作上面運用之外，在自己年度計畫中怎樣執行，讓 OKR 落實在自己的生活上面。後面出一篇文章針對自己年度計畫進行 OKR 的設置跟大家分享，也重新檢視自己是否會在同樣的問題上面犯錯。