為看板設定目標

.

【二種做法】

  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

 

 

廣告

站在看板前面,你該怎麼想?

0006

2018 DevOpsDays 上海,你扮演什麼角色?

.

無論你是剛好走過看板前面,還是刻意停下來打量它,應該做怎麼樣的思維才算精實、敏捷呢?

.

0007_00.png

.

先不要急著去看下面這個看板那些地方有問題,或是找有不符合看板規範的地方。應該先去感受它所輻射出來的重要資訊在哪裡?

.

看板前的思考.png

.

上面這個看板,很明顯的是中間的那個紅色圈圈裡的那張工作單,它是整塊板子第一吸引人的地方,也是團隊最想要被關注的地方,因此應該先關注它一下。

.

觀察看板第一件事,看到輻射資訊。

再來是 …

.

想要協助團隊改善嗎? 先考慮一下這麼做是否會干擾到團隊

無論你的意圖為何? 在看板前;首先要思考一下自己所扮演的角色,多說或多做的事,是否真能幫上什麼忙? 斟酌一下,或許你可以選擇把觀察到的意見寫下來,選擇用留下「建議」的方式,來協助團隊改善在看板上的資訊,也就是寫一張便利貼貼在醒目的地方留給團隊自行斟酌改進!(選擇沉默式的回饋,這樣可以在盡量不去打擾到團隊的運作下進行回饋)。還是選擇打擾一下負責這張看板的傢伙,用面對面溝通的方式來釐清這張看板讓你疑惑的地方(這麼做看似比較敏捷,但你所扮演的角色才是決定該不該這麼做的基本考量)。

.

不會有完美的看板的,它總是有需要改善的地方!

— 限制理論

.

如何持續改善呢?

嚴格說來;上面那張看板並沒有設定WIP(設定半成品數)值,板子上的欄位設計方式,有許多足以隱藏資訊的地方,確實是有改善的空間,但當我的角色是敏捷教練時,我應不應該把他(她)們集合起來,逮住機會即時的給團隊上一堂看板課程呢?

》不要著急! 先考慮一下;要怎麼做效果會比較好:   — 盡量延遲決策(註2)

  • 是由敏捷教練提出來作主動上課的方式,

  • 還是由團隊在意識到某方面的知識有所不足時,主動要求要上課的方式呢?

哪一種方式來的好呢! 同樣是教學,(註1. 團隊主動學習才是王道)選擇引發團隊的求知意識願意主動去追求改善可能是比較好的策略,這正是持續改善所應該要依序的方針。針對同樣的問題,運用引導的方式,往往會勝過直接處理的做法,來得好上許多。所以要設法讓團隊先產生求知的慾望,然後再順勢去推展才是王道。(給自己開一張單子吧,交給ScrumMaster 處理,或貼在自己的待辦事項裡,避免遺忘)

.

當你發現到看板可以改善的地方時,應該採取何種策略來進行改善呢?

.

給團隊一個小的目標

給團隊一個小小的目標讓團隊去達成,然後在達成後依循這個目標再加重一些,再制定下一個目標,再讓團隊達成,讓團隊一再的去克服它。這是一種比較容易引發團隊學習的作法,也能達到持續改善的效果。遇到比較成熟的團隊,可能會要求攻克較大的目標,就讓團隊自己去決定吧! 重要的是它促發了「持續改善」。而持續改善正是團隊最彌足珍惜的一種活動模式。一旦有一次成功的經驗,團隊就很容易會自然地進行複製,而產生成讓人驚訝效果!

.

衡量 vs. 度量

度量;這個詞聽起來就有工程上追求精準的味道,常讓人聯想的是小數點的取捨,該採用四捨五入呢?還是應該多加上幾位小數。英文都是 Measurement,但相對的;

衡量;聽起來就好像要寬鬆了許多,對一些比較不容易用數值描述的事物,必須用較抽象化的方式來陳述它時,「衡量一下」似乎就成了一個好的描述方式。千萬別用形容詞來描述它(註 3)

