運用OKR來量化Sprint的目標

作法

將Sprint衝刺的目的定成目標Object, 然後為這個目標設定三個關鍵的結果(key result),每個結果都必須能夠量化成數據(由0.0到1), 對那些不易量化的結果則預先設定達成何種成果就給它相對的分數,並以難易度來給分。

(給分依據:很難幾乎不可能達成的給1分,必須很努力才能達成的給0.7,稍稍努力就能作到的給0.5,循正常工作就能達到的給0.3,而完全沒作到的就給0分)

然後在計畫會議時由團隊一起來設定關鍵結果,再在最後作回顧會議時一起來打分數(花上3~5分鐘)。然後在每天的站立會議時過一下團隊進度與預期目標的達成狀態,進行檢討。

這麼作你便能運用OKR的設定來量化Sprint的目標了。

.

囉嗦一下:

Sprint的結果無法被量化一直是管理人員的困擾,我們也都相信完成故事點的多少並不能做為開發效能的依據(註1,這裡挑戰了你對敏捷的認知,不要太迷信於故事點),而故事點的多寡最多只能用來看待團隊所面臨負荷大小的參考而已。但在日常的Sprint運行上,我們又常常會面對到一些需要量化才能回答的問題,例如:

.

(高層總是擔心)

  1. 團隊到底是表現得好還是不好?
  2. 我們作對了嗎? 現在的開發方式需要改變嗎? 要怎麼變?

.

(Scrum Master 則常常收到)

  • PO經常抱怨開發團隊只會埋頭苦幹,沒有商業價值的觀念。
  • 團隊每個Sprint週期,都是以完成所有工作為目標,而不是以達成商業價值為目標。

.

老實說;這些問題都很難給出明確的答案,即便是團隊現在顯得工作的很愉快,自組織的味道也逐漸在成型,但這還是不足以回答他們到底表現得如何?接下來又會往哪裡去的問題。面對這些疑惑,運用OKR(Object & Key Result) 正好可以拿來正本清源。

.

目標導向理論是激勵理論的一種。是要求領導者排除達成目標的障礙,

使其順利達到目標,並在過程中,給予員工滿足多種多樣需要的機會。

 – wiki

.

OKR是一種目標導向的引導工具

它是在敏捷宣言誕生之前就存在的一種敏捷理念,安迪.葛洛夫Andy Grove 於1990年在擔任英特爾執行長時所推行的一種簡化版的目標管理法(MBO 註 2. 來自管理學大師 彼得.杜拉克),是一種比Scrum 還要簡單的引導理論,但卻能夠成功的解開Sprint 難以度量的問題,還能夠依據成果導向來激勵團隊開發的衝刺效果,所以我把它跟Sprint的過程畫在一起,讓我們來看看如何融合OKR於Sprint的衝刺過程中的做法。

.

0007.png

為一個Sprint衝刺設定目標及Key Result

.

首先;讓OKR的目標與Sprint的衝刺目標對齊,讓「關鍵結果」成為DoD.

它會讓Sprint衝刺的目標更加明確,有很好的聚焦效果,工程師也會因此而開始關注Sprint所要達成的商業價值。做法是讓團隊在Sprint計畫會議時依據Sprint所要達成的目標,團隊一起定下「關鍵結果」Key Result,這樣作可以讓這個衝刺期間能夠更加關注項目的定義完成 DoD (Definition of Done),這會讓每個工作單完成的定義,變得更為明確。

  • 上圖描述的是將專案分成為多個Sprint的目標,然後在計畫會議時針對這個目標來制定它的關鍵結果Key Result,再持續用它來做為評估是否達成目標的依據。好處是; 工程師會依據目標是否達成而開始關注目標的商業價值,它聚焦了Sprint的衝刺目標,當目標達成時,剩餘的工作單就值得討論是否該拋棄或下一次在作了。

.

Object : 我們想作什麼?

Key result : 我們如何知道是否已達成了目標.

– 開始時不能忽略的提問

.

每日檢討;讓團隊成員以一周為單位設立個人目標。每週週一賦責,週五慶功,並於每日的站立會議加入報告第四件事: 也就是目標達成的狀態說明。能夠即時更新檢討實施的成果,便於修正改善。而缺點是每個人都設定自己目標,常常容易導致團隊目標失焦,因為目標設定多了、太細了花太多時間在目標設定上而少了真正的工作時間,人們很容易便會只專注於自己的使命,而忽略了團隊的使命。(建議先實行團隊的OKR待團隊成熟後再來嘗試個人的OKR,因為個人OKR往往會被導向個人績效的評核,容易走偏了,請謹慎為之)

.

