科技界流傳的 OKR 系統有用嗎？

OKR 系統誕生於70年代，但是直到最近才受到了Google歡迎，並在科技界流傳開來。

作者 | ZAFU LABS

譯者 | 彎月，責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

在過去5年中，我工作過的大多數公司都會使用目標與關鍵成果（Objectives and Key Results，簡稱OKR）系統。這個系統誕生於70年代，但是直到最近才受到了Google歡迎，並在科技界流傳開來。

這個系統本身很簡單：公司負責定義多個目標，而且每個目標都有一個或多個可衡量的關鍵成果。這些關鍵成果旨在跟蹤目標的進展情況。

例如：

• 目標：提高客戶回頭率
• 關鍵成果#1：終身客戶價值從$N提高到$N + 5
• 關鍵成果#2：客戶流失率降低10%

我工作過的大多數公司通常都會制定3-5個OKR。

OKR對公司有何好處？

OKR的初衷基本上是讓公司里的每個員工都有一些直接性的、非常清晰的、可衡量的目標。團隊的一切工作都應該與為特定的OKR服務。從理論上講，這意味著所有人都朝著同一個方向划船。

在某些級別和某些方面，OKR能發揮很好的作用。對於領導團隊來說，通常這似乎是一個很好的機制。它可以讓所有領導都達成一致，並為每個季度提供一個很好的起點。

然而，當開發團隊做出決定時......

在獨立團隊的決策過程中，OKR並沒有用武之地。——Joe Cannatti

最常見的模式如下：

• 團隊開始討論積壓的工作，看看哪些需要處理。
• 他們討論了每一項工作，並制定出了一個按照優先順序排列的基本清單。他們知道短期內都他們都顧不上剩下的工作。
• 他們遍歷一遍清單，並為每個任務/工作項添加標籤，指明哪些工作與OKR的關係最為緊密。
• 在大多數情況下，通常他們無需太費神，就可以為每項工作分配一個OKR。

等一下……這個順序是不是顛倒了？

難道我們不是應該首先通過OKR提出想法嗎？為什麼現在反過來把這些OKR放入了相應的工作中呢？

然而，我認為這就是開發團隊的做法。

積壓的工作項

在我看來，開發團隊採用這種方式的原因通常在於，他們有大量積壓的工作需要處理。這些積壓的工作大部分都是根據當時的OKR制定的。

因此，在當時的OKR下，這些工作都是有意義的，我們只需要將我們已有的工作融入到OKR中。

這有什麼不對嗎？

是，但也不是。

在我看來，最大的問題在於，開發團隊感受不到實際的工作與OKR之間的聯繫。例如，在我寫這篇文章的時候，我可以告訴你這個季度我們打算嘗試的每個項目，但我甚至無法說出本季度的OKR是什麼。

我們能夠讓所有工作都符合OKR，卻從來不覺得OKR能夠指引我們的工作。也許這沒問題，但對我來說，OKR並不是很有用。我認為OKR給領導們提供了一個理由，讓他們宣稱每個員工都朝著相同的目標努力，但我認為這並不會讓開發團隊相信這一切是真的。

改善OKR運作方式的想法

關於如何讓團隊在下一個計劃周期中更好地工作，我有以下幾點想法：

放棄積壓的工作

當開始新一輪的計劃時，請考慮放棄積壓的工作項。不要以團隊以前定義的工作為起點，而是應該從頭開始。

以OKR為出發點，看看團隊能否提出以前沒想到的一些想法。或者，看看他們是否能夠用有意義的方式重新構建他們現有的想法，讓他們真實地感受到OKR的作用。

這不是一件容易的事情。你需要讓所有人都遠離以前積壓的工作，但我認為最終你們可以取得更好的成果。

通過OKR來推動每周的團隊會議

在每周的衝刺計劃以及其他簽到的會議上，以OKR為起點。

一般來說，這些會議會自然地遵循你們正在進行項目和任務所塑造的模式，但是你也可以將討論引回到OKR上。

OKR對你們團隊有什麼影響？

我很希望聽聽OKR對你們團隊有什麼影響。 如果你們也採用OKR，那麼你希望有什麼不同？請在下方留言。

原文：https://zafulabs.com/2019/05/24/okrs-from-a-development-teams-perspective/

本文為 CSDN 翻譯，轉載請註明來源出處。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！