採用OKR後的化學效應

Published in

1:1 with ATeam

Jun 21, 2024

幾乎每半年或一年會進行團隊管理上的迭代。這次我正式引入研究許久的OKR，正式的包裝目前團隊既有的流程。

團隊成立到現在也即將到第五年。一路上我持續地把比較複雜的模式，不斷的精簡翻新，也盡量貼近當時的時空，無論是公司策略或成員組織去調整。

核心則是秉持著文件驅動的模式，這邊可以參考到亞馬遜(Amazon)創辦人Jeff bezos所宣揚的理念。這部份深植我心，也因此我也是用力地植入團隊的DNA中。

但點線面，其實不同層次，而文件比較靠近點這一層，因此線跟面，在看似有一套邏輯但又解釋不出來的同時，就在今年下半年正式引入OKR。

接著會來談談以下三點

為什麼我會選擇OKR

其實我採用過OGSM，但可能研究的時間不夠多之外，幾年前的我還不夠成熟，摸索的範圍也不夠多。雖然表格有出來，跑了一年也有對齊到核心精神，但就是沒有繼續下去的動力。主因還是因為複雜。

理論很多，工具很多。但對應到我們的公司節奏以及團隊大小來說，要選對工具才是最正確的方向。

到近兩年，團隊比較偏向採用圖中橘色的區塊。我們會從專案page中長出backlog，接著開啟每一個sprint去追蹤，最後完成roadmap上的目標。

其實我們已經做了一半了，只是沒有一個架構去檢視。當OKR進來後，補足了左側綠色區塊，這一切就都通了。

最重要的就是，這流程的核心就是：聚焦。

同時剛好手邊有<<博客來-OKR：做最重要的事 (books.com.tw)>>。發現，這書不是告訴你OKR是甚麼，像教科書一樣解釋OKR。OKR簡單到不需要說明，但它需要的是成功案例！

在聚焦與簡潔的基礎下，將大方向抓住後，底層邏輯可以依照實際情況搭配，也就是上至下，下至上的串接結構，全員參與，而非一人導向。無需贅言的架構是我決定選擇OKR的原因，當然同時，我們團隊也早就操作了類似OKR的KR部份了。

首先直接先引入這兩個指標：KR Rate及KR Stauts。

if(prop("KR Rate (0~1)") <= 0.3, "🔴", if(prop("KR Rate (0~1)")> 0.7, "🟢", "🟡"))

在理解這兩個指標前，先談談在此之前遇到哪些狀況。

你不知道到底怎樣叫做完成，又或者為了要定義完成，其實那些支微末節的事情不利於開發進度。而大部分在sprint中，修改task的狀態並沒有一個明確的”意念”去給予狀態修正後的評分。因此，修改狀態去跑sprint變成一種自動導航，好像只要把task消掉季好，並沒有從每一個task中去獲得反思。
現在團隊都知道，不要用過度簡易的標題去列task，因為這不利於追蹤與討論。然而大多時候，雖然看似完整，但卻不見深度。最後還是回歸到上一點，用人自身的認知及那抓不住的觀感去決策最後的task狀態。

從以上兩點可以感受到出來，我們很難用感覺去描述一件任務的深度與結果。

就在OKR這兩項指標進入後，大家獲了得解放！

列task就可以先給予一個指標(KR Rate)，問問自己：我預期它會是甚麼樣的KR Status。這會去影響你這個sprint的安排。而避免去安排過多或過於簡單的task。
有了KR Rate更容易地去定義狀態改變後的follow up。完成也有分程度，也可能會落在紅燈(KR Status)，要不是非常有挑戰，就是臨時改變策略，僅碰了一點皮毛，就被其他task給取代。但在sprint的過程中，我們就可以消除噪音，聚焦在真正的開發進度上。團隊們也不會糾結在於，列錯task或不好意思將task的狀態改到Done。

這兩項指標完整的解放團隊，讓過去一些尷尬曖昧不明的環節得以解脫。而對專案管理者來說，更可以利用平均值去評估這項任務目前的健康程度及深度。

KR Status，更可以檢視task的難易程度。這也就對應到OKR提到的里程碑或理想型。這也更可以促進團隊去發想與開發更困難的環節，設定更高的挑戰也不會怕在專案進度會議上被Review。因為指標這件事情會被Review，一但達成共識後，只有成不成功，失敗就不太是需要擔心的事情了。