0008.png

OKR 的神奇力量,來自0.7的給分標準

.

好的KR應該是定量的、有挑戰的、具體而有驅動性的

好的關鍵結果(Key Result)可以協助我們衡量達成目標的距離,然後進行快速的檢討和進行行為的修正(一般稱這個動作為復盤,game review 註3.)

.

0027_1.png

如何制定高效 OKR的 CRAFT法則

.

一個提前完成的Sprint,一個以OKR驅動提前完成的Sprint

如果我們能夠不用作完全部的需求就已經達到Sprint所設定的目標(商業價值)時,就叫它是一個「以OKR驅動提前完成的Sprint」,它因為已經達成目標了,所以就提前結束了(剩下來的需求,就由團隊一起討論是拋棄它呢?還是要把它繼續做完),Sprint 完成了,但不是團隊作完了所有的需求,試問這有什麼差別嗎?

這是成功Scrum團隊的一大步,它代表了Sprint是以商業目標驅動來決定Sprint 的開發週期的,它超越了1到4周的固定周期式的開發方式,而是視所要達成的目標來調整開發周期,團隊具有一種意識能夠判斷開發功能與商業價值之間關連性的能力,才能夠摒棄多出來的需求單。這是一種理想化達成的Sprint 衝刺目標。也就是不以作完所有需求為目標,而是以達成商業價值為依歸。

.

結語

在過去自己所帶領的團隊裡,PO經常想盡辦法與開發團隊進行溝通,就是希望工程師在開發時能夠以商業目的為主來進行產品新增功能的開發作業,但最後總是落到抱怨開發團隊只會埋頭苦幹,一點商業價值的觀念都沒有的地步。這一點;其實是不能責怪工程師的,因為將使用者故事拆分成一個個工作(Task)的過程,就是要簡化需求讓它成為單純的功能項目,只有如此工程師才能專注的來進行開發工作。因此要求工程師同時又能兼顧商業價值觀是一件二難的事,但有了OKR的目標導向規範,不但這個問題得以克服,更由於對 Key result 的設定,讓我們能夠用數量化來衡量目標的達成與否,也間接的得以評估團隊的狀態,真是一舉數得。

OKR 是一套明確可追踪目標及其完成情况的管理工具和方法,它易懂又簡單,但實施起來需要先弄清楚許多事情。那些事呢? 完全看你要在哪一種層級來運行OKR。如果把它運用在公司層級,則可能需要先弄清楚公司的使命、願景。如果運用在Sprint的衝刺上,則可能需要先弄清楚專案的目標、方向,前提是在一堆待完成的目標裡識別出現在最需要聚焦的一個,然後設定偏高的衡量標準,在激勵自己盡全力去達成它。最後補上OKR的定義如下: (此為Paul R. Niven和Ben Lamorte的版本)

.

0029

OKR 的定義說明

.

註1. 故事點的多少並不能做為團隊開發效能的依據.

因為故事點只是估算時的參考值,無法換算成絕對的數值,因此不能成為依據。

註2. MBO(Management by Objectives)來自管理學大師 彼得.杜拉克 Peter Drucker 在上世纪60年代即提出來的MBO的思想

註3. 復盤,game review

復盤是圍棋中的一種學習方法,指的是在下完一盤棋之后,要重新擺一遍,看看哪里下得好,哪里下得不好,對下得好和不好的,都要進行分析和推演。是一種極致的回顧方式。

 

補充資料

.

0001.png

簡潔、易懂的OKR,有著極高的敏捷性及聚焦性。

.

二個約束:

一、設定目標;充分授權於下屬,不要具体的說明如何去作到,讓他可以充分的去自我發揮。

二、運用關鍵結果作驗証目標是否達成了。以便於在過程中時時鼓勵、提醒與敦促努力的方向是否正確。

.

0002.png

.

0003.png

.

0005.png僅僅用在專案上,有人又稱之 MOKR( Mission OKR)

參考自《OKR:源於英特爾和谷歌的目標管理利器》,稍加了補充.

.

0009.png

一種超越敏捷的激勵力量(Google有團隊訂成0.75,就更有趣了)

.

0012.png

如果運用在公司層面上,訂定"使命“便成了第一步,應該多參考別人的使命.

.

0014.png

參考自《OKR工作法:谷歌、領英等頂級公司的高績效秘籍》的好方法

.

0030.png

曾經試過 .2、.4、.6、.8的五分法的打分數方法,但還是奇數看起來必較有味道。

.

0033.png

公司的使命不是為了想要賺錢,而是為何要創業的初衷。

.

0034.png

實行OKR,你需要建立一個高效的團隊

.

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s