歡迎光臨Python百貨，我是樓管 小笠宏樹，祝各位客人今晚都能挑到你要的商品～

來個我喜歡的團
Foo Fighters. Walk.

OKR

定義

OKR(Objectives and Key Results)全稱為“目標和關鍵成果”，是企業進行目標管理的一個簡單有效的系統，能夠將目標管理自上而下貫穿到基層。（from MBA智庫百科）

以軟體來說就是不定細節，而是定義大方向，然後從上至下去各自定各自的目標，只要下層的目標跟上層的目標是一致的就好，舉個例子來說，整個專案的Ｏ可能是要讓程式碼更簡潔，因此KR可能就會是將專案的Kotlin比例提高，減少程式碼的數量或Size，而接下來不同的Class會訂出自己的作法，比如有的較舊的Class就很直接，就會是將Java轉成Kotlin，而另外一些更改過多次的Class可能就是要將沒刪乾淨的地方刪掉。

失敗案例

KR太過模糊

有時候老闆在定OKR的時候會不知道怎麼下手，但又為了能符合每個部門的
情況，所以就給了一個很模糊的OKR，比如：O是要做出個好的產品，KR是帶來更多的顧客，這種情況下面的部門也會無所適從，不知道該如何定義自身的OKR。

軟體版舉例：「O要寫Clean Code，KR讓看得懂的程式碼增加」，工程師表示誰先來給我定義「看得懂」先，誰「看得懂」，怎麼叫「看得懂」？

太過明確

當老闆訂了一個過於限縮的OKR的時候也會是一場災難，一開始設計O的目的就是為了可以有模糊的空間（這個是為了因應KPI由上層去訂下層KPI容易考慮不周的缺點），讓下層的部門可以自由地去選擇他需要前進的方式，舉個例子：今天假如公司訂了一個OKR是讓業績量變兩倍，那全公司大概只有業務部門知道自己的OKR是要定什麼，其他部門大概就是定業務不需要什麼就支援什麼。

軟體版舉例：「O要讓程式變得更小，KR是讓拔掉User可以更改頭像的功能」，這....就沒有定的意義了，太精確了已經失去了原本定OKR的好處，不如直接當Task來做

O跟KR沒有絕對關係

有時候會訂出O跟KR沒有實際相關或者是KR定的不夠準確，舉個例子：O可能是想要增加產品的知名度，KR是增加付費用戶的數量，這個時候其實O跟KR不一定有直接相關，因此很容易造成下層的部門定自身OKR時會產生價值混亂，比如行銷部門會想說我到底是要純粹撒廣告增加來客數就好，還是也要符合KR的衝付費用戶的條件。並且在最好要確認完成的品質的時候也難以判斷是否有確實得達成目標。

軟體版舉例：「O要讓程式跑得更快，KR讓程式碼減少一半」，這兩者之間是沒有完全的正相關的，因此很容易會不知道該照什麼準則去訂各自的OKR

明天會來講個大膽的系列“微服務”