當你站在看板前面時,應該先問問自己你想知道什麼?

  • 是確切的工作進度呢,(那就去使用數位看板上所記錄的明確數據做依據,進行度量)。

  • 還是你只是想更清楚一下風險的大小?此時選擇衡量一下便是個好選擇。例如:設置紅綠燈的方式。

  • 還是只是順道逛過來隨便看一下而已。

如果是隨便看一下,就不要說什麼,趕緊離開,除非你看了以後產生了較明確的目的。否則盡量採取不干預團隊運行的理念,這是最好的原則。

.

我經常在看了團隊的看板之後,覺得可以提出許多的建議,或是覺得有許多可以改善的空間,但必須忍住不採取任何行動,要選擇相信團隊是正在朝著改進的路上前進,改善是需要時間去形成的,我們有心想幫助,但不該去干預團隊的運作,這種想法似乎有些消極,但一旦考慮到團隊的自主性時!主管就應該要選擇後退一步,盡量選擇潛移默化或事後引導的方式來進行改善,任意的干預是破壞團隊自組織的最大元兇。

.

可以從看板上獲得的訊息

燃盡圖最大的意義是讓團隊知道自己開發的歷程,至於完成的故事點數的多寡,就效能而言是沒有太大意義的。因為你可能只是對需求的點數估得太過寬鬆了而已。千萬不要為了團隊爆量的故事點完成率而獎勵團隊,那樣做的負面效果會遠勝過原來予以鼓勵的好意的。

看板可以讓我們看見一個使用者需求在開發、運維的流程上逐漸被實現的價值流。當然感受上不會像生產線一樣那麼的明確,也不會有像堆積木一般的踏實,可是在軟體開發上,流程中的即時狀態顯示應該是最具價值的,它能夠提供一個需求在開發中的透明性,它描述了即將發生的事件,若是正向的,則團隊會有一次成功的收穫,是負向的;則代表團隊即將面臨一次失敗的經驗,即便是失敗,也要讓他們一起去克服困難去完成任務,這樣才是培養出團隊自主性的方式。

也就是說;看板上最值得看的是工作單的即時訊息,就是工作的狀態,跟它所引發的討論。相對的,看板上最值得我們去修正的則是那些被隱藏了的訊息與它所可能引發的風險。

.

看板上最值得看的是工作單的即時訊息

.

衡量這二個字可以定義成增加或弄清楚對事物未知性的探索。或更具體一點: 就是「以數量表達的方式來降低不確定性」。例如:我們經常對無法控制的事項,改成用紅黃綠的方式來顯示狀態,就是一種衡量。

讓持續改善發生

設定WIP值的目的是為了從限制半成品數來做到持續改善。但往往會因為少了完整的說明敘述,而讓團隊成員忽略了這麼做真正的意義。

.

用文字敘述來描述目標,是使得看板溝通明確化的必要手段。

.

看板也會產生誤解

人們總以為我會這麼寫別人也一定會這麼想的,但實質上是預作了假設(自以為是),唯有經過確認才不至於產生誤解。在透明化的背後共識才是重點。當團隊的看板在有新成員加入時,確認新人對看板的認知是否與大家一致是入門課題。但其實也是考驗看板設計的好壞的時候,所以當有新人加入時正是重新設計看板的好時機。

.

目標: 如何實踐一種符合精實原則的看板運作

0008_1

.

結語

不過是看一眼看板,真的有必要這麼小題大作嗎?

在DevOps的時代裡,你經常需要捫心自問的是,我這樣做敏捷嗎? 是不是符合精實的精神呢? 身為團隊的一員,你可能是主管、PO、SM或是程式員,不論你的角色為何,要回答上面的問題,要讓團隊更敏捷都是你隨時隨地應該要關注的,它不是ScrumMaster 一個人的職務,是企業全員的責任。

.

看板前思考風險? 是應該干擾團隊嗎? 符合精實原則?

.

0007_1.png

