OKR為何不適合衡量個人績效?

Use OKRs to Set Goals for Teams, Not Individuals
傑夫.高瑟夫 Jeff Gothelf
瀏覽人數:8148
pepifoto / Getty Images
近來,愈來愈多企業改用OKR來衡量團隊績效,然而,如果領導人想用OKR來衡量個人貢獻,往往就會出現兩種常見錯誤:無助於判斷員工是否真的實現有意義的成長或改進;員工不願冒風險設定更具企圖心的目標。相反地,領導者對個人貢獻者的評估,應該基於他們的工作對團隊目標達到如何的貢獻程度,以及這些目標能給公司和客戶帶來什麼真正的價值。

「目標(objective)與關鍵結果(key result)」,簡稱OKR,這個架構已成為團隊在規畫和衡量工作成果時,最普遍使用的架構之一。使用這套系統時,組織內各層級主管首先界定出高層次、質性、具激勵性的目標,也就是OKR的O(目標),接著再界定,誰會成為團隊工作成果的使用者或消費者,而他們預期,那些消費者會有哪些行為上的改變,這些改變,可用來量化團隊是否達成之前界定的高層次目標。這些可量化的結果,就是OKR的KR(關鍵結果),用來衡量團隊在實現目標方面的表現如何。

這種方法讓主管在規畫和追蹤進展時,聚焦在工作產生的影響,而不是巨細靡遺地管理團隊每天做的具體工作內容。因此,這是一種有效的機制,可以讓由上而下制定的策略,與由下而上、團隊為達成中期目標,而努力採取的各項行動,能朝一致方向努力,以支持實現那項策略。顯然,OKR的好處,在於不強調具體的工作任務,而是強調這些任務帶來的價值。

然而,如果用OKR來衡量個人貢獻,往往就會顯得不足。要求員工設定自己的目標和關鍵結果,通常會出現以下兩種結果之一:

1. 員工設定「是或否」達成的目標,很容易衡量,卻無助於判斷他們是否真正實現有意義的成長或改進。

2. 員工選擇有把握達成的目標,不願冒風險設定更具企圖心的目標。

先來看看第一種失敗模式。我今年稍早和一家線上遊戲公司合作,協助他們轉為採用OKR。在執行這個專案時,公司要求所有員工(包括個人貢獻者)制定個人的OKR,以下就是一位軟體工程師設定的目標和關鍵結果:

目標:在2021年第二季結束前,提高我的程式設計技能,達到中級軟體開發人員的評級。

關鍵結果:參加三門最新程式語言的課程。

關鍵結果:讀十本關於如何成為傑出軟體工程師的書。

關鍵結果:獲得DevOps專業人員認證。

再舉我另一位客戶的例子,下面內容來自一位行銷部門的個人貢獻者:

目標:在2021年第二季結束時,讓我們的線上廣告活動,產生更大的影響。

關鍵結果:廣告活動增加30%。

關鍵結果:聘用更高水準的設計公司。

關鍵結果:提交事業單位報告的正確度提高50%。

這些目標看似有說服力,但問題是,其中沒有任何一項,能真正衡量這些員工是否成為更好的程式設計師或行銷人員。關鍵結果要能發揮作用,就必須要能衡量某項工作的目標受眾的行為是否有改變。如此才能讓關鍵結果成為衡量成功的客觀指標,而不只是記錄他們投入的精力。

在前面提到的兩個例子當中,設想的關鍵結果,其實根本不是衡量行為改變的指標,只是在描述產出,也就是那兩名工程師和行銷人員打算做哪些工作,希望藉此協助他們實現目標,而不是顯示價值真的增加了。如果只是執行這些計畫,不足以客觀地評估,那些員工的技能、幫公司或客戶增加價值的能力是否已改進,因而這些計畫,只是員工希望在第二季結束前執行的活動(這些活動有可能產生實質的影響,也可能沒有對任何人造成影響)。

再來看看第二種失敗模式。以那位工程師的情況來說,她如果把關鍵結果改為更符合實際工作產出的情況,就可以操縱結果輕鬆過關:

關鍵結果:把我為生產部門寫的程式錯誤減少50%

減少程式錯誤,確實應該是每位軟體工程師的目標,但雇主如果把績效評估和薪酬,與實現這樣的關鍵結果掛鉤,員工就只會選擇風險較小的工作來做(這是許多組織一直在犯的錯誤,即使專家建議別這麼做)。畢竟,承擔較少風險極有可能減少創新,最終會限制團隊和整個組織的成功。

同樣地,前述那名行銷人員可能會把關鍵結果改為:

關鍵結果:確保所有行銷方案第一次提交,就通過法務的核准。

跟工程師的例子一樣,這樣的關鍵結果,將造成行銷人員減少冒風險,以確保所有行銷方案第一次提交就獲得批准,結果削弱了創意,排除績效顯著提升的可能性。

要避免這兩種失敗模式,OKR必須重新設計,找出不只是跟員工個人職務有關的目標,也與員工正在負責的整體產品或計畫有關的目標。這就是OKR如此強大、又這麼難以實施的原因。衡量成功的指標,不是員工所做的事情(產出),而是跟員工工作有互動的人,出現行為上的改變(結果)。提升到這種層次的目標,本質上就不可能單憑個人實現,勢必需要多個團隊成員共同努力。

例如,對那名工程師更有意義的目標,也許是把搜尋引擎的準確度提高25%,但這不是工程師可以獨力完成的目標,因為不只牽涉到搜尋演算法的編碼,還包括搜尋結果頁面的設計、針對個別用戶把搜尋結果個人化、大量數據的分析,以及許多其他因素。真正注重影響力的目標,幾乎都需要團隊協作,不可能靠任何單一個人獨自完成。

針對這一切,有個有趣的提醒,那就是在個人生活當中,OKR架構其實可以在個人層次上運作良好,可以應用在個人目標、家庭生活、職涯發展,或是個人生活的任何其他方面。比方說,你可以給自己設定一項個人目標,要在自己從事的行業建立更響亮的名聲。在這種情況下,你的關鍵結果,可以是別人對你的聲譽有什麼看法,或者,更具體地說,這種看法促使他們採取什麼行動,例如,訂閱你的電子報、在LinkedIn把你加為朋友或追蹤你、邀請你在座談會上演講等。這裡的重點是,你努力做的事情,它的使用者(也就是你設法改變他行為的那個人)是第三方,而不是你自己。

但在工作場所,OKR是以團隊為基礎的目標設定方法。有共同的目標,以及可量化的指標,能協助團隊協調彼此的活動,並與利害關係人互相配合,行動時不會只考慮到自己的近期目標。在OKR架構內,成功不是以任何個人做了什麼來衡量,而是對整個團隊打造的產品及服務使用者,會產生什麼影響。因此,不要用OKR來設定個別員工的目標,用OKR來界定團隊目標,才能真正發揮作用,更有效的做法,是採取團隊層次的觀點,績效評估和薪酬不要連結到員工個人的目標和指標,而要連結到個人貢獻者,對團隊目標和關鍵結果的貢獻程度。

(張靖之譯)



傑夫.高瑟夫

傑夫.高瑟夫 Jeff Gothelf

協助組織打造更好的產品,也協助高階主管建立能打造更好產品的文化,是獲獎著作《精實使用者體驗》(Lean UX)的共同作者,也在哈佛商業評論出版社出版過《感知與回應》(Sense & Respond)。他擔任高階主管教練、顧問和演講人,協助企業彌合企業敏捷度、數位轉型、產品管理和人因設計之間的落差,最新著作《恆常就業力》(Forever Employable)在2020年6月出版。


本篇文章主題管理員工