2017 Scrum Process Chart

.

.

【 新增 】

• 引導 Facilitation
• 二代精實 Lean  (Second Generation Lean Product Development)  by: Donald G. Reinertsen

• 系統思維 System Thinking

.

實行個人看板前該做的事

.

畫一張生命歷程圖，反思自己的過往。

–          如果我可以重活一次

.

A 先生的生命歷程圖示(起始點是大學畢業)

.

生命歷程圖

找一個具有意義的起始點，在時間(橫軸)的流程上，向上點一點是得意的高度，向下點是失意的程度，讓人生如意與失意的重大時刻顯現在時間的畫布上，目的是讓自己能夠回顧那些對自己重要的關鍵時刻，這叫做反思人生（註1. 引導反思)，目的是樹立自己的人生價值觀(請参考scrum的價值觀）。

.

在你邁向未來之前，先回顧一下過去，讓反思教你未來該如何走下去。

–     樹立個人的價值觀

.

/*

一張用五分鐘可以畫完的圖示，描述著你一生中對自己最重大的事件，或許喝著咖啡，或畫在餐巾紙上頭，思考一下、點一點、畫一下，卻對自己的人生有著無比重大的反思效益。

當你畫完生命歷程圖之後，記得挑一個最得意的時刻，設法一再複製他。挑一個最失意的時刻，想法子改正他。這就對了!

 

繪製「生命歷程圖」的步驟：

 

步驟一、先Listing那些有意義的事件，給它一個好名稱（好的命名可以減少我們重畫的次數）。

步驟二、開始把它們依照時間先後排序一下。

步驟三、依照它所給你的感受點在畫布上，越得意的點在越高的地方，越是失意的點在時間軸下方越低的地方，盡可能忠於自己的感受，不要去顧慮別人怎麼看它。要認清生活是自己要面對的。

步驟四、用藍筆把幾個得意的地方圈起來，圈得越多你會覺得人生越美好。用紅筆把失意的地方圈起來，可以想見，圈得越少，人生越好過。

步驟五、坐下來喝杯咖啡，想想自己的人生要怎麼過吧！

（其實施行個人看板時，你又會發現自己其實都是在為別人過生活的，但這是很正常的，無需訝異！這就是人生，我們會為自己在意的人及所愛的人而活，天經地義。）

*/

 

.

一個人的獲利模式

Business Model You (註2.) 是由 Tim Clark, Alexander & Yves Pigneur 所合寫的務實生涯規劃名著。書中用一張填寫的九宮格的表，來幫助你思考，找到工作的意義與方向。他的出發點正是典型的敏捷思維(Agile Thinking)。強調「環境在變，你也要跟著變」。

.

個人商業模式畫布Personal Business Model Canvas

.

這是實行個人看板前的絕佳分析圖示，正是所謂的畫一張屬於自己的商業模式圖，試著看清楚個人的利弊得失，再運用自己的價值觀規劃接下來該怎麼過日子，對自己是最有意義的。

.

它的標題是: 「填好這張圖，你就是自己人生的 CEO!」

.

《來吧！我們來填填看》

 

》個人商業模式圖要填寫的第一個欄位是「關鍵合作夥伴」，它所指的是「誰能幫你? 」是指你可以獲得那些專家、達人的協助。他們會協助你完成工作，給你建議或提供你完成工作的資源。他們可能是你的同事或導師甚至是家人。

》「你做哪些事」也就是關鍵活動。想想你在工作時經常要做的工作，這在看板上頭有清楚的記載，而它們的比例就可以反映出你花在工作上的時間的多寡。它實際上是跟著關鍵資源的，也就是下面的欄位。

》「關鍵資源」: 就是「你是誰及你擁有什麼?」這裡指的是你的興趣、才能或技能還有你的知識、經驗以及人脈，包含那些有形及無形的資源。

》「成本結構」: 指的是在生活中「你要付出什麼?」 也就是為了工作所付出的時間，或是為了家庭生活所購買的汽車或房子等等。

》「收入與好處」:「你會獲得什麼?」 包含薪資、獎金 或是福利等等，還有一些非實質性的東西，例如: 成就感、滿意度或是收稱讚等等。這是看板上經常看不到的東西。

》「價值主張」:「你如何幫助顧客?」這裡指的是你工作上的價值。或是能為他人所提供的有價值的服務。

》「顧客關係」:「你如何與顧客互動?」這裡所指的是你與顧客之間的互動方式，是面對面還是透過email或其他方式。

》「通路」: 指的是「別人是怎樣知道你的?」以及你透過何種方式提供服務。

》「目標客層」: 指的是「那些你要幫助的人」。包括公司(你的薪支來源)，及那些看不見酬勞的工作。

 

《填完後，可能長成這個樣子，是不是很像看板?!》

.

(取材自 http://www.tuzei8.com/business-model/index.html)

.

實行個人看板前該做的事

先知道自己要的是什麼? 先確立自己的價值觀，你想要什麼。回顧過往然後自我檢討是一種確立個人價值觀的重要步驟，反思在那些對我們很重要的人生轉戾點上頭自己是怎麼去應對的，想想是否可以再改善一下，或許人生就會有完全不同的風貌，也就是再給我一次機會，你會怎麼做呢!

 

許多想要改善自己的人士，嘗試了運用個人看板來改善自己的效能。但實行沒多久就放棄了。或許你會怪罪給恆心或是毅力不足的緣故，但實質上是「焦點」的問題，因為失去焦點而無法持續才是主因，因此在施行個人看板之前先弄清楚自己，試著填寫上面那張九宮格，弄清楚自己要的是什麼，然後就可以按部就班的紀錄下來自己的生活與工作事項，再回過頭來看著這些紀錄，自然能夠若有所悟。感謝下面這二本好書，好的作者與精采的翻譯，值得閱讀。

.

《一個人的獲利模式》 Business Model You

.

註1. 《引導反思》

參考自吳兆田先生的《引導反思:的第一本書》，學習如何學習，打通學習與改變的任督二脈。

註2. 《一個人的獲利模式》 Business Model You

作者: Tim Clark, Alexander & Yves Pigneur， 它能幫助你思考，找到工作的意義和方向。

註 3. 個人商業模式的範本 (Pdf檔，可以在這裡取得)

一張範本:

.

如何開始設限 WIP值

.

當你不知道工作流量的大小，就無從去設限WIP值，也就無法去改善流量。

.

運用工具記錄衝刺過程的產能，就能看到流量狀態

.

設定 WIP值就是要解決 Queue 的問題

.

.

 

附註:

1. 運用衡量來增加我們對開發產能WIP(work in Progress)設限值的概念

.

看板的系統思維

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

 

 

如何創建組織文化

 

讓我們退一步思考「如何克服不利於敏捷意識型態的公司文化？」其實實行「敏捷」並不能解決組織的所有問題，事實上，還會在組織內部造成許多問題，因為敏捷幾乎跟務實劃上等號，而這會讓組織暴露出它的缺陷，這就好像我們作人一樣，如果太「務實」了，結果就很容易造成許多傷害ㄧ般。（這種務實的方式一般就稱為太現實了）

一個成長中的組織，總是在面臨著各種困難與功能上的失調中持續爭扎著，只是我們身在其中反到沒有查覺罷了。但要讓組織能夠存活下來的要素卻十分簡單，那就是在快速善變的資訊、社會風潮之下持續學習新知、然後持續成長改變，而不是忽略改變。

引入敏捷

引入敏捷化並非萬靈丹，如果組織原本就作對了的事，就不要藉著敏捷化的名義去異動它，反之，能引入精實（lean)的理念來進化它才是上策，這是我們推行看板方法的初衷(讓lean 與 scrum 交互並行)。許多打算導入敏捷的組織，其實不是想要來一場革命，他們真正想要的是能夠走得更快(敏捷二字太容易讓人誤以為他是一種快速的開發方法)，或是想讓產品更早上市而已，又不需要犧牲任何東西，這是「客製化敏捷」的典型思維，他們並沒有打算接受改變的準備，所以我們常說推廣敏捷必需由上往下才會成功，因為主管的敏捷性決定並且主宰了組織是否持續推行敏捷化的工作(作顧問的最再意的則是如何才能協助組織學習與獨立)。

改善文化，從「溝通」的效能開始

由於要引入敏捷的新概念，有一種作法是對組織先進行全面的評估作業，目的是為了找出對敏捷的認知、知識能力、支持與反對、實作技能等方面的落差，這可以有效的評估導入敏捷的過程中可能會遇到的阻礙及讓作法更明確，然後擬定策略逐步的來縮小這種落差，這是一種有效的作法。但基本上，還是先改善最基礎的「溝通」問題吧！身為顧問，我會經常詢問高階主管當你下達一項命令時，底下最基層的員工要多久才能正確無誤的得知這個指令。試著計算一下；這便是你團隊的溝通效能了。首先要打通這個關鍵點，然後再在上面施力才能有事半功倍的效果。這個關鍵點就是系統思維（System Thinking)之下所謂的槓桿點。（先盡力去改善溝通的效能，作到了再去追求精實）