情境示意圖: 用來回答我這樣做敏捷嗎? 是不是符合精實的精神呢?

.

 

註1.  主動學習的效果遠勝於被動學習

0009.png

註2. 精實七大原則

消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、崁入完整性、著眼全體。

.

註 3. 撰寫使用者故事的時候,最怕寫成「又快又好」這種形式,因為這種用形容詞來描述需求,會造成對目標的無法度量,較好的方式: 應該採用對比的說法,或直接給它下限值。例如: 最少每秒 10次。

主管房間裡的看板

.

主管看板

以決策為主的看板

.

分成二個部分來協助主管管理它底下的專案與團隊,第一部分是看見追蹤紀錄。第二部分則是用來協助主管進行決策分析的部分。

  • 追蹤紀錄(涵蓋 Dev開發 及Ops維護 的全面考量)

  • 決策分析 (運用逐漸成熟的大數據及人工智能所提供的範圍與機率等數據式的資訊,協助主管進行決策,包含: 衡量、槓桿點與決策三個欄位)

.

決策分析

曾經幫一些主管設計他們房間裡的看板,那個時候我心裡想的是戰情室的構想,因此詢問了主管想要得到的資訊是那些,就直接以滿足他的需求來做設計囉。但是這個主題一直困擾著我,到底主管房間裡的看板應該做到那些事呢?

 

決策!

現在想起來,應該以協助主管做各種決策為主來設計看板才是。甚至能夠提供預測的資訊就更有價值了。主管如何做決策呢? 通常是試透過「衡量」,依照觀察所得來的資訊去做決定。過去我們常常說:「如果不是自己所能控制的因素時就可以不放進看板裡」,但萬一碰到委外開發時,有需要掌握的事項時,則多半以紅、黃、綠燈的方式來表現在看板上頭(如果能更進一步運用較精確的數據來作依據,對決策的準確度就更有把握了)。其實;這個時候就可以交給位在主管辦公事裡的看板來做好風險的控管,由主管來監控並進行衡量後做成決策。

.

把一個問題敘說清楚,這個問題就已經解答了一半。

–          查爾斯.凱特靈

.

衡量 (measure)

把衡量放在主管進行決策分析的第一個動作,目的是要打破一般主管主觀的將許多事物看成是不可衡量的,因此做決策時的資訊就少於應該有的資訊,因而提高了錯誤的機會。其實萬事萬物都是可以衡量的(註1),而且大多時候你都無須大動干戈就能獲得足夠的資訊來進行決策分析。做衡量時,我們真正該弄清楚的不是一個明確的數值,而是藉由降低對事情的不確定性來增加做決策時的正確性。

.

若我們能夠衡量資訊本身的價值,便可以運用它來判定進行衡量的價值。其實因爲我們去衡量而誘發的價值,也十分值得關注,打員工績效的KPI就是ㄧ個最好的例子。因此在這個板子上的種種績效,都是員工視為追求表現的事跡。主管可以善用這種看板的透明化讓團隊持續處於積極進取的工作狀態。

.

這裡所謂的衡量是指向度量的範圍及機率,並非指向ㄧ個明確的數值,目的就是要你不必對不清楚的事情或事實去作猜測性的假設。而是用範圍與事情可能產生的機率來協助你作決策。例如: 蒙地卡羅模擬法(註3. Monte Carlo Simulation)目前已廣泛被運用在金融工程學,宏觀經濟學,生物醫學,計算物理學等地方,但在未來 AI人工智能大數據的強力推展下極可能成為風險分析的基礎運算範疇。

 .

衡量的定義」:

根據一項或多項觀察,以數量表達的方式來降低不確定性。

.

 

槓桿點

就是改變系統的關鍵點。這是系統思維(System Thinking)的基本理念,將看到的問題視為是系統結構的一種表徵,當我們想解決問題時必須擁有全盤性的考量,思考要如何才能將資源投入到解決問題的系統結構上。這裡所謂的槓桿點,指的就是在系統某處的一個關鍵點,當我們施加一個小的變化時,就能導致整個系統行為發生顯著而巨大的轉變(註2)。

