前言

這篇跟工程師其實沒那麼有關，適合給新手leader定OKRs的時候看看。

演講總結

今天要講的主題是關於設定OKRs的一些trick。

OKRs是google在…開發的一套目標設定的系統，不清楚的同學可以看看原google官方介紹。

透過OKRs基本上可以達到以下目標：

• 設定目標
• 與團隊達成共識
• 量化進度

而設定OKR看起來並沒有很困難，你可以想像就是個填空題：「我們目標是，以 」

例如：我們目標是「code coverage從35%提昇至50%」，以「增加產品品質」。

看起來設定OKR是如此的輕鬆寫意，但是實際上做起來卻爆炸難。因此講者在此演講講了三個建議（特別是對於那些剛使用OKR的團隊）：

1. 無須設置個人OKR

   個人OKR通常會降低成員的效率，而且還沒有不會有帶來任何價值。甚至往往會變成一些實際的任務或micromanagement的工具。

   因此最好的解法就是不要設置OKR。

2. 忽略數字

   對於剛使用OKR的人，往往會遇到兩個難題：

   1. 覺得重要的事情沒被計算到。
   2. 大部分的KR的數字都是SWAG（a sophisticated wild-assed guess，一亂串複雜粗暴的亂猜）。沒人知道為什麼是從預計提昇至50%，都只是亂猜亂估計。

   也因此數字在初期一點都不重要，應該更聚焦於產出（outcome）而非數字。

3. 避免由上而下的目標

   很多人會覺得應該OKR應該由上而下讓整個組織有一致的目標，但為了做這件事其實會花費非常多的時間align。再者這件事其實往往會扼殺創意，大家會低估自己能帶來的價值。管理階層往往容易膨脹自己的價值，而員工階層往往會忽視自己意見的價值。

   所以更好的作法其實是由下而上（bottom-up）的設計OKR，讓員工們自己設定團隊目標，也可能同時可以當成empower的工具。

個人心得

這篇因為是短篇所以沒有講太多的內容XD，而我自己也沒有太多好的經驗，如果有人知道有好的資源還請麻煩推薦給我m(_ _)m。

我自己是有不少感觸可以理解訂OKR到底有多困難，因為在我離職前一陣子公司有嘗試開始訂OKR。先姑且不論公司是如何執行這件事情，但我個人是遇到蠻多問題的XD。就像上面所說的數字訂法要怎麼訂真的是非常困難，例如到底test coverage應該要提升到70還是80真的完全是亂猜。

關於訂OKR到底要由下而上還由上而下，我自己遇到的狀況是，因為組織策略其實不是很透明，所以由上而下的意義不大，這走的好像也只是個形式而已。但當我們想由下而上來訂時，卻又被要求要與組織的align。或許就像講者說的其實應該要直接是由下而上，而不完全需要與組織align是比較好的選擇。

而自己也遇到了蠻多問題例如OKR到底是不是代表一種評鑑方式？OKR訂太多還有意義嗎？如果上層的OKR訂的不好該怎麼辦？等等其實我也不知道怎麼樣做比較好的事。或許這還是需要多一點的實際經驗看其他公司的正確使用姿勢，才會比較會有幫助。