製造「提問的文化」

看板正是製造這種文化的最大利器，團隊需要有團隊的看板，或是開發Dev的看板或是維護Ops的看板（其實DevOps是不該分開來的，即便他們是二個團隊）,而主管則應該有屬於自己作決策時所倚仗的看板 (決策看板)，它可以用來發覺那些需要衡量俱有風險的項目，並要求進行衡量之後再協助下達決策。

看板讓許多我們本以為應該是這樣的事情變得透明化了，大家都看見了現實的工作進度及狀態，但那些看不見的事情呢？那些我們無法控制的等待或是依靠他人來完成的事情呢？(例如: 委外開發)請試著用提問來描繪它抽象化的外型或狀態。只要這項資訊值得我們去衡量來幫助決策時，就去進行衡量的工作，這會幫助你看見許多無形的事物。

當然的，我們自己就是公司文化的ㄧ部份。我們透過學習成長獲取經驗也累積了公司的無形資產，也就融入了公司的文化中。而要創造敏捷的文化當然應該用敏捷的方式來達成，這正是杜威(註 1.)所謂的經驗學習法則，它經由外來問題產生的「刺激」引發我們實際體驗、概念、觀察與行動的彼此交融辯證而產生ㄧ種統合整理的歷程，透過這種方式去驅動成員產生學習的動能，進而對經驗的「觀察」反思，產生特有的「認知」，爾後我們就能憑據這種學習後的認知來作「判斷」的依據，這便行成了所謂的智識，當然它依附在組織之下，而成為組織文化的ㄧ部份。