.

幹桿點_1.png打勾者為 Scrum 既有的關注點

.

小結

我是基於二個理念來決定為主管看板加入「衡量」與「槓桿點」二個欄位的。第一點、是想協助主管降低下決策時的不確定性(先進行衡量,在做決策。千萬不要有先入為主的觀念,認為這件事是不可或不易測量的或太花時間)。第二點、則是系統思維,這是實行DevOps 三步法的第一步原則。應該以動態的系統思維來考量解題時應該關注的施力點,而不要以線性方式來作思考(例如: 二倍的工作量的需求,就可以以加入二個人力的方式來解決。但是,動腦的工作,絕不是 1+1=2 這麼簡單的,它是非線性的)。

 

主管房間裡的看板,跟團隊日常站立會議的看板有何差異呢? 其實主管也很需要回饋也需要與團隊溝通,因此這個看板是主管在下決策前用來與團隊進行討論的一個基礎看板(團隊中可能有Dev 的看板及以維護為主 Ops 的看板,但在 DevOps 的系統思維下,是不應該把開發及維護的看板區分開來的),它陳列的是我們追蹤到的紀錄,並敘述了主管衡量後的結果,其中包含了我們認為可以據以改善系統行為的關鍵點,也就是槓桿點。這個板子充分的展現了主管下達決策時的考量,跟足以支撐這些決策的關鍵因素。他讓(主管)一向神秘的決策變的公開而透明,是實行DevOps時的一大基礎。

.

(這裡不對追蹤紀錄的部分做說明,有疑問的話來聽我的演講吧!)

.

 

1. 萬事萬物都是可以衡量的

麻省理工學院指定教材,長踞亞馬遜網站商業類暢銷榜,一生受用的衡量技術!

商業、科學、生活上所有問題的解答
任何需要做分析、決策的人必讀之書

世界上沒有任何事物是不能被衡量的。
所有看似無法量化的難題,
只要能讓你知道得比以前多,就是一項成功的衡量。
本書對於降低決策風險、排除不確定性,大有幫助!

 

2. Thinking in System 系統思考 by 唐納拉.梅多斯

系統思考,是以整體、動態去思考問題的思維模式,
是複雜動態系統中「化繁為簡」的智慧。
提升系統思考的能力,才能克服思考盲點,
面對複雜性的挑戰,進而徹底解決問題。

工作,其實就是不斷地解決問題,然而,有些問題遲遲無法解決,或是即使換人改用不同的方法,也找不到好的對策因而疲於奔命。事實上,這是因為面臨「複雜性」的挑戰,牽涉到「系統性的問題」。

 

註 3. 蒙地卡羅模擬法(Monte Carlo Simulation)是一種基於大數法則的實證方法,當實驗的次數越多,它的平均值也就會越趨近於理論值。 蒙地卡羅模擬法最能涵蓋投資組合的各種風險因子,尤其是某些難以進行估算的非線性投資組合(如含有凸性的選擇權等),只要假設合理,此模擬能將分配精確的呈現出來。不要從這裡開始,除非你是ㄧ位經驗豐富的分析師,否則我會建議由常態分布曲線(normal distribution)開始。

 

作決策時,另一個很推薦的是 丹尼爾.卡納曼 的展望理論(英文:prospect theory),是一個行為經濟學的理論,為心理學教授丹尼爾·卡內曼和阿摩司·特沃斯基提出的。這個理論的假設之一是,每個人基於初始狀況(參考點位置)的不同,對風險會有不同的態度。它之於經濟學的貢獻就好像敏捷對專案開發一般,推翻了許多古老的假設,以務實化從朔了理論,並引起了巨大的改變(作者為此獲得 2002的諾貝爾經濟學獎)。公式如下:

IMG_1951

.

 

看板之我思故我在

.

敏捷開發;實質上都是在處理人的問題。

