Ruddy Lee 分享空間

主管；你很忙嗎?

2021 年 04 月 09 日2021 年 05 月 07 日 ruddyllee發表留言

想要加快團隊的開發速度，告訴你一個加快開發效率的秘密；就是把一個目標切成多個小目標；開發速度自然就會加快了。

-Ruddy Lee

沒有不忙的主管，就沒有不忙的工程師了

如果你問主管最近忙不忙? 八九不離十；一定會回答: 忙死了。接著問他，哪你有什麼方法來解除你的忙碌呢? 他可能會落入一段沉思。接著反過來問:那你的下屬忙嗎? 最可能的回答是: 他們也忙得一塌糊塗。哪你有什麼方法來解除他們的忙碌呢? 身為主管，這可是你的問題了，所謂的忙中有錯這意味著過於忙碌就容易犯錯，不要等出了大問題時再來亡羊補牢就來不及了。

解決忙碌；提升效率只是治標；治本之道則是適度的去完成真正的目標。

經理人要怎樣做才能不那麼忙呢?

答案是運用敏捷流程的核心觀念:「小增量、多迭代及尋求回饋」，做法則是對照到《一分鐘經理人》書裡頭的三個訣竅。如上圖所示三個訣竅的運用如下；先和下屬一起設定一分鐘目標(讓目標變小的好處是容易確認不會做偏了，也就是小增量、多迭代)，確保每個人知道自己該做什麼，以及好的工作表現的標準；之後你會努力發現他們作對了什麼事，好對他們進行一分鐘稱讚(激勵、鼓舞士氣)；最後，如果發現有人在工作上犯了錯，就對他們進行一分鐘更正(取得回饋後進行檢核、調適)。

一分鐘目標 Goals

因為一直在做適時的調整3個訣竅，所以目標走偏了的機會降低了，也自然的減少了返工的機會，因此設定一分鐘目標是提高工作效率的一條最基本的途徑。這一點與時下流行的目標和關鍵成果OKR 很類似，這樣做可以讓人們每天回顧自己的目標，對比自己的行為，產生自覺而自我修正的機會。將目標訂小了(也就是小增量)可以讓工作進度更透明更容易發現錯誤，別人也更好給予回饋，既容易達成共識也容易進行確認跟修正(不會做到最後才發現做錯了)。能夠協助工程師在開發過程中進行知識的累積，也能有助於程式品質的提升。應該要:

清楚闡明目標，取的共識。
明確好的工作表現標準，對OKR而言就是制定關鍵結果(Key Results)，還記得0.7原則嗎，好的關鍵指標本身就是一種激勵。
每個目標用一頁紙描述，遵守簡潔易懂的Simple原則。
經常性快速回顧目標，開始時要較頻繁的關注，當上軌道後就可以維持一定的關注頻率即可。
鼓勵人們審視自己的表現是否與目標一致，正是OKR的每日回報。
表現不一致就要敦促調整，千萬不要因為自己也不清楚答案就不置可否，應該鼓勵積極的去弄清楚它。
一直到達成目標為止。

一分鐘稱讚 Praising

有效訓練部屬最重要的關鍵的是，當發現他們基本上算是部分作對事的時候，就給予(作對的部分)適時的鼓勵，激勵他們因為做對了。我們都知道要在新人入職時給予關察、關懷一直到他能上手，但是其實人人都需要激勵，這是人們表現更好的動力。實施時；

稱讚正確行為。
即時稱讚並具體說明原因。
顯明的表達出你的喜悅，讓對方受到肯定。
沉默幾秒讓對方體會。
鼓勵繼續這種行為。

訴說這件事對在哪裡；比訴說這件事錯在哪裡要有效的多 -因為它能夠賦能。

一分鐘更正 Redirect

大多數經理人都喜歡把回饋(不滿)累積起來，也就是說，他們對下屬的錯誤行為不置可否，等累積到一起算總帳。這是很不好的習慣，但經理人卻總以為這是自己容忍的美德，要知道及時更正；在錯誤剛剛發生完後立刻進行更正才是最有收穫的時機。務必:

重新申明目標並達成一致共識。
確認既有事實。
分析錯在哪裡。
表達你對這個錯誤的感受。
沉默幾秒讓對方審視錯誤。
告訴對方你的實力其實比這個強多了，你很有信心。
更正完畢整件事就過去了，千萬不要去累積他人的過失，反過來應該立即告知即刻更正才是良好的回饋。

小結

想要加快團隊的開發速度，告訴你一個加快開發效率的秘密；就是把一個目標切成多個小目標；開發速度自然就會加快了。 這個方法是我多年來到處作顧問不變的手法，它始終有效，請試著問你的團隊；為什麼? 讓他們自己去思考、討論為什麼。它讓共識變得自然而簡單，而簡單造就了效能。

(新)一分鐘經理人的三個訣竅，道理很簡單；實施起來其實也一點不困難。步驟如下: 首先；在專案開始之初要讓團隊看見全貌(影響地圖與使用者故事地圖就在做這就事)。團隊在知道全貌時才能意會到自己在哪裡? 也容易認知到自己缺少那些知識或技能才能夠完成任務。接著；就要善用小增量的觀念，將目標分成多個小目標(一分鐘目標；書裏頭運用 80/20原則來說服大家只要對重要的 20%做目標設定就可以了；無需另外設訂剩下的80%，可以將它們視為次要目標。這個觀點大家都很熟悉，但實施起來卻仍是100/100，所有的需求都一樣的重要。這裡換成敏捷的制定小增量原則，就務實多了)，請謹記敏捷的小增量制定原則，也就是必須是「潛在可交付的目標增量」，它可以很容易收到利益相關者的回饋(避免做到最後才發現做偏了)。每個小增量盡量設計成對正到一個或數個開發的衝刺(Sprint)週期，並讓每個衝刺都是團隊驗證成功或失敗的時機點，成功或部分達成就應該對做對了的地方予以稱讚(一分鐘稱讚)，失敗的地方取得更正的正向回饋，並進行更正(一分鐘更正)。

新一分經理人溶入Agile

敏捷運用小增量、多迭代的方式，將大目標切割成小增量以多做幾次的方式來逐步完成目標。目的是讓開發者漸進的累積對產品的開發知識，同時間運用對需求增量的設計，也就是以「潛在可交付的小增量」，來獲取使用者的經驗回饋，用這種方式來修正產品對使用者的好用性，也就是增加價值。這與一分鐘目標正好不謀而合，而80/20法則也正好讓我們能夠聚焦在較重要的功能上，而不是對所有的開發功能都一視同仁，它能夠將開發的努力聚焦在最有價值的地方。

敏捷團隊的效能多半來自在開發過程中的激勵效應。這正是一分鐘稱讚發揮效力的時候，敏捷團隊在每日的站立會議時常常有許多掌聲或笑聲正是一種團隊的激勵效應，但一分鐘稱讚更重要的一個目標則是引導，因為稱讚正確的行為往往能夠引發更多的仿效，能夠帶來更多正面的效應。

回饋 feedback, 對經理人而言是改正下屬行為或工作失誤的最好時機，能夠即時且確實做到才能獲取最佳效果。一分鐘更正則是經理人進行衡量之後正確回饋的時機點，相對的敏捷流程則是在檢核(Review)會議時針對產品開發的增量尋求回饋；讓團隊在衝刺完成一個或多個Sprint增量時可以有機會聽聽客戶的反應，藉以調整自己的設計。接著在回顧會議(retrospective)時透過團隊自己檢討的方式來改善缺失。這是一種團隊自我管理的表現。經理人則應視團隊或個人的情境予以協助(請參考情境領導理論)。

運用80/20法則 設定一分鐘目標

「你獲得重要成功的80%都來自於你20%的目標，所以我們只對那20%設定一分鐘目標。」

一分鐘經理人具體實施方法

抱歉我把三分鐘變成五分鐘了。一分鐘經理人原本是三個訣竅，也就是設定一分鐘目標然後看是成功或失敗再去進行一分鐘稱讚或是做一分鐘更正。總計起來就是2 ~ 3分鐘。但在我實際實施時卻發現目標往往需要有衡量標準，而且最好是在設定目標時就與對方約好結果的評量標準，而這不就是 OKR了嗎? 因此；就把 OKR 的關鍵指標(Key Results)加了進來。但是在實施過程中，經常可以感覺到新經理人的不安情緒。為此；又把透明(可以看見問題)的手法加了進來，那就是運行看板背後的理論基礎，就是限制理論(TOC)，讓經理人經常的去思考，目前系統最大的限制是什麼；然後就可以把目標修正到這個約束的方向上。因此有了下圖的實施方法。具體說明是: 以敏捷為基礎；也就是「 小增量、多迭代與尋求回饋 」來設定目標。接著是運用 OKR的觀念；在設定目標時就把激勵效果加了進來，那就是設定「 0.3 正常工作/0.5 用心工作/ 0.7表現優異 」 的關鍵指標。最後是運用限制理論來持續「 思考目前系統運作的最大限制是什麼? 」也就讓系統能夠持續改善，也能避開落入局部優化的陷阱。