.

經驗主義就是依據迭代的方式做累積

.

這張圖示大家應該似成相識，杜威的經驗學習模式也正是敏捷所謂的迭代的方式。這一點也驗證了敏捷開發實際上是奠基在持續學習之上，且同樣是一種經驗主義下的產物。他的名言:「教育及改造」，這正是我打算用教育來改善組織文化這種想法的根源。而做法則是推行「提問型的文化」。

「提問」如何改變組織文化?

只是問問題為什麼能改善組織文化呢? 試想；當我們問別人問題、並請他們和我們一起找答案時，這時不僅僅是資訊的分享，也是責任的分擔。因此一個提問型的文化是一個分擔責任的文化。同時，當責任分擔後，大家就會交換意見、共同來解決問題(因為，問題已經不在是你的或我的了，而是我們的)團隊的互助文化也就油然而生了。提問真是好處多多，但是一樣需要練習，它也是經驗主義。(註 2.)

 

問對問題是成功領導的第一步。

.

小結

我的習慣做法會是先採用 “奧卡姆剃刀”法 Occam’s Razor (註 3)，也就是先找到組織的核心價值，然後集中發揮他應有的資源，接著進行簡化再簡化的動作。一般的做法是採用雙管齊下的方式，其一、首先是簡化流程，避免不必要的文書作業，建議引入 ITIL 的(Information Technical Infrastructure Library，是一套公開、並用於規範資訊技術服務管理的架構)辦公室自動化標準，目的是讓組織的行政效能提升（如果我們只用敏捷的角度去看一個企業的轉型，就容易忽略了組織在行政上的改善機會）。再來才是引入敏捷，也就是開始做教育訓練課程與輔導，讓開發及維護的效能提升。作法則是先以看板做開端，先接受現在的工作方式，讓「看見」的看板理論來觸發團隊主動自己改善的意願，接著才是逐步進入Scrum 的開發實務。而我以為必須要讓他們學會這一切才行(理想是這樣，但實際上只要組織開始進入學習的模式就成功了，經驗會讓他們自然的越變越好)，而我以為最好的作法就是讓領導者能學會提問的領導模式(過去我總以為 Scrum Master一定要學會提問的技巧，但實際上主管才是重點)，其實就是一種大家共同負責的模式，團隊也能開始真正為自己的工作負責，這就形成了一種自我管理的模式，則組織自然就會朝向敏捷化的方向在移動了。