.

我思故我在參考自維基百科

.

我思故我在 I Think, Therefore I am.

敏捷開發;實質上都是在處理人的問題。因此我們不能不對行為科學有所了解。為了更了解人的行為模式,這就是為什麼專注在 Scrum 的人後來都跑去研究引導、精實或是系統思維(system thinking)的原因。其實行為科學就是心理學加上人類學的研究範疇,就是在研究人類的行爲,而如果我們弄不清楚工程師們爲什麼這麼做的因果關係的話,又如何來談改善呢?

》站立會議不是一般的例行會議,不是你報告完了就沒事了,它是提供你在這裡跟著大家一起學習、一起成長的地方。

但這裡想談得東西,其實是因為看到許多運用看板在執行站立會議的團隊成員們經常沒有把心給帶上。只是人站在團隊中,輪到我報告的時候就是交待一下工作的進度就了事了,少了團隊組合裡的責任與義務,也就是對團隊事務的參與。為了這一點,我經常在自己顧問的團隊裡給出會議的宗旨,例如: 專案開始之初,第一周的主題一般都是「專注」。(我用Scrum的價值觀來做站立會議的主旨,它們是: 專注、承諾、公開、尊重、勇氣)而我以專注做開始,實際上是為了在專案開始之初,要求成員盡速的把手頭原有的工作完成或交接清楚,如此才能專心在這個專案上頭。其實任何會議都應該有一個明確的宗旨,否則就容易讓來参加的人變得行屍走肉般的缺乏目標式的参與。

 .

站立會議的四種提問模式

在看板前運行站立會議不是一層不變的,怎麼問、問些什麼? 詢問問題的內容、形式跟得到的答案或效果也將大不相同,以下是我整理出來的四種模式:

  •  激勵提問模式

  •  品質提問模式

  •  反思提問模式

  •  領導提問模式

重點不是在選擇哪一種模式來進行,而是在是否能產生「有效的提問」(註1.),選擇使用那種模式只是用來弄清楚希望獲得的效果或是想要達成的目標是否達到了。因為站立會議的時間簡短,必須迅速的問到重點。因此提問的技巧及方式就非常重要了,他是經驗主義的產物,你必須透過經常性的練習才可能達到好的提問效果的。說明如下:

激勵提問模式

這一點幾乎是所有團隊行為裡必然會被問到的基本要素,共同激勵模式。我們可以從球場上每一節都有的簡短休息中看到教練在休息室裡頭運用慷慨激昂的喊話來激勵球員,團隊成員幾乎沒有個體回應的機會,問的問題也都運用封閉式(註2)的提問方式,團隊瞬間成了一個凝結起來的個體,一致的回答讓情緒快速的高漲了起來。當然在站立會議上我們不必要運用喊口號的方式來激勵士氣或提高大家的腎臟腺素,光是運用掌聲其實就夠了。

相對於激勵模式之下的是可以打擊團隊士氣的提問方式 – 打擊式的提問!當我們把問題重點放在「為什麼未能準時完成任務」、「是誰跟不上進度」。這類有歸罪責任傾向的問題時,常常會立即導致被詢問者打開自我反衛能力的保護傘,是站立會議時最應該避免的提問方式。

品質提問模式

由於軟體品質的好壞幾乎和整個開發的過程都息息相關,因此在站立會議的進行過程中被詢問到最多的問題,幾乎都是跟品質有關的提問: 「程式碼做過code review了嗎?」、「有作單元測試嗎?」但這樣問的效果常常不良,若能改變一種方式來提問(這類問題都是跟程式設計人員的基本素養有關的問題),以主動協助式的提問方式會比採用上面那二種被動式的提問要有用的多,例如: 「讓我來幫你做測試,如何?」、「有誰對這段程式碼有興趣的?」。若是能夠讓團隊整個動起來,則效果更好。具體上可以這麼做,將團隊分成數組,分別負責單元測試(單元測試小組)、負責code review(程式碼檢核小組),就能夠在有人異動工作單時,藉由負責的小組主動發問,主動要求協助。這種既具有提醒作用又有主動提出協助的方式將可以大量提升團隊的協作能力。