若是主管想藉由持續的增加工作壓力來讓部屬成長，這是完全錯誤的觀念，因為潛能是藉由激發所產生出來的，增加工時的產能只會增加負荷換來倦怠，成效適得其反。

潛能就是能耐，要靠士氣去激發他而非壓力，

否則當壓力消失後 …

註 1.《一分鐘經理人》為 1982年為肯．布蘭查與史賓賽．強森所合著。

《新一分鐘經理人》則於 2015 年誕生。小小的一本書，卻解答了經理人過於忙碌的處理原則。實施時只要對正到敏捷流程，效果即能自然浮現。(新版將第三個訣竅由One Minute Reprimands 改成 One Minute Re-Direct，也就是將批評改成了更正)。

註 2. 80/20法則 ；又稱為柏拉圖法則 (Pareto principle)、關鍵少數法則、八二法則；它指出，約僅有20%的變因操縱著80%的局面。也就是說：「所有變數中，最重要的僅有20%，雖然剩餘的80%占了多數，控制的範圍卻遠低於「關鍵的少數」。此原則在現今企業管理中廣泛被運用。例如:「80％的銷售額來自20％的客戶」。理察·科赫 Richard Koch 撰寫了一本「80/20」原則，展示了柏拉圖原則在企業管理和生活中的實際應用。

註 3. 溶入OKR的運用，請參考:

如果你的團隊已經在運用OKR了，便可以輕鬆的運用關鍵結果Key Results來判斷針對目標的達成是成功或是失敗，然後再決定該進行一分鐘稱讚或是進行一分鐘更正，唯一要注意的是回饋必須是即時的才會產生最好的效果。(經常有團隊在施行OKR時，覺得更忙、更沒時間做工作時，那便是沒能將80/20理論融入OKR的制定中，而那是實施OKR的基本思維，也就是你80%的成就，其實是來自你 20%的努力)。

註 4. 80/20 法則，推薦《80/20法則：商場獲利與生活如意的槓桿原理》by Richard Koch，這本書的宗旨就是要幫助你不要那麼忙! 但如果你還是那個凡事都要做到 100/100(50/50是一種認為凡事有因必有果的線性思維方式，他把事件的聯繫看單純了。而100/100的思維則是一種更荒唐的思維，他想要把所有可能的因素都做進產品的錯誤思維者，是一種天生的勞碌命者，也連累到他的周邊人員)，然後又沒有時間磨刀的砍柴工的話，那便是一本放在沒時間看書的人士桌上的絕世武功祕笈，它會一點效用也沒有的。

IT主管的敏捷情境領導

2021 年 03 月 30 日2021 年 04 月 20 日 ruddyllee發表留言

Paul Hersey 於1969年所創，為領導者加入了環境因素

情境領導理論強調環境因素對領導效能具有絕對的影響。採用時勢造英雄的觀點，且組織的結構、氣氛、角色特徵及部屬特質，均是影響領導的情境因素。

-Paul Hersey

• 針對位於 S1 較低成熟度的人，稱為「教導」: Telling

領導者必須指出何地、何時和怎樣做。但不宜表現出過多的關懷，否則就可能被認為你是一個含糊、隨便支持後進的人，反而會不力於指導。

• 針對位於 S2 中等成熟度的人，稱為「推銷」: Selling

領導者仍需進行指導和指引，通過解釋原因澄清事實。要讓追隨者買帳才是。

• 針對位於 S3 中等較高成熟度的人，稱為「參與」: Participating

領導者和追隨者相互指引和指導，領導者的主要作用是促進和鼓勵追隨者們關心和參與。

• 針對位於 S4 較高成熟度的人，稱為「授權」: Clelegating 因為領導者把決策和執行的責任授予了追隨者，只需在任務外圍進行觀察即可。

主管；請後退一步

實施敏捷化時，主管最常聽見敏捷教練說的一句話:「請後退一步，讓團隊自己做決定」。目的是養成團隊自組織的習慣。為了讓團隊習慣自己管理自己的原因，敏捷教練只好站在團隊與主管之間，冒著被責難的危險勇敢地請主管後退一步，讓團隊自己處理他們自己的問題。一開始有很多主管都不能適應，尤其是一些現場經驗十分豐富的主管，越是難以適應。就像父母親對待孩子一樣，我們總是擔心他們因為犯錯而受到苦難，而忘了當年自己也是這樣成長過來的，孩子們總是在犯錯後學得最多，這種因為錯誤後的體悟，越是深刻對他人生的幫助就越大。對團隊也是如此，正如DevOps三步工作法的第三步所言: 在過程中持續學習與實驗原則。所謂的實驗原則指的就是 fail fast, fail safe的原則。(失敗；這是老闆們最害怕的東西，所以敏捷教練經常將失敗設計成 fail early，這就是為何有 Sprint 0的故事，它是拿來快速失敗用的，目的是讓團隊越早受到挫折，重新再起來的力道就會越大，也越能體會到敏捷的真諦。是融合團隊最有效的方式，也是讓一群人士有過共患難的難得經驗後，能夠順利團結合作建立互信的重要原因)

上面那張情境領導的圖示，最棒的地方是讓領導者「從關注領導者本身，轉向關注領導者環境」。考慮的環境因素是「情境特質 = 能力 + 意願」它說明了身為主管者，何時應該前進一步，何時又應該後退一步。

下面針對四種可能的情境質加以進一步的說明:

當工作能力低；工作意願高的時候(右下角象限: S1)

主管請前進一步，直接告知應該怎麼做，幫他做決定。一般發生在升任新職務的人士，屬於熱心新手的階段，有意願把工作做好但卻缺乏經驗，這個時候他的主管應該以告知型領導的方式來協助他，也就是指導多、支持少的情境運用。原則是；告知、引導、指示及建置。

當工作能力低；工作意願不高的時候 (右上角象限: S2)

主管也請前進一步，以推銷的方式跟他解釋應該怎麼做，說服他做決定。一般發生在對新任職務尚未完全勝任的養成期時段，這個時候主管應該以銷售型領導的方式來協助他，也就是指導多、支持多的情境運用。原則是；推銷、解釋、澄清及說服。這個階段往往是離職率最高的時期，他需要更多的關懷，多讚揚並做回饋可以提升效果。

當工作能力高；工作意願低的時候 (左上角象限: S3)

主管請後退一步，並以參與者或支持者的方式來跟他討論，但要把決定交給他，也就是讓他當責。一般發生在對職務已經十分熟悉的老手身上，這個時候主管應該以參與型領導的方式來協助他避免他養成逃避責任的惡習，也就是指導少、支持多的情境運用。原則是；參與、激勵、合作及承諾。這個時候就能看出主管平時能否以身作則的原則了。關懷時多做鼓勵是必須的行為。

當工作能力高；工作意願也高的時候 (左下角象限: S4)

主管也請後退一步，並以完全授權的方式交由他去進行，這個時候主管應該以授權型領導的方式來協助他，也就是指導少、支持少的情境運用，讓他養成獨立自主的習慣。原則是；授權、觀察、注視及履行。此時最適宜的協助是衍架式的教練方式(參考: 主管不能不懂的-鷹架理論)。並以追求最佳化為目標。

※ 中間那條貫穿四個象限的曲線；稱為「領導行為曲線 」。Hersey 的解釋是你可以由成熟連續統一體( 統一體；指的是上面圖形中由四個不同顏色所組成的正方形框架)上的一點，然後從哪一點向表示領導行為的曲線連一條垂直線，在曲線上所產生的焦點，這一點就表示特定情況下最合適的任務行為和關係行為。

小結

主管；你是否還記得敏捷教練或 Scrum Master 請你後退一步的情境呢? 有時我們甚至會懷疑，如果我一直後退，當團隊出事的時候我要怎麼來協助他們呢? 其實在上面那些情境，有時你應該前進一步，但有時你又應該後退一步，依情境作判斷才是王道。情境領導理論的基本概念，包括領導的效能、領導的型態及被領導者的發展層次三個面向，其重要論點為：如欲發揮領導的效能，必須識別個體或組織的不同發展層次，運用不同的領導型態或採取不同的領導策略，惟其如此，始能達成領導目標，完成組織任務。

名詞解釋

• 準備度 = 工作成熟度(技能和專業知識)和心理成熟度(部屬的自信與自尊)。