.

 

註 1. 杜威 John Dewey，1859年10月20日－1952年6月1日

是美國哲學家和教育家，與皮爾士、詹姆士一起被認為是美國實用主義哲學的重要代表人物。杜威最重要的兩個教育思想：連續性以及實踐中學習（也就是: 從做中學習）

對杜威來說，創造充分的條件讓學習者去「經驗」是教育的關鍵：「所謂經驗，本來是一件『主動而又被動的』（active-passive）事情，本來不是『認識的』（cognitive）事情」，杜威「把經驗當作主體和對象、有機體和環境之間的相互作用。」他主張以這種進步的（progressive）教育方法使學習者從活動中學習，經驗本身就是指學習主體與被認識的客體間互動的過程。但他又說：「經驗的價值怎樣，全視我們能否知覺經驗所引出的關係，或前因後果的關聯。」並不是每一種經驗都是有教育的價值的，對經驗過程逐漸形成的主體的詮釋是關鍵所在。正因如此，杜威亦指出培養出學習者自習能力是教育的功用，他說：「教育功用的經驗的另一方面，即是能增加指揮後來經驗的能力。」他把這種能力的培養稱為「改造」，所以他說「教育即改造」。

.

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

.

註 3. 著名的 “奧卡姆剃刀”法 Occam’s Razor

他所主張的“思維經濟原則”，概括起來就是“如無必要，勿增實體。”因為他是英國奧卡姆人，人們就把這句話稱為“奧卡姆剃刀”。
他: William of Occam，約1285年至1349年，英格蘭的薩里郡，奧卡姆 是他出生的地方。
這把剃刀出鞘後，剃禿了幾百年間爭論不休的經院哲學和基督教神學，使科學、哲學從神學中分離出來，引發了歐洲的文藝復興和宗教改革。

事實上，我們的組織正不斷膨脹，制度越來越煩瑣，文件越來越多，但效率卻越來越低。這迫使我們使用“奧卡姆剃刀”，採用簡單管理，化繁為簡，將複雜的事物變簡單。

為什麼要將複雜變簡單呢？因為複雜容易使人迷失，只有簡單化後才利於人們理解和操作。隨著社會、經濟的發展，時間和精力成為人們的稀缺資源，管理者的時間更加有限，許多終日忙忙碌碌的管理者卻鮮有成效，究其原因正是缺乏簡單管理的思維和能力，分不清“重要的事”與“緊迫的事”，結果成為了低績效或失敗的管理者。從這個意義上講，管理之道就是簡化之道，簡化才意味著對事務真正的掌控。

 “奧卡姆剃刀”三法
1、精兵簡政，不斷簡化組織結構 。
2、關註組織的核心價值，始終將組織資源集中於自己的專長 。
3、簡化流程，避免不必要的文書作業。

.

主管房間裡的看板

.

以決策為主的看板

.

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

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

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

.

決策分析

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

 

決策!

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

.

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

–          查爾斯.凱特靈

.

衡量 (measure)

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

.

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

.

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

 .

「衡量的定義」:

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

.

 

槓桿點

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

.

打勾者為 Scrum 既有的關注點

.

小結

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

 

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

.

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

.

 

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

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

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

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

 

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

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

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

 

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

 

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

.

 

看板之我思故我在

.

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

.

參考自維基百科

.

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

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

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

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

 .

站立會議的四種提問模式

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

•  激勵提問模式

•  品質提問模式

•  反思提問模式

•  領導提問模式

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

● 激勵提問模式

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

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

● 品質提問模式

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

● 反思提問模式

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

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

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

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

 

● 領導提問模式

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

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

結論

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

.

.

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

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

.

註1. 有效的提問

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

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

 

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

註3. 引導反思 Processing

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

註4. 同化 Assimilation

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

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

.