反思提問模式

試問要如何讓一個人改變他的決定? (尤其是那種固執的可以的人物,例如: 老闆。註2) 答案是: 「問他一個會讓他進入自我反思的問題」。藉由當事人自我的省思,是觸發一個人改變行為的最基本條件,至於他會做什麼樣子的選擇就另當別論了,這種引導的過程,有一個專有名稱叫做「引導反思」。

當遇到需要集思廣益來共同解題時的最佳提問方式。團隊會透過這種協作方式而變得更為團結、默契更上層樓,人們總是把一起學習一起成長的伴侶視成知己,合作起來效能當然就更好了。

提出讓團隊成員產生延伸思考的問題。例如:

  •    這種做法可以得到什麼效果呢?
  •    能不能舉個例子,或說得更清楚一些?
  •    有沒有可以二者兼顧的做法呢?

 

領導提問模式

傳統的領導方式是採用告知的方式。就是直接把重點告知下屬,讓他們照著做,用來避開在自我學習的過程中所可能產生的時間浪費及風險,但這麼做固然快又不出問題,可是這麼做卻會破壞團隊自我管理的機制,不但會限制了團隊發展的潛力,也會無形中讓團隊解決問題的能力下降。在這裡,我所謂的領導則是指向類似教練模式的指導方式,領導者不是以下指導棋的命令方式提問,而是以教練作指導鼓勵學習的方式來進行提問,讓團隊成員能夠透過討論或是集思廣益的方式來進行解題。你可以這麼提問:例如;

  • 這麼做固然可以解題,但大家想想看是否還有其他方法可行?  張三你來說說看 

結論

請把專案開發視為是一種創意的行為,而不是一種解決問題的手法。這是一種跳脫系統來回擺盪的方法。(註4. 請參考《最小阻力之路》這本書的副標題:以創造力修練取代「不斷解決問題」的人生結構革命。)這是系統思維的基本考量。如果你對Scrum、Agile、Lean以至於 System Thinking還有些許迷惑的話,請參考下面這一張圖示。

.

00

.

實在很難去界定什麼樣的提問是問了個好問題,但好的提問卻擁有一些共同的優點:(註4.)

.讓人專注並竭盡心力。
.創造深度的自省力。
.挑戰那些被視為理所當然的假設;它阻礙了人們用更新更有力的方式做事。
.激發勇氣和力量。
.引導突破性思考。
.掌控打開通往解決途徑之門的鑰匙。
.讓人對情況看得更清楚。
.讓人敞開心胸、思考得更透徹。
.考驗假設,讓大家思索為何他們會這麼做,還有為何他們會選擇採取行動。
.激發正面及強有力的行動。

.

註1. 有效的提問

提問難在哪裡? 我們經常在問問題時,太過專注於立刻想把問題給解決掉,經常不能等到被詢問者經過較完整的思考所作的回答,就急著想下結論了。因此就經常得不到好的回答,因此一個有效的提問必須要考慮到在正確的時機點提出正確的問題,並得到預期的效果。

參考自《你會問問題嗎?》 by Michael Marquardt

 

註2. 每當我想到這個問題就想到《Inception》全面啟動 這部電影,主角李奧納多 費了千辛萬苦,設計了一層又一層的夢境就為了改變繼承人的一個念頭(放棄父親既有的事業,重新建立自己的事業),如果把這個問題交給你來,你會怎麼做呢?

註3. 引導反思 Processing

五南出版社.吳兆田先生出的書引導反思的第一本書

註4. 同化 Assimilation

專案開發是一種創作的過程。依系統思維的方式來觀察人類創作的三個主要階段:分別是萌芽期、同化期及完成期。同化期則是我們在學習組合過程中,用來聚集能量以堅持到最後完成的必經過程。

