各位玩家大家好～我是你們的GM小立宏樹！歡迎你們進入這場真實人生大冒險，請各位保持愉快的心情繼續玩這個為期一生的遊戲，我們遊戲商能保證的是除非玩家不想玩不然我們的伺服器絕對不會倒～

來首很符合我想要的意境的歌
糯米糰。黃金單身漢

最近幾年由於很多書籍開始討論那些最潮的大型科技公司都用OKR了，所以很多新創也一窩蜂的跟上流行的腳步，這也導致了KPI以及OKR雙方的大戰一直持續不斷。所以今天就來分別討論一下KPI和OKR那些失敗的案例吧～

KPI

定義

又稱主要績效指標、重要績效指標、績效評核指標等，是指衡量一個管理工作成效最重要的指標，是一項數據化管理的工具，必須是客觀、可衡量的績效指標。這個名詞往往用於財政、一般行政事務的衡量。是將公司、員工、事務在某時期表現量化與質化的一種指標。可協助將優化組織表現，並規劃願景。（from 維基百科）

用軟體的方式解釋就是為每一個Class都定義符合它的寫程式規則，而且必須是明確的規則，比如public變數不能超過5個，Function需要低於10個，Global變數不能超過5個等等。這個乍聽之下是不合理的，但可以帶入一個企業常見的現象是，企業在更改組織架構是很漫長的，所以在架構長時間不變的情況，去定義每一個Class裡面的寫作規則算是有道理的。

失敗案例

太過明確

有的公司會將KPI定義的非常明確，但太過明確往往會產生過於量化的問題，反而導致規則過於無法變通，比方說KPI定義了業務必須在一季至少交出2000萬的業績，但有可能業務手上有長線的客戶可以在下一季產生5000萬的業績，但這一季必須全副精神來處理這一單，這個時候太明確的KPI，反而會無法衡量這個指標。

軟體版舉例：軟體的Size每個季度都要少10%。假如突然需要加功能的時候，還必須遵守這個規範，那這個KPI就是沒有考慮到這個狀況的。

太過偏頗或有漏洞

規則明確的時候通常表示的就是漏洞百出（遠目我們的法律），漏洞不代表上面的人不會訂規則，而是規則沒有及時地隨著周遭的情況變化，有漏洞通常就很容易產生反效果，比如：寫程式的衡量指標是發了幾隻PR、業務的指標是賣了幾單產品、設計師的指標是產出了幾件作品等等，這些都容易讓別人鑽漏洞，也代表著KPI定不好。這條其實非常常發生，因為通常定KPI的上司很容易沒考慮到第一線的細節，因此如果要用KPI還需要盡量搜集第一線的意見。

軟體版舉例：某個Class的程式碼行數越少越好。一行解決全部的程式是好的程式？可讀性也需要考慮進KPI

訂的太過複雜

過於複雜的KPI，反而會需要讓每個員工和上司疲於去應付KPI的規則，要知道KPI的量化或者值化的行為都是人要負責去填補資料的，所以說就會出現常見的怪現象，比如：每天都必須要記錄每個小時做了什麼工作、每天寫紀錄的時間比工作更多、上司每週都必須繳交檢討報告交到後來都是敷衍亂寫。

軟體版舉例：每一個function、var、Class都需要寫註解。這個保證把工程師逼瘋，寫註解的行數都比程式本身還多。

好啦～今天讓作者偷懶一下 先交上半部，明天我們再來聊聊OKR的怪現象。