程序員的工作怎么量化？bug 數？代碼行？版本數？
做過程序員的都知道，這些指標都是不可行的。
例如某通信大廠考核程序員的 bug 數和等級，並且更加讓人蛋疼的是同時考核測試人員發現 bug 的數量，結果程序員和測試員為了一個問題是 bug 還是需求遺漏、bug 等級是嚴重還是一般，能夠吵上 2 個小時，2 個小時吵不下那就拉上雙方主管再吵 2 小時，還吵不下那就拉上經理繼續吵 2 小時，於是最后就看誰會吵，誰官大，搞得程序員和測試員身心俱疲，關系很緊張！
即使程序員的工作可以量化，那每次績效都是這幾個指標，定績效目標還有意義么？
例如：假設考核程序員用 bug 數、代碼行數、版本數，那 2000 年用這個指標，2017 年也還是這個指標，這樣的績效目標有什么意義呢？
團隊 leader 如何制定團隊的 KPI？
可以看兩個團隊誰的代碼行多么？可以看誰的團隊 bug 數多么？可以看誰的團隊版本數多么？可以看誰的團隊分享次數多么？這些其實都不行。
前瞻性的工作誰願意做，有風險的工作誰願意做？
例如：引入 ElasticSearch 理論上是可以提升搜索性能的，但可能在引入的這一年反而會帶來很多問題，而能帶來多少收益還不確定，這個時候怎么定 KPI？
如果我們關注目標，我們會想接下來我應該做什么事情，是要解決產品的卡頓問題，還是可以引入大數據來做精准推薦；而如果關注指標，因為我們的工作是編程，那我們就會想哪些指標可以衡量編程工作呢？我們想到的是代碼行數、bug 數、單元測試覆蓋率這些。
一個技術團隊 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 號上線”。
針對“用戶量增長 50%”這個 KR，初看好像和技術團隊沒有太大關系，但實際上這就是技術團隊需要基於業務來思考技術的一個典型 KR。技術團隊應該從技術的角度去分析業務的目標：哪些技術是和用戶增長量相關的，這些技術目前是否具備，是否目前做的不好還有優化空間。
例如：影響用戶增長量的一些技術指標有“安裝包大小”、“App 啟動時間”、“App 崩潰率”、“App 耗電情況”……等等，假設經過分析后技術團隊認為目前安裝包太大，並且 App 啟動時間較長，那么可以將這兩項相關的優化作為技術團隊的 OKR：“App 安裝包從 20M 縮減到 8M”，“App 啟動時間從 2s 優化到 500ms”，而這兩個 KR，業務負責人幾乎是不可能提出來的。
4、除了上面的自上而下的目標分解外，技術團隊也需要從團隊和技術本身的角度來思考是否有這個階段需要重點做的事情。
例如：我們團隊目前的版本節奏較慢，而慢的原因是因為版本多而測試環境不足，測試環境不足是因為機器不夠，那可以得出一個目標“解決測試環境不足導致版本等待的問題”，分解出來的 KR 可以是“添加 4 台測試環境機器”（是的，雖然是一件很簡單的事情，但這也可以作為 KR），也可以是“引入 Docker，支持一台機器搭建 20 套環境”（這個 KR 比較符合技術人員的理解）。
通過這種 OKR 的方式進行思考和分解，最終技術團隊要做的事情如下：
01. “5 月 30 號完成開發 XX 業務開發，6 月 15 號上線”
02. “App 安裝包從 20M 縮減到 8M”
03. “App 啟動時間從 2s 優化到 500ms”
04. “引入 Docker，支持一台機器搭建 20 套環境”