參考自著名的《最小阻力之路》by Robert Fritz.

.

引導看板 Facilitated Kanban

前言

  • 已身.png孔子《論語·子路》,「以身作則」“其身正,不令而行;其身不正,雖令不從。”
  • 「潛移默化」,形容人的思想、性格或習慣受到影響, 不知不覺中起了變化。

.

引導 Facilitation
我教敏捷開發課程已經超過15個年頭了,這麼多年來我一直相信敏捷是一種文化,他可以深深的改變一個團隊,甚至是一個人的家庭文化,因此我很早就在家中實施敏捷教育了。為了讓孩子們也能像我一樣熱衷於追求學問,我總是以身作則;經常在餐桌上擺滿了書籍,表現得用功而認真的埋首於書寫或閱讀中,企圖用這種行為來感化孩子們,深深的希望這麼作能影響到孩子們的求學之路,有時候;我只要聽到孩子們下樓或要進到餐廳的聲音時,就會刻意的把書本打開來,裝作很用功的在研讀中,因此家中的餐桌上,總是長期的堆滿了各式各樣的書籍,嚴然就是一副圖書館的樣子,目的就為了形成孩子們愛讀書的風氣(真是用心良苦啊!)。

但這麼多年過去了(十幾年了,孩子們都超過30歲了),家中的餐桌上依然只有我的書籍,它們依然經常凌亂的躺在餐桌上,卻從來就沒見過孩子們這麼作過。所以我實在不相信以身作則就能夠有效的改變風氣。

05.png.

一直到我遇見了引導,才晃然大悟;其實,除了以身作則之外還需要依靠引導的方式,或許這才是循循善誘吧!(建議那些也想要運用以身作則,來感化孩子們的家長)你必需採用適當的引導方式,才能讓孩子們朝向你所期望的方向去前進。而在工作上我們也經常會碰到一些團隊表現的與你所期望的有相當差距的情形,這時候就是你該思考如何加強團隊引導的時機了。

這裡我嘗試了一種可以運用看板視覺化的力量來協助團隊協作的工具,我稱之為「引導看板」,效果好極了!每當你遇到要主持一些需要較多引導、較抽象的工作坊或會議時就可以自行先設計一個引導看板,讓與會人員一眼就知道今天的會議程序以及目前已有的成果,迅速移除那些讓参加者因爲不熟悉所造成的疑惑而造成的無為現象。它同時也能幫助你更有信心的去引導團隊並毫不遺漏的主持好會議,歡迎嘗試看看。

 .

運用看板來達成引導的目的 – 引導看板

.

引導看板」;一種用來持續顯示討論成果,以作為後續討論依據用的視覺性看板。

 . { 範例參考:  Scrum 四大會議的引導看板,放在文章後面。(其實;越是難以捉摸、越是高抽象度的會議越適合採用「引導看板」來召開,也能越見功效,例如:召開創建使用者故事地圖會議或可稱為Workshop 就屬於較高創意、十分抽象的會議類型,相當適合採用。目前只要是找我指導的會議,我一定會採用引導看板來進行,務必讓参與者迅速進入會議情境,充分的運用視覺化來完成會議紀錄。 )}

.

「引導看板」的目的是用來協助、組織召開複雜性高或曠日費時的會議或工作坊時所可以採用的一種視覺化看板。

.

看板天生就是作來引導用的

因為看板就是設計來顯示、管理工作流程的,因此十分適合拿來進行引導作業。而引導看板是紀錄成果,指引向未來的利器,它不同於一般的看板,一般看板在上面移動的是一個個的工作項目。但「引導看板」的目的是累積成果,持續讓大家一直看得到結論,並以此做為後續討論的依據,因此它顯示的是目前進行到的流程(欄位)以及已經累積下來的討論成果。如下面的創見使用者地圖的看板,紅色倒三角()一看便知是目前進行到的流程位置,也就是進行到第四個欄位(繪製示意圖),明顯的;示意圖不可能繪製在看板內,需要再運用其他的空間進一步產出(最後結果,則可以用照相的方式放上來)。但運用看板做引導的真正目的是消彌大家對程序上的疑慮,讓按部就班成為大家群策群力的依據,讓團隊智慧足以充分發揮。