Hersey 參考了馬斯洛 Maslow 的需求層次論與 Argyris「成熟-不成熟理論」的觀點而形成情境領導理論中的部屬準備度(Readiness，也就是所謂的情境特質 )的概念。(Ready, R1~4請對照到上圖中的 Situation, S1~S4)

高準備度	中高準備度	中低準備度	低準備度
R4	R3	R2	R1
有能力和有意願或信心	有能力但無意願或缺乏安全感	無能力但有意願或信心	無能力和無意願或缺乏安全感

• 情境特質= 能力 + 意願 = 部屬的準備度 (Follower Readiness).

註 1. 請境領導與情境領導II

情境領導 (Situational Leadership) 是由 Paul Hersey 與他的研究生 Kenneth H. Blanchard 所共同開發出來的。著作是《組織行為管理》Management of Organizational Behavior (9th Edition) 之後 Kenneth 又進一步注入個人的情境展模式就成了 情境領導II ，將 R1 改成 D1， R: Readiness 為準備度， D: Developer 程度(仍是依據個人能力與意願，這一點未曾改變)，在第一象限上(右下角) 便有了不同的說明。但一般都採用混和的版本，原本乃針對團隊，但在針對個人時採用 情境領導II 的說法就比較合適了。上面我自己畫的那張圖示，亦為混合版。至於個人發展歷程補充如下:

敏捷的專案排程 –目標驅動開發

2021 年 03 月 10 日2021 年 03 月 30 日 ruddyllee發表留言

還記得暑假作業嗎? 應該什麼時候做呢? 是一開始還是最後一周再做呢? 帕金森說因為有日期的限制，所以你會把時間都拖完，直到最後不得不做時才想到該去做了，這是人類的本性。因此專案排程絕對不要以日期為排程的依歸，應該以有意義的增量做目標，團隊為了達成目標而努力，如此專案才有機會提前完成，並因為團隊表現良好而獲得足以激勵他們的獎勵。例如:月餅趕工，八月十五日不是目標，中秋節才是。

不可或缺的專案排程

專案排程使專案進度一目瞭然、可以提升工作效率，可以增加規劃管理的彈性操作。讓協作團隊或維運人員可以順利啟動超前布署或各種支援行動。讓團隊的工作流程得以透明化，對專案開發而言是不可缺少的工作物件。所以在專案成立之初一定會被要求相關的時間排程。但是當你的第一個排程版本曝光之後，接著而來的便是無止境的調整作業，似乎大家都有意見。這是一種正常的情形，試想；你要與公司的戰略相配合又要聽聽各個協作單位的意見，所以改來改去實屬正常，但講得好聽一點是隨著大家開會所給的建議及溝通後的成果，會讓專案的時程規劃變得越來越踏實了而不只是你一個人在規劃，專案排程是團隊協作下的產物，而你只是負責專案方向的舵手。

目標驅動開發

敏捷的專案怎麼做排程呢? 敏捷不是強調估算是不準確的、僅供參考的嗎? 那還需要做排程嗎? 又；當遇到主管要求排程時該怎麼辦呢? 老實說；專案的時程規劃是絕對有必要的。即便它只是躺在你個人的行事曆裡，做為你的To-do List。但要知道，只有自己在看而沒有任何回饋的專案時程規劃是很不好的，少了協調回饋，這種專案排程就真的沒必要了。在敏捷開發之下，專案的時程規劃依然是必要的，只是請把日期移到目標的下方並盡量概略化(例如: 4月1號則改成 4月初，因為估算僅供參考)。也就是要幫開發的排程制定各種目標(每個有意義的小增量，都應該設定增量目標)，而專案開發的過程則以完成目標為主而不是去吻合開發的時間日期。這便是敏捷開發周期稱為 Sprint衝刺的原因，團隊為達成目標而努力衝刺，所以衝刺一定要有目標而日期不是一種目標，有意義的功能才是。

概略化階段日期，改以有意義的增量為目標。

-目標導向排程

制定目標讓我們的工作有了向心力，團隊知道這個Sprint是為何而做的，也才有了提前達成的機會，團隊潛能也才有發揮的機會。那種成就感或因為表現優異而受到讚賞的作用是不可言喻的。這與 OKR的鼓舞作用是相仿的。若在時間上是允許的話就再加上OKR的關鍵結果評比就更見激勵的效果了 (給分依據：很難幾乎不可能達成的給1分，必須很努力才能達成的給 0.7，稍稍努力就能作到的給0.5，循正常工作就能達到的給0.3，而完全沒作到的就給0分)。這種團隊表現的考核才是有意義的績效評比。

小結

雖然我拿暑假作業來提醒你，但下一次討論排程的時候，我相信你還是會用時間做限制而忘了目標才是重點。但暑假作業則始終還是暑假作業。

為了敏捷化；我應該放棄傳統的專案排程嗎?當然不是，你只需要把以時間作為標的的方式改成以目標驅動就可以了，還有時間是僅供參考的請概略化。說明一下上面那張圖示；第一行是二階段的專案排程，我們在達成階段目標的過程將它分成多個小增量，並針對有意義的增量將它設為目標，在會議討論時以達成此目標為依歸，而不是完成的時間為標的。這一點正是敏捷口訣中所謂的小增量、多迭代開發設計。也就是運用增量的方式讓團隊能夠發揮在開發作業中所習得的知識，將累積而來的知識運用在後續的開發上頭，因為逐步完成目標會比一次做到位穫得的更多(註1)。第二行是以增量作為目標，用作簡報或討論的主題，然後將習慣陳列的日期時間移到第三行並概略化完成階段的時間(但小增量的目標時間可以不變，這麼做的目的是拿來做為風險衡量的參考指標)，第四行則對工作內容加以說明。

專案排程千萬不要以日期為依歸，固然用日期來控管風險或資源會容易得多，但卻因此讓開發團隊失去了有意義的目標，也失去了可以提前完成的機會，失去了Sprint衝次的動能，自然也沒有了讓團隊有發揮潛能的機會，真是損失慘重啊。如果日期真的那麼重要，那就找出它的意義來，運用有意義的目標來取代它。若是你擔心專案會因此而延期或是造成答應客戶的承諾會跳票，那就積極的鼓舞你的團隊讓專案提前完成吧!

註1. 逐步完成目標比一次到位收穫更多

學習到的知識或技巧往往需要時間去消化它。分成幾次做完這個歷程也會在我們的記憶中留下更多的印象，拿寒暑假作業為例子，若能夠親子一起共同去完成作業學習的旅程，會讓寒暑假變得更具有意義也更為充實(當然是孩子學會了在自己去做，而你只是陪著他一起學習)。一次就想到位的想法，源自於現代人過於忙碌而致力於追求效率的結果。也往往希望一次就能完成所有的工作想法，損失了在過程中因為小增量讓你可以獲得回饋做得更好的機會。要知道回饋的價值，甚至能讓你有機會避開極可能因為犯錯而大量損失的時間及精力。

註2. 讓小增量形成目標

拿寒暑假作業為例；寒暑假作業通常被設定為，為下一個即將來的學期的內容鋪好基礎的前置學習，因此常常有數個明確的目標可循。我們可以善用這幾個目標，讓它形成小的增量，家長與孩子針對這些目標，排定一下學習的順序，讓寒暑假的生活在這幾個小的目標下逐漸的展開來，讓整個寒暑假作業變成在生活中多次迭代下的學習目標，一個一個在與家人一同學習下度過並逐步的完成。孩子若提前達成了目標就給予獎勵，延後了則表示這方面需要去加強，然後在增量即將完成之際才開始去做作業，這時候；孩子有了基礎的概念後在去做相關的作業時自然更為熟練，而學到的東西也會更多。

讓 To-do List 變敏捷起來

2021 年 03 月 05 日2021 年 03 月 05 日 ruddyllee發表留言

不是要全部做完

To-do List它不是工作備忘清單，不須要全部做完，而是要讓我們清楚下一步該做什麼，讓事情安排得更合宜。生活不是要把想做的事情通通都完成，而是要過得有意義。所以To-do List需要不斷更新、需要持續排序而不是通通做完。即便你把它當作備忘清單，也千萬不要把子項目全部做完。正如史蒂芬·柯維（Stephen Covey）所說的「真正有效的工作方法，是區分事情的輕重緩急，先做重要的事。」反過來說就是要篩選事情的重要性，只做那些值得去做的事。但是這句話講得容易，做起來卻很難。敏捷的思維在這裡可以幫上忙，請謹記敏捷的口訣:

小增量、多迭代與尋求回饋。

-敏捷精神

【口訣小解】

做任何事之前先思考它的小增量是什麼? 應該分成幾步來完成它才能讓我在學到如何把它做好之際還有機會在下一個迭代可以把缺憾修正過來，將事情做得更好。當然了；如果可以得到當事人的回饋，就更棒了。

