為看板設定目標

.

【二種做法】

  1. 設定持續改善的依循目標  – 持續改善目標表。
  2. 為使用者故事或Task 設定要達成的目標  – OKR用戶故事卡。

.

以紙本的方式

OKR用戶故事卡(左側) 與 持續改善目標表(右下方)

.

如果你已經在使用看板了,那你對看板的三條約束一定不陌生,它們是劃出價值流、設定WIP及管理你的流程。你也一定知道,它的終極目標是能夠做到持續改善(Kaizen)。但在你實施一陣子之後,一定有過這種疑惑,我們經常改動看板但是到底是改對了還是改錯了呢? 這樣改變WIP的值到底產生了多大的影響,有效嗎?

.

持續改善就是持續去設定目標,在達成目標之前能有效的持續地進行調整。

– 持續改善目標表

.

有明確的目標才能持續改善

當你在做一件有意義的事時,你會設定目標嗎? 如果你沒有設定目標這個習慣的話,又怎麼知道目標是否已經達成了呢? 又方向對了嗎,還是漸行漸遠了?舉個例子: 出外旅遊時,我們經常興高采烈的設定要去的地方,然後走著走著,在進入陌生的巷弄時難免就會心生疑慮,懷疑自己是不是走錯了,這時候;有一個可以用來確定對錯的好方法,便是使用目視法;要能始終看到目標物在哪裡,維持一直能看得到目標,這樣不管是怎麼繞來繞去只要一直能看到目標,而且有持續接近的跡象,就可以安心了。這種作法其實是由於可以確定方向是對的,心理頭自然就不會害怕是否迷路了,旅遊的心情也就自然地平穩了下來。這是持續看到目標確定方向的好處。然後篤信只要朝著這個方向去前進,就一定能到達目標。 

上面的方法可行,但那是在你已經很接近目標物的時候。如果遇到距離較遠無法目視到目標的時候,我們可能就得先行規劃到達某一個特定目標之後再向主要目標前進,採用兩段式的方式去達成目標,這便有計劃的持續改善了,我們先設定好一個目標,在確定到達後,再朝向另一個目標去前進,自然能按計劃越來越接近目標了。 

.

為看板設定目標

看板上少了一個可視化的設定,就是設定一個持續可改善的目標。雖然你可以辯解說目標一直都存在讓流程更快更順暢上頭,但其實它少了視覺化,這一點讓我們不容易聚焦,少了聚焦時便少了經常被關注到的機率,也就自然地就降低了持續改善的機會了。所以我們應該為看板設定一個現在正在改善的目標,然後讓它一直可以被看到。

.

目標就是我們想做的事,關鍵結果是讓我們知道自己達成了沒有。

.

看板上的卡片

將用戶故事設計成包含於OKR關鍵結果相連接的清單上,便利我們在選取 Task 時,確認自己機將做的工作能夠與設定的目標相吻合,以及須要完成到何種程度。當發現有用戶故事找不到與目標對齊的歸宿時,就可以顯現出(可以拿來度量)團隊實際用在開發功能上的時間都花到哪裡去了。解決方法有二一、是把它轉為功能目標,在設定好關鍵結果。(懷疑是目標訂得不好,所以就為目標加上一支腳,待事後回顧時可以做檢討用)。二、便是刪除不做。這是考驗PO如何來目標設定,及顯示出團隊戰力都消耗到哪裡去了的好現象。

.看板上的OKR清單

看板上顯示OKR能關聯到用戶故事的清單(它放置在To do list前)

.

OKR用戶故事卡: 連結目標、關鍵結果與實際描述需求的用戶故事的卡片。

.

結語

在看板上實行OKR依目的可採用二種方法,一種是針對持續改善的目標設定方式,以設定「持續改善目標表」來讓團隊知道整個看板運作正在朝向哪個方向進行改善。另一種方式為創建用戶故事與OKR的關聯清單(稱為;OKR用戶故事卡,如果你只有Task 而沒有用戶故事的話,就叫它OKR工作卡)。

 

對於純粹使用看板方法的團隊,例如維運團隊而言,設定「持續改善目標表」會讓改善看板運行效率成為可以被看得到的成果,團隊容易形成共識進而加強了自組織性。而OKR工作卡則促成我們在做任何事之前先設定目標,由於預設完成後的關鍵結果,這一點可以激勵工程師表現得更好。對於運行Scrum的團隊,幫助就更大了,它可以讓綁定需求(用戶故事)與目標,讓開發需求時的預期目標能夠凸顯出來,更加專注於主要功能而減少去做與目標無關的工作,換句話說就是減少了浪費。

 

聚焦持續激勵

聚焦與持續激勵是成就OKR成效的依據。所以必須一直提醒自己,一直提醒團隊是否偏離了目標的路線。站立會議是看板實作OKR開始時,最重要的檢核時機,透過隨時更新關鍵結果的信心度,可以讓團隊持續聚焦在目標上頭,而透明出來的效果更能持續增強團隊對目標的專注度,因此看板在實行OKR時,確切又正向的站立會議將是一大成功要素,不能忽略。

.

目標管理法

目標管理法概述

.

註: 幾本實行OKR的參考書籍

  1. OKR工作法谷歌领英等顶级公司的高绩效秘籍

         寫得好極了,也有一些獨到的施行方法,值得閱讀。

  1. OKR:源於英特爾和谷歌的目標管理利器

        囉說了些,但如果你想多參考一些建議的話,還是好書。

  1. OKR资料全集

       明道互联网公司的免費佳作。https://www.mingdao.com/home

 

 

廣告

運用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,你需要建立一個高效的團隊

.