Ruddy Lee 分享空間

Emergent Design 演化設計

Posts Tagged ‘看板

主管房間裡的看板

leave a comment »

.

主管看板

以決策為主的看板

.

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

  • 追蹤紀錄(涵蓋 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

.

 

廣告

Written by ruddyllee

2017 年 06 月 09 日 at 22:46:56

張貼於未分類

Tagged with , ,

看板之我思故我在

leave a comment »

.

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

.

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

.

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

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

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

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

 .

站立會議的四種提問模式

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

  •  激勵提問模式

  •  品質提問模式

  •  反思提問模式

  •  領導提問模式

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

激勵提問模式

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

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

品質提問模式

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

反思提問模式

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

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

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

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

 

領導提問模式

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

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

結論

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

.

scrum、Agile、Lean.png

.

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

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

.

註1. 有效的提問

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

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

 

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

註3. 引導反思 Processing

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

註4. 同化 Assimilation

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

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

.

Written by ruddyllee

2017 年 06 月 06 日 at 10:58:30

張貼於未分類

Tagged with , ,

引導看板 Facilitated Kanban

leave a comment »

前言

  • 已身.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每日工作看板需與真實的工作流程相符(僅供參考)

.

Written by ruddyllee

2017 年 02 月 20 日 at 22:33:03