該做什麼?

不是「下一步要做什麼? 」而是「下一步行動該做什麼?」。因為時間總是不夠用的。To-do List 列了一堆該做或想做的事，要挑重要的事做而不是緊急但不那麼重要的事去做。所以在每做完一件事後，首先該做的事便是判斷接下來該做哪一件事? 這一點可以參考單核工作的循環方式(註1)。

只有專注才會有高效

尤其是知識工作者，更須要延長自己專注的時間，專注是讓我們不輕易犯錯的根本。一定要減少被中斷，不要以已經習慣被中斷做藉口，因為越多的中斷只會破壞你的專注力，讓它變得越來越短。培養專注能力的一種好的做法是製造一個不會被輕易干擾的環境。其實由其他人所給你的中斷應該算是少數，真正大量的干擾反而是來自你的手機、社交媒體，哪些不可預知的事件。所以在需要專注工作的時候，首先要隔離電子干擾，再來才是來自外部人員的干擾。

不只專注(Focus)要全神貫注(Concentrate)。如果你試過《蕃切工作法》或是其他協助你提升效能的工作法。還記得第一次使用它時的感受嗎? 感覺很累；特別累對不對。是的；如果你經常工作在十分專注之下，那是一種很容易讓人疲倦的工作形式，但換來的是工作的高效能。這說明了注意力是有價值的你必須在精神上付出的更多。因為有許多錯誤的產生都源於我們注意力的不夠集中，尤其是工程師在撰寫程式的時候。因此我比較喜歡用全神貫注。想要提升效能，第一件事就是必須在工做時能集中精神，心無旁鶩。

小結

To-do List 就是看板的第一個欄位，在工作上；我們與團隊將開發流程運行在團隊的看板上，大家協同合作處處追求效能。感覺上就像在跑接力賽跑一樣，但是一棒接一棒的速度，絕對不會是個人個別成績的速度總和。而減少的時間則來自團隊的協同合作上頭。相比之下在生活上，運行的個人看板就要複雜得多了。原因是生活的 To-do List ，那些想做與必須做的事，種類太多了差異性也太大了。所以要怎麼樣才能更高效率呢? 答案就是能夠將工作項目安排得當。上圖中的第一個欄位裡，放了綠色的健康事項，灰色的公事還有藍色的事業項目及紅色的老婆交代的事情它們由上往下依重要順序排列。簡單陳述一下這個看板:

待辦事項: 包含了個人健康、興趣、家庭事務及公司工作。
5件事清單則可以在全景模式時進行填補、判斷。
檢核欄位: 提供自我檢查，
另外次欄位提供等待的暫存區，因為真實世界等待是難以避免的。
最後的完成區，提供夜晚上床睡覺前的回顧動作，並藉由email來記錄結果，以便形成持續改善。

運行的重點在中間的【Doing】欄位，它分成專注與全景模式，並以25分鐘做切分。意思是當你專注地做了25分鐘的工作後，請切換成全景模式去審視一下5件事清單是不是有所異動，然後把最重要的事放在最上面，也就是接下來該做的工作，也就是最重要的事。

》在全景模式中，放眼整個地平線上的任務：從現在開始的一小時最好用來做什麼？
》給專注時段設置一個固定的長度 (整點時鐘<25 分鐘) 有助於保持良好的節奏。

如果你覺得排序很難的話，那就把它寫下來，然後用OKR的方式(註2.)去評估它，自然就容易進行排序了。

To-do List沒問題，問題出在你怎麼去用它。

註1. 單核工作法的循環裡有一個集草器清單，遇到不會立即處理的終斷時就把它擺進去。然後給項目三個屬性: 目標、利益相關人與進入的時間日期。每每做完一件工作項目，就回過頭來看看集草器清單。在快速排序一下，決定是否放入優先開工的事項裡。

註2. OKR (Objectives and Key Results)全稱為“目標和關鍵成果”，是企業進行目標管理的一個簡單有效的系統，能夠將目標管理自上而下貫穿到基層。是企業進行目標管理的一個簡單有效的系統，能夠將目標管理自上而下貫穿到基層。它的簡單性其實更適合運用在日常生活上。

看板的流程管理

2021 年 02 月 23 日2021 年 03 月 03 日 ruddyllee發表留言

主管站在看板前該想些什麼呢?

看板可視化了主要的開發流程，但無論是設計得再好的流程仍然需要管理來輔助，因為它是不會自我管理的。團隊運作的主要流程當然應該由團隊自我管理(self management)。那主管呢? 組織與經理人則負責資源、人員與績效目標的管理，也就是說管理者要負責看板上看不見卻又佔著重要地位的事務。換句話說；管理者在看板前觀察看板事件時的角度是由支持流程與管理流程的角度做出發點。也就是一方面由巨觀的角度參考由目標、績效、資源與界面接口為重點來思考與解釋真正的問題。另一方面；要細膩的看著出問題的事件(工作單)並以上述四個特性去追蹤挖掘思考是哪裡出了問題。

流程管理

需要考量到人、事與管理上的問題:

流程除了主要目標之外，是否擁有合理的子目標? 個人目標?
當我們專注於流程效能時，是否忽略人員的績效管理. 誰讓團隊鰾線得更好?
團隊的壓力是否合理，是否有常態的循環，團隊是否得到了足夠的資源配置.
流程中步驟與步驟間的接口是否進行了有效的管理。

一個組織的工作其實是由主流程、支持流程與管理流程合力完成的。

《流程聖經》(註1.)

範例: 生活就是故事，把故事寫在卡片上，將從起床後到出門前的所有行為記錄下來，就是你的晨間故事。因為它是流程所以可以把它組成看板的型態，顯示如下:

你可能會按照時間的充裕程度來選擇做不同的事情。並試著調整(限制)你從起床一直到整裝出門所花的時間。在以時間為基準時你會得到所有工作的優先順序，也就是排列出它們的重要性。一旦有了可視化的順序依據，你就能夠輕易的看出流程中最大的浪費、找出最有意義的事是什麼?最不可缺的是什麼? 這個時候便可用時間做基準調整出屬於你個人的最佳流程了。

上面陳列了你在早晨時的主要流程(primary process)，其實；每張單子也就是每個工作項的背後，可能都還有用來支撐它的流程，我們可以稱之為支持流程(support process)。例如: 吃早餐；如果前一天沒有去麵包店購買麵包，則今天打開冰箱就沒有麵包可吃了。或是前幾天沒有去買鮮奶，冰箱裡就不會有鮮奶了。整個流程就會被打亂了。另外；針對多人的情境，當家人沒有相互配合好的時候，也會造成流程出狀況無法順利完成。例如孩子的學校有校外教學的時候，家長就要配合他的生活作息作調整，我們可以稱之為管理流程(management process)。這便是看板方法在管理流程時的多角度考量。單一團隊所運行的看板流程就是主要流程，背後還有其他團隊需要協作的工作或服務資源調度，就是支持流程，而公司組織所提供的資源協助，便是管理流程。有時候它們都是可見的，也可以串接起來，例如 DevOps 中的開發與維運就能清晰的串接起來，成為主要流程一起來評估效能。但其他流程；一般都是隱形的成本，但也不能被忽視，一旦忽視了就會出問題。

小結

一個組織的工作其實是由主流程(業務、開發、維運)、支持流程與管理流程合力完成的。團隊運行看板方法只是其中的一環，為了看清全貌，我們可以把開發與維運流程相結合(就成了DevOps看板)或是把業務流程也加進來(BizDevOps)，自然可以看的更清楚了。這時你會發覺這些流程需要管理嗎? 想當然是的。要知道；流程可以自行運作但它需要細心的管理來維持或績效改善。這是管理人的職責。

由看板發生的種種情境去發掘團隊運作的好壞、正常與否。

在管理流程時；我們可以由主要流程向前看到業務端時，往往可以發現外部有著更大的目標可以去設定去追求，適當的目標往往可以起到激勵團隊的作用。往內看到團隊成員的工作績效時，明白要落實績效管理才能有效的支撐流程的高效運作。因此我們不能忽略流程的管理；也就是看板運作的管理面。一般的管理階層通常都只是看到團隊在看板上的進度與效能的表現，但實質上我們需要進一步去了解為什麼?為什麼會這個樣子，這是管理者不該忽略的地方，經常去關心看板的為什麼，是我們進行平時績效考核的一種依據。例如: 我們應該時時關注；誰讓團隊表現得更好? 誰又需要鼓勵來讓它迎頭趕上大家的步調。這也是各級經理人在運作看板時應該作到的管理行為。

註1.《流程聖經》為流程教父拉姆勒&布拉奇的經典著作。企業轉型升級的助力之作。

看板方法 :以人為本，跨越邊界

2021 年 02 月 08 日2021 年 02 月 18 日 ruddyllee發表留言

軟體設計的開發應變力，關鍵在於「以人為本」。

《Agile Software Development》

軟體開發不同於產品製造，你無法用產品的分工機制來加快軟體的開發。當然；將看板運用於軟體開發上也應該與運用於生產製造上有著不同的重點。在講授看板方法時經常被詢問到:『團隊是否已經達到能力的上限了? 要如何得知呢?』其實真正應該關注的是團隊的士氣。

改善軟體開發的祕訣在於人，而不是製程。

Bob Martin

看板方法 Kanban Method

看板方法(Kanban Method)實踐的是軟體界的流程，它的目的是要你打破流程中關卡的邊界。如果你還是以Toyota式的思維在運行看板(TPS 讓產品的製程視覺化，而看板方法則是可視化知識工作者的工作流程)，則很多地方都會將你帶到傳統開發的思維方向去。然而；軟體開發沒有傳統產品線在製程上重複的機械式工作。又前一次的工作量、做了多少時間並不能做為下一次工作效能的依據，所以說軟體開發就像是從事藝術工作一般，沒有一支程式會長得與任何其他程式一模一樣的即便它們有著相同的產出，程式的這種獨特性打破了傳統看板的執行規範。所以如果你還在強調步驟與步驟間的效能、速度那就錯了。你應該看的是全貌，整體(團隊)的效能才是你應該關注的。

應該關注的是團隊的士氣，而不是他們達到最大工作量了嗎?

燃盡圖不是效能圖示

它是團隊開發的進度警示圖。我們常犯的錯誤是『上回團隊做了多少故事點?』、『這一回團隊應該做到多少故事點?』這是一種錯誤的思維方式。軟體開發不比規律式的產能，人的因素始終佔著最大比例。可視化的「燃盡圖」目的是讓我們(每天都)能看到工作進度的全貌，同時知道目前自己在哪裡。完全是一種系統思維的模式，團隊可以在站立會議時看到產能運作狀態，就像接受紅綠燈一般的警示作用。圖上的數據也是拿來做為參考使用的，例如: 有人請了幾天假，那進度勢必會跟不上。如果我們想維持進度，則就要採取相對的措施才行。

小結

跨越邊界；看板上的流程是用來跨越的，許多看板的使用者，不管運行了多久的看板方法卻從頭到尾都依據同一組流程來跑看板，這麼做就錯了。要知道；在同一個步驟內追求效率，致力於消除浪費，努力的提升效能降低半成品數(WIP)，這是不夠的，正好犯了限制理論(Theory of Constraints，TOC)所謂的局部優化的徵狀。正確的方式；應該先嘗試運用不同的開發流程，在找出團隊開發上的最大約束之後(例如:單元測試或整合測試)，再針對這個約束去擬定改善策略，以科學實驗的精神(假設-實驗-驗證)來發掘問題並改善問題，這才是運行看板方法真正的精神 —嘗試運行不同的流程。

早期TOYOTA時代的運用看板，是在追求產品製造過程的高效能運作。而 David J. Anderson 先生發明的看板方法(Kanban Method)則是運用在軟體開發上，適合做為敏捷變革前置運作的視覺化工具，它能讓團隊成員因為看見了自己在開發上所表現出來的效能，因而引發改善的意念，藉此激發團隊持續改善的意識。因此在運作上並非侷限在每個欄位的效能或致力於消除queue的浪費上頭，而是以人為本追求團隊開發的整體效能為依歸。

註 1. 《Agile Software Development》敏捷軟體開發為 Robert C. Martin 所著

註 2. 看板方法六大核心實踐

顧問的 20/80 簡報製作技巧 – Ghost Deck

2021 年 02 月 04 日2021 年 02 月 08 日 ruddyllee發表留言

Ghost Deck有人翻譯成「空白簡報」，但它並非完全空白。也有人以直譯的方式翻譯成「幽靈甲板」就有點像遊戲或小說的名稱，這裡就直接用原文了。它是一種簡報製作的快速起手勢。讓我們針對手上的既有資料快速勾勒簡報檔的整體架構，也就是用少少 (但要多少才夠呢?我想20/80法則或許不錯) 的資訊去發掘事件的全貌，隨後再逐步的去補足80%的資料內容。是一種非常符合敏捷精神的簡報製作法(敏捷開發以重復式由淺而深的增量方式構成迭代作業，如下面的蒙娜麗莎圖示)，講求先構建輪廓，再逐步釐清內容的簡報製作方法，不論是麥肯錫顧問公司(McKinsey & Company)或是波士頓顧問公司BCG都依據 Ghost Deck的方式訓練旗下顧問運用這種方式來製作建議案。

所謂Ghost Deck的概念，就是一堆沒有內容的投影片的組合。舉例來說，假設一場簡報有11張投影片，大部分的投影片都還沒有填入內容，有些投影片上面有文字，但只有填入講者想對聽者說的重點，或是講者想強調的論點，但沒有具體的說明。總而言之，其中包括了故事情節(storyline)之外，也包含想要傳達的重點，以及為了支持該重點所需要的資料或分析資料的圖檔。說穿了就是一個虛構的投影片檔。

Ghost Deck 的好處

這是一個先抽象化勾勒輪廓再具體化實作內容的概念。它不僅僅在整理思緒、決定哪些工作非做不可的事情時能順利派上用場不至於遺漏。更能基於假說思考來快速的組織簡報，無疑是顧問工作的利器。這種做法像極了敏捷開發以重復式由淺而深的增量方式構成迭代作業的效益。好像畫家作畫時，會先從輪廓開始，然後再逐步填入元素加深各個部分。這種先全貌後細節的好處是:

它可以協助更加清晰的思考。
它是一種對已知與未知資料的盤點。
對不足資料的盤點，讓我們不至於只關注部分重點而迷失了方向。

先架構化在填入細節

所謂的將故事架構化，是指模擬整件事情是以某某內容與方式所構成的整體輪廓。這是一種結構化思維的過程，如果你的框架結構是合理的，接下來的步驟也會因此變得容易起來。你所創造的內容就是方案的大綱，而且它架構了一個故事，彷彿作畫一般，輪廓以概略說明全貌，再來才是去填入那些足以吸引人的細節元素。你的目標是讓聽眾或溝通對象能夠輕鬆的解讀，避免冗長敘述而容易造成錯誤的解讀。由於人們傾向依靠自身的經驗來解讀信息，因此能有一個清晰的輪廓可以避免在一開始就走偏了。

運用假說思考組織簡報

你作了一個假設，然後證明它是對的還是錯的。這種敘述問題的方式是最有說服力的了。在邏輯上稱之為演繹法。人們在面對未知的情境時，能夠依序的運用邏輯推理來產出結論，當然就容易被人們所接受。

小結

身為講師；早就已經習慣以做簡報的方式來進行學習。也就是理查德費曼Richard Feynman所謂的費曼學習法the Feynman technique (為諾貝爾物理獎得主理查德費曼所創造的一種快速學習方法)。以簡報來促發自我學習的效果尤其快速。但若是要拿來說服他人的話，就顯得凌亂無章了些。為了增強說服力，往往會再採用麥肯錫的金字塔原理將整篇資料由結論先行的方式輔之以歸納或演繹的邏輯論證來重新寫過。拿一個我典型的簡報演講跟大家分享:

一場Keynote 可能只有40~60分鐘，演講者要介紹自己又要介紹今天的主題，又要有自己的風格，然後又希望能夠打動聽眾。想做的事實在太多；而時間始終是不夠的，所以我選擇能夠在聽眾(學員)心中留下一些印象、一些蛛絲馬跡這樣就夠了，讓他們在未來有機會遇到相關的問題時，能夠有跡可循就不虛此行了。所以我採用的是倒敘的流程，先介紹題目、介紹自己，然後就破題(結論先行)，接著就跳到後面的「看見全貌」投影片(一般演講；正式結束的投影片是 Q&A問題看板頁)，要求聽眾思考「後退一步的真諦」無論它現在正在做什麼，客觀的回顧一下，是加強反思的手法，希望帶來對學員有用的思考。接著會以圖示的方式，三言二語就把整個演講內容介紹完畢(全貌出來了)。隨後才是跳回去主題，開始我的演講。

註《假說思考》作者: 內田和成第三章洞察事情的整體架構，介紹到了波士頓顧問公司 BCG 的空白簡報法(Ghost Deck)

麥肯錫顧問公司的 Ghost Deck 在這裡。

計畫是為了更少的開發

2021 年 02 月 01 日2021 年 02 月 01 日 ruddyllee發表留言

產品開發的真諦

用最小的開發成本為客戶製造最大的價值。上圖借自《用戶故事地圖》作者 Jeff patton 在使用前必讀的起始章節中的說明。它屬於對PO產品負責人的期許，核心概念是人們透過產品的製造、新功能及特性增強來改變這個世界，而促使現在邁進到未來的則是製造產品所依據的思維:『 需求正在改變這個世界』。講得更清楚些；是成千上萬的產品負責人透過規劃需求的方法，製造出各種產品來促使人類改變生活方式進而改變這個世界邁向未來。

需求正在改變這個世界

– Jeff Patton

用戶故事地圖的目的

在《用戶故事地圖》裡 Jeff Patton 告訴我們:『用戶故事地圖真正目的是造成對需求認知的共識』。我們一群人圍繞著使用者故事地圖，從左到右描述著用戶會採取怎樣的操作步驟，然後再由上往下來討論上層的操作活動，再針對每個細節討論如何實作才能達成上一層的功能任務。然後從專案開始到結束為止，應該依據著需求的變化，大家持續更新著地圖上的任務。讓視覺化的全貌協助我們自始自終讓所有的人都能知道團隊已經完成那些任務現在正在進行怎樣的工作、專案的全貌長成什麼樣子而我們又在哪裡。換句話說；就是因為透明令大家都看見進度，而更是看見後能夠擁有相同的認知；達成了一致的共識。

使用者故事地圖；希望讓我們能夠在專案開發的過程中，一直看到需求被實現出來的樣子。並強調用戶故事最重要的不是寫下了什麼? 而是讓人在閱讀時會記得什麼? 就像度假時的照片一樣。

計畫是為了更少的開發

產品開發的前提是運用最小的開發功能爭取對客戶最大的價值。並基於產品是由多個獨立或相依功能所組合而成的這個概念，運用一個使用者故事地圖來涵蓋多種不同的使用者，如上圖中的User Type, 也就是使用者類別。換句話說；針對某一種使用者類別就能夠運用產品功能規劃而採用使用者故事地圖工具預先畫出他會如何使用產品時所留下的足跡。再運用產出的使用者故事地圖作為依據進行功能提供的開發作業，而不同的使用者則只是不同功能組合的結果，所以產品功能在對照到不同的使用者類別時(由於不同的使用者對產品自然會有不同程度的需求)，自然會產生需求的重要性排序，因此我們開發產品時自然就可以依照主要的客戶形象(persona)將產品功能區分成必要(must have)、應該要有(should have)、能有最好(could have)及不會有(won’t have)的功能區分，這正是著名的需求四類區分法MoSCoW(註1)。

需求分類MoSCoW的案例

英國國防部在2009年左右，為了減少友軍誤殺自家人的事件(註2)，決定開發一套戰鬥識別系統(Combat Identification System, CIDS)，避免悲劇繼續發生。採用的需求四分法是一個典型的放棄傳統計畫驅動開發改為價值驅動開發的作法。下圖中左側是傳統計畫型開發考慮的「時間-資源-需求」專案鐵三角。對正到右側的DSDM(Dynamic Systems Development Method)敏捷開發方式，差異在左側不可變的功能並預設可改變的是時間與資源，也就是專案開發必須完成所有的需求才算完成，右側則是站在開發者的立場，視需求功能是可調整的項目，並依此來配合固定的時間與資源量。

當PO無法抉擇需求的MoSCoW分類時 – 採用不同的使用者類別

計畫是為了更少的開發；這個道理大家都懂，但是你若以計畫驅動開發(傳統)的思維方式來規劃開發方法的話，就是會以在時程內完成所有的需求為目標。而忽略了不是所有使用者都會需要所有的功能的。因此請扭轉你的思維改以先完成哪些對使用者最有價值的需求，也就是價值驅動開發的思維方式。做法是:採用不同的使用者類別(persona)來區分需求，一定有一些需求是大部分的使用者都會用到的，這些便是屬於 Must Have的部分。也一定會有一些需求沒有那麼多使用者都會用到的，這些僅次於Must Have的需求，就可以排進Should Have的部分。至於那些看起來不是非要不可的需求就屬於 Could Have 的類別。在其他的便是Won’t Have了，也就是不會被列入開發工作的需求。

什麼都要是一種資源分配的問題。

適當的資源分配；

用之於時間；稱為效率。

用之於需求；稱為專注。

小結

主管在討論需求時經常是「什麼都要」，團隊(PO們)也就經常用這個來作為無須排訂需求優先順序的藉口。其實這是一種資源分配的問題。主管們經常考量的依據是該選擇專注於重要的項目的投資報酬率會比較好呢? 還是追求產品功能的完整性會比較划得來些。但其實真正應該考量的是以對客戶最有價值的投資是什麼為依據，而不是基於自己開發團隊的能力，因為這才是產品開發的本質。

註 1. Case Method Fast-Track: A Rad Approach by Dai Clegg

此為ORACLE經典 Case Method 叢書。出版於 1994/09.

註 2. 英國國防部在2009年投入開發的戰鬥識別系統(Combat Identification System, CIDS)，CIDS專案目的是減少友軍誤殺自家人的事件。系統分成三期開發，所有需求以Dai Clegg 的MoSCoW分類方式進行。成功達成了敏捷小增量、多迭代的繪圖式開發方式。

參考自: https://idlsocweb.org/Documents/Symposiums/IDLS2009

註 3. 用戶故事地圖 User story mapping

用戶故事地圖作為一種對照需求開發工作是一種極為有效的規劃工具，越來越廣泛地應用於團隊開發實踐中。Jeff Patton 編著的《用戶故事地圖》以用戶故事地圖為主題，強調以合作溝通的方式來全面理解用戶需求，涉及的主題包括怎麼以故事地圖的方式來講用戶需求，如何分解和優化需求，如果通過團隊協同工作的方式來積極吸取經驗教訓，從中洞察用戶的需求，開發真正有價值的、小而美的產品和服務。

讓敏捷更敏捷的「假說思考」

2021 年 01 月 19 日2021 年 04 月 21 日 ruddyllee發表留言

身為敏捷教練；可能一輩子都會不停地在尋找能夠讓敏捷更加敏捷的方法(它可能就是我這輩子的課題了，就是無限賽局。註0)。其實可以推廣的理念很多，例如 Dan North 的刻意發現(Deliberate Discovery)，就是一個讓敏捷開發更早開始的好概念。應該算是團隊在開始開發行為之前的前置處理動作吧。這種讓開發者在還沒開始動手之前就能先加強相關domain knowhow的做法(增進開發專案的相關知識)，對即將到來的開發作業一定會有著某種程度上的幫助的(與prototype 或MVP應該有著一樣的貢獻)。波士頓諮詢公司BCG的「假說思考」在某種形式上也算是一個前置思考的方法，但要更讓人驚艷。

我們習慣的思考方式

一般人在面對問題的時候，都會採取先搜集、分析資訊再做決策。也就是依據戴明博士的 PDCA循環(註1)做解題的動作。這樣做的結果往往容易花費大量的時間在做資料蒐集(尤其是在現今資訊過量的時代)，卻未能及時的拿出解決問題的策略(敏捷化的團隊則是在收集了部分足夠開工的資訊後就啟動Sprint，這種啟動方式避免了過度分析資料的做法。說起來是一種快速啟動作業的開發方式)。但其實；在這個資訊爆炸的時代「捨棄資訊比搜集資訊更重要」。因此而衍生出來一種更快速的解題模式，它的做法是先構建假說，並在向前推進工作的同時，對假說加以驗證，然後持續探索解決策略。這是一種既科學又符合敏捷精神的作法；這種方式就稱為「假說思考」方式。

在VUCA的時代下，未來是多變、不確定的，因此無論多大規模的企業，都需要應對未來的一切變化。所以，應該培養並持續累積顧問式的經驗法則，如此便能在遭遇問題時立即(先)做假設，以快速的回應來爭去時效。這對任何企業的管理者來說，藉由累積的經驗來掌握假說思考方法都是至關重要的。

假說(hypothesis):未經證明而最接近答案的解答。

–內田和成

假說思考: 就是先做假設，然後再去驗證它的對錯，藉此避免過度蒐集資訊，而浪費太多時間在做分析上。它是以結論為起點的一種思考模式。從右腦大膽假設，再交由左腦細心求證。可分成二個先後階段: 首先藉由假說找到真正的課題。再續用假說尋求解決課題的最佳答案或最適決策。

首先要有假説 – 第一條法則: 捨棄資訊比搜集資訊更重要

提出假説的好處是能加速解決問題的速度，而且能避免一開始就陷入資訊洪流中，藉著思考描繪問題框架(避免一開始就Google!)。有經驗的顧問們通常都能見微知著，從簡單的細節看出問題的模式(pattern)，然後提出假説並釐清問題解決流程。不過就算是新手，也別害怕提出假説，一旦發現錯誤了，只要能心平氣和地修正就好，千萬不要死守假説或不必要的資訊。最後要相信，對顧問而言；假説能力遠比分析能力更重要，因為唯有能提出解決方案的人才能成為顧問因而立足商場，如果過度重視分析能力而身陷資料流沙中，便無法幫助企業解決問題。

在目標確定之後，透過大家Brain Storming ，列出種種假設，然後挑選最被看好的幾個依序去分析它們，再去驗證它們，如果錯了就換下一個來做，發現對了就挖到寶了，這麼做；怎麼說都比全部去分析、驗證要划得來許多，省下不少時間。是先快速做假設，看起來很盲目但其實對於一開始我們面對無知的探討實在是很科學的作法，能快速的過濾多做假設所造成的雜訊，也提升了許多效能。當你需要從許多需求中找到重點的好方法。

避免窮盡分析 – 網羅思考

網羅思考vs假説思考。網羅思考就如同人機對弈時AlphaGo所採用的窮盡分析法，每下一步棋，電腦就得將所有的可能性都分析一遍，強調決策一定要基於完整的資訊和分析角度。這在超級電腦上或許行得通，但在瞬息萬變的商業市場上則是行不通的，一方面商業發展的可能性無窮無盡，另一方面它變化快速，而網羅思考耗時耗力，是無法滿足即時分析的需求而快速的產生解決方案的。

假說思考讓敏捷更加敏捷

假說思考的特色是；於一開始就從事物全貌切入，再來思考如何解決個別問題。這一點與敏捷強調以小增量、多迭代與尋求回饋的方式十分相似。敏捷避開了傳統開發法在前置分析上的時間浪費。但這麼做只縮小了在開發量上資源的浪費，並未減少需要收集資訊量的大小，若是再加上預做假說的思考模式，就可以大量減少資訊收集的範疇(對系統思維System Thinking而言；就是先運用假設來縮小系統的邊界)，而在分析、求證上只針對該假設的範疇來進行，在時間上更符合小增量、多迭代的思維，然後在透過驗證假設是否正確的嘗試得到實質上的回饋。做為新假說的依據。所以說；假說思考的方式能讓敏捷更加敏捷，也更能聚焦在一個基於假說上的小增量上頭。也更符合科學精神。

假說思考是來自波士頓諮詢公司BCG的策略思維方法。(請參考内田和成所著的《假說思考：培養邊做邊學的能力，讓你迅速解決問題》，原著標題是The BCG Way—The Art of Hypothesis-driven Management) 是一種思維模式也是一種顧問需要養成的習慣。就是在解題時從資訊還相當有限的初期階段起，就不斷思考問題全貌與結論的方法。先做假說；這麼做可以有效的減少需要考慮的系統範圍，一旦系統範圍縮小了，就能讓我們更專注在小事件的驗證上，小範圍能便於快速的進行驗證，又能以逐步釐清的方式去看見問題事件的全貌。它符合敏捷開發小增量的核心觀念，讓我們專注的聚焦於小的驗證上頭，逐步去釐清問題的看見它的全貌。

要了解自己的第一步，就是做出一個決定 ；然後去質疑自己關於自己的種種預設，去積極考證我們在別人眼裡的樣子，去帶著一種積極的思維和接納自我的態度去追求真實。

-《深度洞察力》,TASHA EURICH

傳統思維 vs 假說思維 的敏捷性

傳統開發法是認為仔細的分析後就能按部就班地完成專案。相對的；敏捷開發追求邊做邊學，再蒐集足夠開工的資訊時就快速的開工，以應對變化為常態的一種開發方式，進行方法是衝刺(sprint，全力邁進)的小增量、多迭代與尋求回饋的開發作業。傳統對問題的思考模式是認為資訊收集的越多，就越能確保決策會越正確。假說思考法則認為: 捨棄資訊比搜集資訊更重要。運用假說來縮小驗證的範圍，迅速的邁入求解的途徑。

假說思考的好處

1. 解決問題的速度倍增: 以答案為起點的做法，讓該做什麼變得清楚分明。

2. 能夠累積出解題的路徑，有效的「定位問題」: 如果在遇到問題的同時，就能夠在心裡建立「暫時的解答」，便可以很快的去「驗證這個暫時的解答是否正確」。

3. 假說無論對錯，驗證完後(對/錯)， 都能夠讓下⼀步更清晰 : 如果目前假說是對的，可以深入分析，並試圖提出可能的解決方案。如果發現假說不對，便可以快速的換到下一個假說去驗證它。

4. 可以有效累績、運用過去的經驗 :「假說」是基於現有知識的最佳解，因此隨著你對於問題的相關領域的了解越來越深，或是日積月累解決問題的經驗越來越豐富，很有可能在一開始就提出了正確的假說。因此假說暫解是善用及累積經驗的好方法。

以假說(設)為基礎的思考方式，是一種以最短時間有效達成目標的方法。

小結

敏捷開發Agile development不是一種快速的開發方法，它是應對需求多變的一種開發方法。目的是避免軟體在專案前期花費太多時間進行分析、文件製作的工作上，而在遇到變化時反而因為依循計畫而失去彈性的缺失。波士頓諮詢公司BCG的「假說思考」則更進一步的依據工作者的經驗先進行假說，有效的縮小了問題系統的開發範籌，雖然它是顧問公司所用的一種快速取樣驗證的手法，但在搭配以敏捷化的小增量、多迭代與尋求回饋的增量，就更能展現出它的效益了，也更能符合多變的VUCA時代的問題特徵。

假說思考法是一種顧問的策略模式。是一種吻合科學實驗的方法(若是你沒先做好假設就開始做實驗，當取得實驗數據時；反而會不知如何去詮釋)。它以為在問題出現的前期，即提出假説的好處是能加速解決問題的速度，而且能避免一開始就陷入在資訊洪流因為吸收過多訊息而造成分析上的時間浪費。這是一種基於捨棄資訊比搜集資訊更重要的實際行動。核心觀念是遇到問題時，先「想」或猜(依據經驗而來)有什麼可行的解法，接著再進行數據的收集與分析驗證。也就是所謂的「大膽假設、小心求證」的科學實驗精神。這與我們一般在做策略規劃的流程: 先分析再設定目標然後擬定對策的正規思考方式不同(1.現況、2.目標、3.分析、4. 擬定策略、5.資源投入與建議的五步驟解題流程)。假說思考法是直接跳到最後一步(步驟五、資源投入與建議)上，依靠顧問的直覺與經驗快速的給予解題建議。但它是一種暫時性的答案，還需要驗證，透過驗證才能確認問題的全貌與結論。

《假說思考法》作者內田和成在書裡的定義；所謂「假說」，是指在蒐集資料過程、著手分析之前先做的「暫時性答案」。「假說思考」可說是一種思維模式或是習慣，從資訊還相當有限的階段起，就不斷思考問題全貌與結論。換句話說；是一種刻意發現。換言之，假說思考法的精髓在於”假設可能的答案”，而這個答案可能是整體問題的答案，特定步驟的答案或是支援論點數據的答案，而它只是一個”暫時的答案”。所以問題來了，如何進行此假設，或是如何提升假設的準確度與深度呢？這便是顧問公司所擁有的實力與經驗了。也就是我們常常聽到的麥肯錫顧問公司Mckinsey或波士頓顧問公司BCG這類的顧問公司，在為客戶提案之前早已完成了”70%的結果”，而這七成的結果其實就是從經驗或過往案例所推演出來的假說結果。說穿了就是依靠顧問們在實戰經驗中累積下來的相關經驗，正是敏捷開發中所謂的經驗主義下的快速產物了。

解決方案先行

所有的客戶都急切的想從顧問口中聽到解決方案，為了有效地說服客戶，我們花費大量精力去尋找合適的資料，繪製複雜的表格，製作大量的PPT，為的是用精準的數據來打動聽者。但這種方法並不怎麼有效，我們的溝通對象根本沒有時間和耐心來聽枯燥的報告，他們需要的是解決方案，而且立刻就想知道！因此假說思考法便顯得如此可貴。因此要持續累積經驗形成模式(pattern)才不會讓我們弄巧成拙。就如《極簡思考》作者Mike Ferriolo所言(註3. 推廣結構化思維)；假設是一種實驗性的、可在未來分析中做進一步測試的觀察、現象或疑問。在結構化思維過程中，假設是你在第一步中為問題找到的答案，你之後將以它為核心進行分析，從而將其證明或推翻。不要擔心，在你把方案徹底想好前，你無須將結論與任何利益相關人分享，一些利益相關人直到你做完了全部論證才能看到你的想法。跟科學實驗相同，實驗室的初步假設往往與事實有著巨大的差異，但最終你卻端出了極具價值的原理。請記住，當你埋首於分析的時候，你並不能創造任何價值。

