OKRs 和 KPI 的區別到底在哪裡?

OKRs 和 KPI 的区别到底在哪里?

Q1:OKRs 和 KPI 的區別是什麼?

這個問題我還是有些發言權的,因為我在微軟的時候,有一項工作是和 Global Reporting Team 對接,進行 KPI Report 在大中華區招聘團隊的落地。每個月我要提交我們的數據,並且能看到所有國家地區的 KPI 完成情況的彙總和排序。

有 KPI 相比於什麼都沒有肯定是更好的。至少我們知道要關心哪些指標,這些指標作為一個明確的準則,可以來幫助我們優化自己的工作。

但 KPI 在當時確實沒有滿足我的工作需求,我經常乾的事情就是不斷地追問為什麼。

KPI 裡有一條我很感興趣,就是新員工入職兩個月內的離職率。設置這條 KPI 的目的是為了保證招聘質量。

如果只盯這個 KPI,其實有很多辦法去實現它,比如,我可以設置一筆入職 3 個月後才能發放的入職獎金,我還可以設計週期較長的入職體驗來降低 2 個月內考慮離職的可能性,甚至我還可以靠個人關係請求同事不要影響我的 KPI——顯然,這些辦法看起來都不能保證招聘質量。在 KPI 體系裡,其實不是沒有 O,而是 O 被隱藏了,如果沒有人知道或者沒有人去溝通,這個 O 很可能就不能被實現。

另外一個我關心的問題是:「為什麼所有國家和地區要使用一樣的 KPI?」 比如,KPI 裡有一個最常見的指標——招聘完成率。假如是在業務成熟穩定、招聘量不大的國家,填補崗位是為了填補工作量,而不是要解決業務的難題,那麼招聘完成率是個合理的指標。

但當時中國的部門在業務和團隊上都處於高速發展。一方面業務是需要一些關鍵人才的;而另一方面招聘部門每個人的招聘壓力非常大,如果為了讓招聘完成率的 KPI 更好看,很有可能的做法是先把量大好招的崗位先填了,但這又不一定能最優地滿足關鍵人才的招聘。所以,雖然 KPI 看起來和 OKRs 中的 KR 很像,但由於 KPI 的 O 是隱藏的,我們往往很難準確地判斷 KPI 的設置是否是對的。

那麼,OKRs 和 KPI 的區別,就是多了一個 O 嗎?KR 相當於 KPI 嗎?並不是。

我們思考 OKRs 的過程,不是先去想 KPI,而給它按一個 O。是要先定下 O,再從 O 出發去想,描述這個 O 實現時的 KR 是什麼。

以剛才「新員工入職兩個月內的離職率」這個 KPI 為例,我們試寫一個 OKRs。

Objective:保證新員工質量滿足公司發展的需求

    • KR:入職一個月內,新員工能夠按照預期職責開展工作,並表現出積極的工作態度

    • KR:入職後的第一次績效考核中,新員工符合績效標準

    • KR:入職後的半年裡,新員工體現出來的行為符合公司的文化

這裡我們會發現,KR 不是單一的,而且和之前的 KPI 不一樣。還有很重要的一點是:KR 並不一定是個量化指標,它只需要「有時間限制」、「可衡量進度」即可。

Q2:什麼情況下適合用 OKRs,什麼情況下適合用 KPI 呢?

OKRs 和 KPI 本身都是工具而已。工具的最大價值在於提高效率。

那麼,首先我們要考慮的是:公司有沒有「目標管理」上的效率問題?比如,很多人做的事情跟公司策略沒關係;每個人做了很多事情,公司業務卻沒有進展;員工不知道自己做哪些事是有用的,要做到什麼程度是有用的。這些都是「目標管理」上的效率問題。有效率問題,引入工具就會有所幫助。

從前面一個 QA 裡,我們可以看到,OKRs 相比於 KPI,提供了一顆清晰可見的北極星,幫助我們儘量專注並且不跑偏。長期來看,OKRs 可以避免更多執行中的彎路和無用功。

但另一方面來講,工具的使用也存在時間成本。OKRs 使用的時間成本,在引入初期一定是比 KPI 高的,因為它要求思考的過程更細緻、溝通的過程更充分。

所以,當業務非常成熟穩定的時候——預期的結果是確定的,實現結果的方法也是確定的,只要將既定的方法執行到位就一定能達到預期的結果——這時候,依靠經驗制定的 KPI 大體是不會錯的,使用 KPI 其實就能發揮很好的作用了。使用 OKRs 的效率反而可能沒有 KPI 高。

相反的,如果我們在做一件不確定性很大的事,或者解決問題的方法不確定的時候,比如做創新業務的創業公司(e.g. Google),探索新方向的大公司(e.g. Intel),KPI 很有可能會把我們帶偏,或者約束我們的創造力。這時候我們就應該考慮引入 OKRs。

Q3:OKRs 和研發流程的管理會有重複或者衝突嗎?剛開始使用會不會帶來很麻煩?

有不少科技公司在諮詢時會提到,產品和技術團隊本身已經有一套管理研發項目的流程了,使用 OKRs 對他們來說是不是要使用兩套並行的工具。

這裡需要指出的是,研發流程的管理,是過程管理,而 OKRs 是目標管理。簡單的說,OKRs 決定了哪些工作應該進入研發流程,以及研發流程的週期長短,而不會干涉研發流程中的管理。

至於引入 OKRs 會不會很麻煩。我想必須搞清楚的一點是:思考目標是什麼,拆解目標,按照目標優化工作,評估目標實現的進展,是本來就應該做的事情,而不是因為我們要使用 OKRs 才要來做的事情。OKRs 作為工具,是來幫助我們提升做這些事情的效率的。

如果我們認為做這些事情是一種「麻煩」,那麼當然,引入 OKRs 會很麻煩。如果我們想要把這些事情做好,那麼引入 OKRs 就是一件事半功倍的事情。

我想引用之前去華為做分享的時候,華為的一位經理說的:

「OKRs 並沒有增加我的溝通成本,它反而大大減少了我的溝通成本。因為我一旦制定好、溝通好 OKRs,我的團隊就能主動地、高效地跑起來,不像以前需要在執行的時候反覆溝通。」

CIO之家 www.ciozj.com 微信公眾號:imciow


分享到:


相關文章: