OKR 管理本來就是為所有層級而設計的。

上述兩本奠基性書籍中都經常提到個人 OKR。事實上，《Measure What Matters》一書描述了 Google 高管要求所有員工在規劃期前提交 OKR，這是一種全公司範圍的 OKR 實施方式。但這種方式在個人層面上最終是如何運作的呢？我們稍後會進一步討論。 值得注意的是，OKR 管理框架並不是專案管理。 高層 OKR 的作用是確定戰略性目標（Objectives），並明確達成這些目標所需的關鍵結果（Key Results）。以下是一個技術專案的 OKR 示例：

目標：開發革命性的 AI 驅動 Python 編程軟體。

關鍵結果：

• 展示 AI 編程如何將編程時間減少 50% 的 5 種方式
• 演示 AI 編程如何降低 35% 成本
• 證明 AI 編程如何減少 75% 的程式錯誤

正如你所看到的，OKR 只是指引方向。至於如何通過工程努力（即專案管理）來達成這些關鍵結果，則是研發團隊的工作。這意味著公司中許多活動並不屬於 OKR 的範疇，而這樣的安排是合理的——詳見《專案管理中的 OKR 是什麼？》

因此，看起來 OKR 似乎並不適用於個人層面。

個人 OKR 的經驗是怎樣的？

本·拉莫爾特（Ben Lamorte）在《The OKRs Field Book》中提到，Google 的全員 OKR 實施在個人層面上僅部分有效——有些員工受益，而其他員工則認為這只是浪費時間。 他還提到：

• 低層級的 OKR 經常變成待辦清單，而不是具挑戰性的目標。
• 有些員工刻意降低 OKR 目標，以確保能輕鬆達成結果，這種行為被稱為「設低標」（sandbagging）。
• 有時候 OKR 並不適合某些職位。例如，一位客服團隊的主管已經有完善的績效追蹤系統，擔心額外實施個人 OKR 會適得其反。

拉莫爾特建議，個人 OKR 應該是一種可選擇的方式。

數據顯示什麼？

關於 OKR 實施的統計數據並不多，但根據 OKR International 2024 年的研究，僅有 23% 的企業 在全公司範圍內實施 OKR。 有些公司全員使用 OKR，而有些公司則只部分實施。為什麼會這樣呢？

企業的結構和運作方式是多樣的

從各種文獻中我們可以看到，OKR 的理念確實能幫助企業成長和繁榮。但現實情況是，工作環境的差異使得 OKR 無法適用於企業的每個層面。企業規模大小也影響 OKR 的可行性。 然而，OKR 本身具備靈活性。企業可以根據自身需求調整 OKR，使其適應獨特的組織文化。此外，即便企業不在所有層級強制執行 OKR，仍然可以在概念上貫徹其核心原則。

哪些團隊適合 OKR？

在討論或教學 OKR 時，常以運動為例。原因很簡單，運動比賽的成果可以透過數據衡量，如安打數、打點（RBI）、勝負比、投球局數等。在 OKR 框架下，很容易設定、追蹤和監測這些數據。 在商業領域中，銷售也是適合 OKR 的部門。為什麼？因為銷售工作涉及許多可量化的數據，例如成交數量、電話聯繫次數、會議安排數、潛在客戶數、點擊成本等。這些可衡量的業務指標讓銷售團隊能夠順利實施 OKR，甚至能延伸到個人層級。

工程領域並不適合 OKR

我發現，工程領域在個人層級下並不適合 OKR。原因是，許多工程專案的工作內容由研究、設計、編碼、原型測試、測試驗證等組成。而 OKR 並非待辦事項清單。 當然，你可以嘗試將可衡量的結果應用到所有這些環節，但我認為，這可能正是部分 Google 員工認為 OKR「浪費時間」的原因。 我不會要求工程師在每項工作中都必須設定可衡量的目標，但我會鼓勵他們在 OKR 框架下提升意識並嘗試應用它。

但 OKR 的概念仍可應用於工程領域

在台灣科技公司中，研發專案的管理方式常常不夠嚴謹。許多任務和時間安排往往依靠直覺估計，導致部門衝突、專案延誤和變更——令人沮喪。 為了解決這個問題，我們嘗試為工程師實施OKR 的自下而上方式：

• 教導工程師基本的任務拆解和進度規劃。
• 鼓勵員工記錄計畫，並每週進行 OKR 進度檢查。
• 培養員工反思自己的成功與失敗（OKR 促進改進與批判性思維）。

簡而言之，我們透過 OKR 讓員工成為自主管理者，並為未來的晉升做準備。

鼓勵個人層級積極參與 OKR

OKR 讓員工有機會學習、成長、並與公司目標保持一致。這能提升個人競爭力、避免裁員風險、並幫助員工提升職涯發展。 我們看到了一些驚人的變化——普通銷售員成為知識豐富、能力出眾的公司代表，能夠進行精彩演講並超額完成銷售目標。