假說先行的思考方式；對於專案負責人PO或資料分析團隊Data Team而言，都是一種先定位後驗證的科學式思維。運用系統思維的說法是一種能讓我們面對眾多的選擇中縮減範圍畫出系統邊界再求證的做法。對專案負責人PO而言，在面對龐大的產品需求時，可以大膽的假設客戶只需要這些足夠的需求，就能接受我們的產品並感到滿意。因此而勇敢的排除了那些次要的功能，選擇依據假設先完成部分的功能，讓開發時間變得簡短了。然後在以客戶的回饋作為驗證，修正假設。若假設是不符合客戶的期望，再修正假設決定是那些功能需要既須開發來滿足假設。對於資料分析團隊言，則可以先鎖定假設，不致於被蒐集到的龐大資料所迷惑，以至於難以做成分析結論。並在持續收集到的資訊中驗證假設是否正確，並持續的修正假設來獲取結論。

註0. 《無限賽局》賽門‧西奈克 2020年的著作。敘述人的一種崇高的信念：值得我們為它努力的事物。

註1. 戴明博士的PDCA 循環；是針對品質工作按規劃、執行、查核與行動來進行活動，以確保可靠度目標之達成，並進而促使品質持續改善。這個過程也被人們熟知為：Plan-Do-Study-Act（PDSA）。是企業界早已普遍運用的一套「目標管理」流程，透過規劃Plan、執行Do、查核Check、行動Act四階段，確保每次的目標都能達成。

註2. 假說；Hypothesis。亦可翻譯成假設，但是為了符合原著上的翻譯，這裡一律採用假說一詞。

註3. 《極簡思考》by Mike Ferriolo, 迈克·费廖洛。書中闡述的極簡思考法: 結構化思考。結構化思考是被假設驅動的，出於以下幾個原因。這個方法可更快地找出一個答案。你的假設將確定你論證所需要獲取的資訊，並指出哪些資訊與你最終的結論無關，以此能減少你花在無用分析上的時間。假設能讓你以事實為依據去找尋結論，也能讓你有能力找到事實來證明或推翻它。如果你推翻它，你將進入優化反覆運算的過程，直到找到一個可以證明為“真”的建議。你的假設越簡潔，其他人就越有可能理解你的回答和建議。

註4. 如何選擇一個正確的假設?

敏捷管理就是善用情境領導

2020 年 12 月 21 日2020 年 12 月 24 日 ruddyllee發表留言

主管需要成為“教練”嗎?

是的，主管需要成為團隊的教練。因為今天組織是以團隊運作的方式為主，已經不是主管一個人所能獨自完成的工作了。主管需要的是去瞭解他們的員工正在做什麼，但是並不是要像每位員工一樣能夠熟練地完成工作。再說；現在的員工並不需要一個權威人物來告訴他們或督導他們做什麼了。相反地，員工需要的是一個能夠傾聽、指導、訓練以及幫助他們的「教練」。身為教練這個角色的首要任務，便是能夠確保團隊成員擁有完成一流工作時所需要的資源。同時；還必須不斷激勵他們學習成長，為他們釐清責任和目標，使他們能提高工作績效，並且在組織內貢獻自己的力量。(參考: 《高績效教練》by: Sir John Whitmore)

主管需要的技能

成為你所負責的(主要)活動的通才。越是高層的管理者越需要是通才。你必須在這個領域上成為通才。也就是說；大多數的主管在他們所熟悉的特定領域內進行管理，只有如此你才能了解團隊成員們所遭遇到的困難。但就熟悉的程度而言；你只需要是一個通才。相反的；「人際關係」是一種能讓成員很好地與別人一起工作的能力，理解團隊的需求，建立良好的溝通，以及激勵他人的能力，這樣的人際技能，反倒是主管所不能或缺的。

由於主管是通過其他人來完成工作的，所以對於團隊而言；他必須擁有良好的人際能力來溝通、激勵、協商、授權和解決衝突。尤其是對工作上的概念(conceptual)，雖然沒有必要懂得工作上的細節，但是能夠擁有足夠的概念，在就實際而言，這種「深入的概念」將更能幫助管理者做出更好的決策。尤其是對相關領域的熟悉程度，也就是需要有更充足的領域知識(domain knowhow)，以建立足夠溝通的良好模式。
.

情境領導理論 Situational leadership theory

主張領導風格應該根據具體的情境而有所不同。為保羅·赫塞(Paul Hersey；老師）和他的學生肯尼斯·布蘭查德(Kenneth Blanchard)所共同提出的理論。情境領導關注於所謂的員工成熟度。成熟度(readiness，D1-D4) 指的是員工能夠並願意完成某項具體任務的程度。赫塞和布蘭查德定義了成熟度的四個階段：

階段1 = D1：員工既缺乏能力但滿腹熱情時。【熱心的新手】

階段2 = D2：員工能力提升但仍需協助，且無意願從事必要的工作。【半生不熟】

階段3 = D3：員工有能力但卻不願意做領導者希望他們做的工作時。【專家】

階段4 = D4：員工既有能力又願意做領導者希望他們做的工作。【獨自處理】

該模型主要在說明的是作為一位領導者，你應該怎麼去做。也就是針對不同的階段你該如何進行溝通，就是依據成員的行為反映來進行不同的溝通方式和類型。

隨後布蘭查德又提出進階的「部屬發展模型」Development Level of the Individual 4階段，以員工的工作能力和工作意願，來判斷員工處於哪一發展階段，並據此將部屬個人的發展階段與主管的領導風格連結了起來。因為是藉由不同的工作任務來界定員工處於哪種發展階段，所以當某一項工作任務更換時，就得重新診斷員工的發展階段。(參考MBA智庫百科)

情境的S1-S4 相對於成熟度的D1-D4:

低能力、高意願 D1：部屬為新進員工時，雖然工作意願高，但對工作技術不熟悉。這時領導者應採取「指導型」S1領導風格，協助員工。

能力平平、意願低D2：部屬的能力雖然有所進展，但在工作上還是需要幫助才能完成，遇到困難時，部屬工作意願跟著降低。此時領導者應採取「教練型」領導 S2，除了指導外，還要給予較高的支持行為，傾聽部屬的困惑。

高能力、意願不定D3：員工有足夠的能力，但欠缺獨當一面的自信，或不確定自己能不能做好，此時適合採用「支持型」領導S3，由領導者和部屬一起進行決策。

高能力、高意願D4：員工有充分的能力和意願，對自己的能力充滿自信，甚至可能比領導者更有經驗。此時領導者應該採用「授權型」領導S4，由部屬來決定工作的計畫和組織，偶爾過問工作的進展情況和遇到的困難即可。

結論

情境領導模式只是一種可以幫助團隊成員成長的領導方式的簡易判斷模式。強調的是領導者應該依據成員的「成熟度」來決定採用的領導方式。目的是幫助團隊成員的成長。只是一種易於運用的領導風格。藉由D1~D4的成熟度分析來決定領導者需要採用的管理模式，也就是 S1~S4情境運用。

敏捷教練也能依據這個模型，指導主管應該前進一步去協助團隊成員，或後退一步讓團隊成員自己做決定。也就是:

當成員處於S1情境: 缺乏能力但滿腹熱情時，這個時候主管無法光靠引導的方式就能讓成員順利完成任務時，主管此時應該要勇於前進許多步，主動協助完成工作。
當成員處於S2情境: 成員的能力提升了但仍需協助，且工作意願不足的時候，主管此時應該要前進一步，除了主動討論如何完成工作之外也給以適當激勵是十分重要的，並協助他做好正確的決定。
當成員處於S3情境: 有能力但卻意願低的時候，此時主管應該要後退一步，主動與該成員一起討論如何完成工作，但將決策交予該成員。譬如: 下屬跑來請示應該如何完成工作時，此時主管對有能力完成工作者，不應該直接給予建議。反之；應該詢問該成員，準備如何完成他的工作，採取退一步的方式，引導他想出對策，不直接給建議。
當成員處於S4情境: 既有能力又有意願做領導者希望他們做的工作時，主管應該後退許多步，授權下屬讓他能完全獨自完成工作，主管只需稍加留意即可。全權交予下屬自行做決策，只在必要時予以提醒協助。

應該授權或賦能到什麼程度與方式? 應該視(依據)成員的成熟度來決定如何做前進或後退的指導方式，並非一意運用引導(Facilitation)的方式，或是全然採用命令干預的方式進行管理的措施。傳統上；大多的主管只會採用一到二種策略來進行領導下屬的行為，赫塞和布蘭查德的情境領導理論則提供了更完整的視情境決定領導方式，值得敏捷管理者參照。

參考: 《高績效教練》by: Sir John Whitmore 及 MBA智庫百科.