摘要： 題記：從技術 leader 的角度出發，看技術人績效考核的痛。大多數公司裡面總會因為 KPI 的考核方式而存在各種各樣的問題，OKR 是一個在矽谷網際網路公司比較流行的做法。怎樣去理解 OKR 這個概念，並在技術團隊中推行，從而使績效考核更合理也更有意義？ KPI 的困惑 索尼公司前常務董事天外伺朗的《績效主義毀了索尼》一文，曾經在業界流傳甚廣
KPI 的困惑
索尼公司前常務董事天外伺朗的《績效主義毀了索尼》一文，曾經在業界流傳甚廣，也激起了廣泛的爭議，支持的反對的意見和聲音到現在為止都還沒有停止。拋開文章的結論是否正確，觀點是否偏頗，索尼是否沒有真正理解 KPI 等爭議，單純從文章描述的現象來看，相信絕大部分公司裡面都會存在類似的現象，例如：
- 「因為要考核業績，幾乎所有人都提出容易實現的低目標」
- 「因實行績效主義，索尼公司內追求眼前利益的風氣蔓延。這樣一來，短期內難見效益的工作，比如產品質量檢驗以及「老化處理」工序都受到輕視」
- 「上司不把部下當有感情的人看待，而是一切都看指標」、
- 「為衡量業績，首先必須把各種工作要素量化。但是工作是無法簡單量化的。公司為統計業績，花費了大量的精力和時間，而在真正的工作上卻敷衍了事，出現了本末倒置的傾向」
我開始帶技術團隊后，在績效考核這方面同樣遇到了類似的疑惑，例如：
- 程序員的工作怎麼量化？bug 數？代碼行？版本數？
做過程序員的都知道，這些指標都是不可行的。例如某通信大廠考核程序員的 bug 數和等級，並且更加讓人蛋疼的是同時考核測試人員發現 bug 的數量，結果程序員和測試員為了一個問題是 bug 還是需求遺漏、bug 等級是嚴重還是一般，能夠吵上 2 個小時，2 個小時吵不下那就拉上雙方主管再吵 2 小時，還吵不下那就拉上經理繼續吵 2 小時，於是最後就看誰會吵，誰官大，搞得程序員和測試員身心俱疲，關係很緊張！
2. 即使程序員的工作可以量化，那每次績效都是這幾個指標，定績效目標還有意義麼？
例如：假設考核程序員用 bug 數、代碼行數、版本數，那 2000 年用這個指標，2017 年也還是這個指標，這樣的績效目標有什麼意義呢？
3. 團隊 leader 如何制定團隊的 KPI？
例如：可以看兩個團隊誰的代碼行多麼？可以看誰的團隊 bug 數多麼？可以看誰的團隊版本數多麼？可以看誰的團隊分享次數多麼？這些其實都不行。
4. 前瞻性的工作誰願意做，有風險的工作誰願意做？
例如：引入 ElasticSearch 理論上是可以提升搜索性能的，但可能在引入的這一年反而會帶來很多問題，而能帶來多少收益還不確定，這個時候怎麼定 KPI？
OKR 的嘗試
帶著這些疑惑，我嘗試去進行一些探索或者改進，並試著去看看業界在面對這些問題的時候是如何處理的，於是順利成章的找到了 OKR 這個在矽谷網際網路公司比較流行的做法。然而很遺憾的是，雖然 OKR 有 Google、Facebook 這樣的大公司光環，但我剛開始了解 OKR 的時候，基本沒看懂 OKR 和 KPI 的區別，感覺這兩個東西基本上是一致的，只是換了一個說法而已。
我們以廣為流傳的Google投資人 John Doerr 介紹 OKR 的 PPT 中的樣例來看：
我第一次看到這個分解的時候，第一感覺就是：這不就是 KPI 麼？我們完全可以說：主教練的 KPI 分為 3 點，每點都有量化指標；公關經理的 KPI 有 3 條，但其中有 2 條沒有明確的量化指標，這點跟 KPI 不符合，但其實跟 OKR 自己的要求也是不相符的，例如如下的 OKR 要求第二條就是 measurable：
雖然出師不利，但我並沒有放棄（幸好我沒有給自己在這件事上定一個 KPI），而是繼續去查找更多資料，看看各種不同的解讀，再結合自己的思考和探索，然後在團隊中進行了小範圍的嘗試，發現非常有利於解決之前遇到 KPI 相關的困惑，通過這樣的「探索 - 嘗試 - 思考 - 改進」的方式，逐步真正的理解了 OKR，發現 OKR 真是團隊績效管理的一個利器！接下來我將整理一下理解和實踐 OKR 的一些關鍵點，希望讓更多的人擁抱 OKR。
深入理解 OKR
理解 OKR 的第一個關鍵：OKR 與 KPI 的區別是什麼？
OKR 全稱是 Objectives and Key Results，而 KPI 的全稱是 Key Performance Indicators，單純從名稱上來看，有點不同，但看起來又很類似，這也是我第一次接觸 OKR 的時候的疑惑，OKR 的 KR 和 KPI 沒什麼區別，但實際上這兩者的關鍵差別就在名稱裡面，如果不理解這個關鍵差別，實踐的時候就會感覺 OKR 和 KPI 是類似的。
OKR 和 KPI 具體的差別表現在：OKR 的關鍵詞是 Objectives，KPI 的關鍵詞是 Indicators！
不要小看了這兩個詞的力量，正是這兩個詞決定了 OKR 和 KPI 的本質差異：OKR 關注的是目標，KPI 關注的是指標。當我們關注「目標」的時候，我們會思考接下來我要做的事情是什麼；而我們關注「指標」的時候，我們會思考自己的工作如何評價。
- 以程序員為例，如果我們關注目標，我們會想接下來我應該做什麼事情，是要解決產品的卡頓問題，還是可以引入大數據來做精準推薦；而如果關注指標，因為我們的工作是編程，那我們就會想哪些指標可以衡量編程工作呢？我們想到的是代碼行數、bug 數、單元測試覆蓋率這些；
- 以足球運動員為例，如果關注目標，我們會想到奪冠、四強、保級；如果關注指標，那我們就會想到進球數、助攻數、跑動距離、比賽場次等；
- 以滴滴和快的為例，如果關注目標，快的的目標應該是超越滴滴；如果關注指標，快的的指標應該是司機數量、訂單數、乘客數等；
為何這兩種思考方式差異非常大呢？有一句名言形象的說明了這點：如果方向對了，就不怕路途遙遠！而如果方向不對，指標再漂亮都沒有意義，甚至指標越漂亮就錯的越大。目標就是我們的方向，指標就是評價我們做的事情的質量。使用 OKR 的時候，我們的思維第一反應是「我們的目標是什麼」；而使用 KPI 的時候，我們的思維第一反應是「我們的職責是什麼」，如果我們將思維固化在當前的職責，那就不會去審視整個環境當前的狀態以及後續可能的變化，也就不會及時的根據實際情況進行調整。
以《績效主義毀了索尼》一文中的例子為例：「具有諷刺意味的是，因單槍三束彩色顯像管電視機獲得成功而沾沾自喜的索尼，卻在液晶和等離子薄型電視機的開發方面落後了。」。因為彩色顯像管是已經在做的產品，按照 KPI 的方式去思考，自然是要將彩色顯像管銷量指標做的越高越好；但按照 OKR 的方式去思考，就會發現行業都轉向液晶和等離子電視了，應該儘快將目標轉向液晶和等離子電視，而不是繼續將目標放在彩色顯像管電視上。
再假設以快的和滴滴為例，如果按照 OKR 的方式來思考，快的的目標應該是「2014 年 Q4 超越滴滴」；如果按照 KPI 的方式來思考，快的的指標可能是「2014 年 Q4 訂單數增長 100%」，也許為了達到「2014 年 Q4 超越滴滴」這個目標，最終確實要求「2014 年 Q4 訂單數增長 100%」，但更可能的情況是為了達到「2014 年 Q4 超越滴滴」這個目標，最終要求「2014 年 Q4 訂單數增長 200%」，因為快的需要考慮滴滴本身的增長。單純從指標來看，「增長 100%」已經是非常厲害的了，而如果從目標來看，「增長 100%」卻還遠遠不夠！
彼得德魯克在《管理的實踐》中說：「並不是有了工作才有目標，而是相反，有了目標才能確定每個人的工作。所以企業的使命和任務，必須轉化為目標。」。我覺得這句話非常好的詮釋了 OKR 的本質，以及 OKR 和 KPI 的區別，形象的提煉一下：OKR 讓我們做正確的事情，KPI 讓我們正確的做事情！
理解 OKR 的第二個關鍵：OKR 與 KPI 的聯繫是什麼？
雖然我們前面深入剖析了 OKR 與 KPI 的關鍵區別，但這並不意味著它們就是截然相反，水火不容的。我們在實踐中會發現，OKR 最後的 KR 和 KPI 看起來沒什麼兩樣，這又是什麼原因呢？主要原因在於 OKR 中的 KR 和 KPI 的表現形式是基本一致的，OKR 的 KR 也要求 measurable，這點和 KPI 的「量化」指標基本一致，所以很多 KR 形式上看起來和傳統的 KPI 一樣。例如下圖，這裡面的 KR 我們說是 KPI 也基本沒問題：
OKR 和 KPI 的關係，用下圖來表示最形象不過了：
根據上圖的描述，我們可以看到，OKR 首先確定 O，然後從 O 分解出 KR，然後用 KPI 或者 Milestone 的形式來表示 KR。
這裡有一個細節需要特別注意：OKR 的 KR 可以是 KPI，也可以是 Milestone，這是為什麼呢？關鍵在於 OKR 要求 KR 是 measurable，中文譯為「可衡量的」，而 KPI 的指標要求是「可量化的」，也就是說衡量的方法更加廣泛一些，可以是「量化」衡量，也可以是「里程碑」式的衡量。
同樣以《績效主義毀了索尼》一文為例，索尼公司彩色顯像管的開發項目立項時的 KR 應該是「19XX 年開發出彩色顯像管電視」，這是一個無法量化的目標，但完全可以通過里程碑的方式來評估這個目標是否達成；再以足球隊為例，皇馬足球隊的聯賽 KR 應該是「奪取西甲聯賽冠軍」，這也是一個無法量化，但可以評估的結果，你總不能說為了量化改為「奪取 1 個西甲聯賽冠軍」，因為 1 年內根本不存在奪取多個西甲聯賽冠軍這個結果。
理解 OKR 的第三個關鍵：OKR 到底要不要和績效考核相關？
OKR 目前在美國矽谷的科技公司應用並取得了很好的效果，但介紹 OKR 的文章裡面無一例外的都提到了 OKR 和績效考核無關，例如 Facebook 的績效考核是 360 度環評，而中國公司的績效目前來看不太可能採用這種方式進行績效評價，那如果我們要推行 OKR，績效考核如何做？ 難道還要發明另外一套機制來進行考核？
前面我們分析 OKR 和 KPI 的關係的時候，提到了 KR 其實可以用 KPI 或者 Milestone 的形式來進行衡量，而這正好和我們傳統的 KPI 績效考核的形式是一致的，因此我認為根據 OKR 來進行績效考核並沒有什麼問題，而且可以從已有的 KPI 績效考核平滑的過度到 OKR 績效考核，只要考核 OKR 的 KR 是否達成，達成情況如何就可以了。
例如，我們在制定 KR 的時候，可以直接將結果等級包含進去。以恆大足球隊為例，如果 KR 直接定「奪取聯賽冠軍」，那考核的時候只有兩種結果：達到和未達到，考核就比較粗粒度了，但如果 KR 為「保底 4 強，滿意亞軍，爭取冠軍」，那就可以進行傳統意義上的績效考核了：4 強是「正常」，亞軍是「優秀」，冠軍是「突出」，許老闆也完全可以根據這個結果來決定發多少獎金 ：）
根據 OKR 進行考核的時候，還可能出現另外一個問題：KR 都達成了，但是目標沒有達成。例如快的的目標是「超越滴滴」，KR 是訂單數增長 200%，但到了年底盤點一看，訂單數增長 300%，但第一還是滴滴的，那這個到底算達成還是沒達成呢？其實如果按照 OKR 的核心是目標這個點來看，肯定是沒達成，畢竟目標是最關鍵的。
理解 OKR 的第四個關鍵：OKR 的「目標」從哪裡來？
OKR 最重要的是目標，因此要求目標本身就是正確的，不能憑空捏造或者胡亂猜想。一般在介紹 OKR 的文章裡面，都會提到「自上而下」的目標分解方式。例如球隊經理確定球隊目標，然後主教練和公關經理再根據球隊經理的目標來進行自己的目標分解，通過這種一層一層的分解，逐步將大目標分解到不同團隊不同個人的一個個小目標。這種分解方式要求團隊 leader 具備較強的業務理解能力。
我們在實踐中發現，單純採用「自上而下」的方式進行分解還不夠，還需要「自下而上」的提煉，即：團隊根據自己的業務和團隊情況提出一些專業上目標。以技術團隊為例，假如現在的系統問題比較多，團隊成員花費較多時間在處理各種線上數據問題，雖然由於團隊成員的能力很強，最終這些問題對業務沒有什麼大的影響，但站在整個團隊的效率和質量角度來說，這樣肯定是不正常的，因此團隊 leader 可能需要提煉「系統存儲結構優化」這個目標，而這樣的目標是難以採用自上而下的方式分解出來的。
自上而下的目標分解需要 leader 有很強的業務理解能力，而自下而上的目標提煉要求 leader 有很強的專業能力，兩者相輔相成，缺一不可，因此可以看出，實行 OKR 其實對 leader 本身也是一種考驗，因為要求更高了。
一個技術團隊 OKR 的實例
我們以一個假想的技術團隊為例，假設這個技術團隊做一款購物 APP，我們看看 OKR 應該怎麼做。
1、首先，業務負責人（或者決策團隊）要確定半年的業務目標，這個業務目標不能是眉毛鬍子一把抓，而應該綜合市場、用戶、競爭對手等分析的出來。例如：業務目標可以是用戶量增長，也可以是用戶活躍度，也可以是市場地位，還可以是訂單量，還可以是成交金額，還可以是利潤……那這半年到底應該以哪個或者哪幾個為目標，這是業務負責人（或者決策團隊）要想清楚的，而不能像 KPI 一樣，每個指標都按部就班的設定一個增長量就可以了。
2、假設業務負責人確定這半年業務目標是「用戶量增長」，然後業務負責人分解了幾個 KR，例如：「用戶量增長 50%」，「從 XX 管道買量 XX 萬」（這個是 KPI 式的 KR）、「6 月底新增 XX 業務」（這個是里程碑式的 KR）。
3、那麼技術團隊拿到業務 OKR 後進行分解，注意這裡的分解不是說技術團隊背一個類似「用戶量增長 20%」這樣的指標，因為這樣的指標是無法衡量這 20% 到底是不是技術團隊的功勞，而是要從技術的角度對業務的 OKR 進行分解。例如：「從 XX 管道買量 XX 萬」這個 KR 對技術團隊來說關係不大，可以無需關注；而針對「6 月底新增 XX 業務」這個 KR，技術團隊直接將其轉換為自己的目標即可。技術團隊對「6 月底新增 XX 業務」這個目標進行分解，得出 1 個 KR：「5 月 30 號完成開發 XX 業務開發，6 月 15 號上線」、
4、針對「用戶量增長 50%」這個 KR，初看好像和技術團隊沒有太大關係，但實際上這就是技術團隊需要基於業務來思考技術的一個典型 KR。技術團隊應該從技術的角度去分析業務的目標：哪些技術是和用戶增長量相關的，這些技術目前是否具備，是否目前做的不好還有優化空間。例如：影響用戶增長量的一些技術指標有「安裝包大小」、「App 啟動時間」、「App 崩潰率」、「App 耗電情況」……等等，假設經過分析后技術團隊認為目前安裝包太大，並且 App 啟動時間較長，那麼可以將這兩項相關的優化作為技術團隊的 OKR：「App 安裝包從 20M 縮減到 8M」，「App 啟動時間從 2s 優化到 500ms」，而這兩個 KR，業務負責人幾乎是不可能提出來的。
5、除了上面的自上而下的目標分解外，技術團隊也需要從團隊和技術本身的角度來思考是否有這個階段需要重點做的事情。例如：我們團隊目前的版本節奏較慢，而慢的原因是因為版本多而測試環境不足，測試環境不足是因為機器不夠，那可以得出一個目標「解決測試環境不足導致版本等待的問題」，分解出來的 KR 可以是「添加 4 台測試環境機器」（是的，雖然是一件很簡單的事情，但這也可以作為 KR），也可以是「引入 Docker，支持一台機器搭建 20 套環境」（這個 KR 比較符合技術人員的理解）。
通過這種 OKR 的方式進行思考和分解，最終技術團隊要做的事情如下：
- 「5 月 30 號完成開發 XX 業務開發，6 月 15 號上線」
- 「App 安裝包從 20M 縮減到 8M」
- 「App 啟動時間從 2s 優化到 500ms」
- 「引入 Docker，支持一台機器搭建 20 套環境」
寫在最後
OKR 對很多人來說還是一個新事物，我接觸 OKR 並不久，也許還有很多東西沒有徹底理解，也許實踐中也還會遇到各種各樣的困惑，但是單純從思路的轉變來看，我認為 OKR 不僅僅是一個績效和目標管理方法論，更是一種「聚焦目標」的思維方式，掌握這種思維方式后，不僅可以在工作中應用，在個人生活中也完全可以應用，並都能夠取得很好的效果！