.

下面是一個"創建使用者故事地圖"的步驟,它隱含"靜態頭腦風暴"的工作坊及會議(這是一個會讓你站到腳痠的會議)。首先;召開的步驟是:

20.png

21.png

.

召開的過程中,前面階段所得到的產出物都是為了用來做為接下來討論的依據。所以必須明確的紀錄在隨時可以看見的地方,以便於接下來的討論。所以十分適合採用看板來視覺化過程。你可以解讀下面的"創建使用者故事地圖看板"為:

  • 目前已經進行到: 第四個欄位,馬上要作畫出使用者操作的情境示意圖。
  • 第三個欄位: 明顯的標示了主要用戶與次要用戶的特性指標。
  • 第二個欄位: 標示了此專案對客戶及公司的利益所在。
  • 第一個欄位: 說明了參與討論者所扮演的角色。

.

14.png

.

所有程序一目了然,可以讓人增加穩定感並提升參與度

針對創建使用者故事地圖製作引導看板的目的,是由於「創建使用者故事地圖」是一種抽象度很高的活動,當召開時我們經常會邀請35名專家來參與這種啟發式的(頭腦風暴)討論。所以與會的人物經常是互不相識的(並且經常是第一次參加這種創意式會議),由於大家都不熟悉,這會讓會議的進行增加許多的不確定性,再加上對會議的成敗的疑惑,因此常常需要更多的暖身活動才能上軌道。所以我才決定運用這種可視化的技巧,讓與會者完全看到會議的步驟,藉以讓大家擁有較高的穩定性,用此拿來做頭腦風暴前提升穩定度的依據。

 

上圖中的看板,除了有明確的陳列出各個工作步驟之外,更把每個步驟的執行成果都記錄在該步驟的欄位中,讓參與會議的成員可以透過持續看見的效果,以此做為後續討論的明確依據,它可以讓會議不容易失焦,而且大家都能持續看到全貌,因此更能專注地去完成討論的目標。

.

devops看板_1.png

.

【 創建引導看板的步驟 】

一、繪製(會議程序的)價值流程圖 — 視覺化你的流程。

二、在最前面加入要達成的目標及說明 — 明確的說明所要達成的目標。

三、保留足夠空間做紀錄用 — 將紀錄用便利貼或其他方式陳列出來。

四、在看板的下方加上欄位說明 ,運用WIP來限制討論時間– 規範流程。

.

結論

製作用戶故事地圖的創建會議,實質上就是一種「設計思考」Design Thinking 的過程。成果是累加出來的,後面的討論往往是依據請面的線索所做的推論。這種形式的會議其實很多,若能夠善用可視化的呈現方式,則對創建的成果將會有著明顯的幫助。此時能夠採用引導看板來做呈現,除了可以大幅增加會議的明確度,又可以讓與會者迅速進入狀況外,還能適當的紀錄下所有的成果(明確的展示了創建使用者故事地圖的會議結論),具有圖像視覺化會議的成效。

.

{你其實可以更明確一點,之所以要保持抽象,目的是為了維持包容性,而再明確一點的目的,則是為了讓流程能夠順利地進行下去。}

— 運用看板進行引導

.

範例參考 】 – 展示會議、計畫會議、回顧會議。

Scrum 的 review meeting 的「引導看板」

明確的說明了即將有幾個展示、是由哪位成員所完成的,以及目前進行到哪裡。更有效的部分是,它可以讓來參與展示會議的使用者都能夠很清楚何時、何刻輪到他必須發表意見,應該要做較大還是較小的回饋,如此可以更順利的獲得客戶的回饋。

20

.

1.png

.

2

.

devops看板.png每日工作看板需與真實的工作流程相符(僅供參考)

.