黑先生

【工作流程 - 問題探索工作坊】 假如團隊中有一個工作流程問題，會想要具焦解決問題呢? 會議or工作坊? 如果問題很明顯可見且範圍局部、時間短，可以用 會議 的方式來針對性的討論，但不要忘了準備相關資料。譬如說實際的例子、數據或相關資訊，在會議前能先發送給大家閱讀，或者開會前先導讀相關資料與宣告今天會議目標，讓大家IN情境後再開始，效果會比較好。 有個不錯的步驟可以參考： 澄清問題、分析問題、提出假設、驗證、解決問題。 相反的，如果問題層面比較廣且模糊，問題間似乎有許多關連存在，就會需要用長時間(1.5小時以上)的 工作坊 ，集合大家的經驗與討論，系統性地找出問題根源。 不管是用上面哪個方式進行， 定義出正確的問題，比找出解決方案更重要。 而這最重要的步驟就是， 事前設計討論流程與型式 。 會議或工作坊最好都有個引導者或主持人，讓會議不至於發散收不回來，蠻多書和網路資料都有提到相關資料，就不多述。而我自己常用方式，則是在於事前的設計規劃，透過適合此目標的思考框架工具，設計流暢的討論過程，產出最大效益的結果。 切入正題，這道理大家都懂，該如何設計與規劃才是重點。前一陣子剛好做了一個類似於會議的工作坊，效果還不錯，提供一個 通用的討論架構 給大家參考運用，而此方法也不難，取自於設計衝刺Design Sprint的理解目標(Day1)與分開發想(Day2)。 當時跑此工作坊的背景資訊， 一位新主管想了解目前要接手的團隊狀況，包括人員關係、工作流程與問題，但不知如何有效的聚焦出所要的資訊 。 以上的需求可想而知的就是把一團亂的思緒與資訊，整理出具體且可定出執行方案的狀態。 大致流程如下： ●理解目標 #請團隊成員先畫出目前的工作流程示意圖 #所有成員畫出工作心情曲線圖 #輪流分享自己畫的圖 #其他聽的人把聽到的資訊摘要寫下，貼到同理心地圖對應位置 #分享完後，再把同理心地圖便利貼做分類 #用How might we(HMW)的方式，替分類的資訊重新定義問題 #HMW是由團隊共識後寫下，這也是最棒的地方，會發現在討論的過程其實就自我察覺形成解決方案的概念 ●分開發想 #每個人獨自寫下HMW的解決方案 #把方案貼到剛剛的流程示意圖對應位置 #視情況是否做分享或討論收斂 【結論】 事前需求確

【看板方法導入 PART 14 - 看板蛻變與進化(Design Sprint)工作坊】 人們對於一件全新的領域或知識，當有一定的熟悉度後，就會開始產生一些想法，想去嘗試對目前現狀做出些不一樣的改變。以「守、破、離」三學習階段來描述，是最適合不過的形容。 「守」，就是完全遵守教條； 「破」，要你重新設定以往學到的東西； 「離」，才能脫離過往，確立自己的風格。 對於一個團隊，經過九個月的看板方法洗禮，會有兩種反應， 一、習慣於現況，沒有想特別想法。 二、團隊成員開始自發性的表達，想要對目前的看板做些調整。 第一種狀況就需要客觀看一下，是趨於穩定還是淪於流水型式。如果是穩定的話，倒也不是什麼壞事，不一定特別要做出些什麼改變。反之，就需要反思一下目前到底發生什麼狀況。 可以從 結果、產出 來反推是穩定還是流水。 當團隊發出第二種訊息時，表示團隊要從 震盪期(Storming) 進入到 規範期(Norming) ，是最好重新檢視看板的時機；如果是強推改變，通常都不會有意願與沒動力想去調整。當然，如果教練或主管已經早就嗅到這機會，缺臨門一腳的話，可以多製造(挖坑)不同的觸發點或加深痛點，讓團隊自己提會是最好的方式。強求總是不會幸福的。 先前的幾篇看板方法導入，都是以「守」的方式漸進提功相關敏捷知識，應用在專案執行上，讓團隊慢慢吸收消化。而第一版的看板樣貌，也有很大的可能是由教練以經驗值直接提供適合目前團隊的看板格式，尤其是在大型團隊(快三十人)，就不好共識出看板樣貌。如果所有成員又幾乎是第一次才接觸敏捷，再改變原本行為與適應新環境、新流程的壓力下，要同時做好看板，難度更高。所以傾向以教練經驗製做第一版的看板樣貌，先讓團隊有些概念後，時間到了，自然會展出團隊希望的格式。 也許有人會疑問，為何快三十人團隊沒有拆看板或分組? 當然，答案也沒有一定，只有適不適合與要不要這麼做。拆，還需看場地、團隊成熟度、專案特性與專業能力等，取較符合目前成本的方式進行。如真要拆的話，以只有看板方法拆分，也相對單純許多。可以依產品線或職能進行劃分，這又有延伸的議題需要去考慮，之後再來分享。 拉回今天想說的重點，當一個大型團隊有想法要調整看板樣貌時， 該如何讓他們有效的凝聚共識，且能親自動手做出屬於自己的看板格式

【Design your life 工作坊 - 做自己的生命設計師】 做自己的生命設計師 ：史丹佛最夯的生涯規畫課，用「設計思考」重擬問題，打造全新生命藍圖。 簡介：人生是「設計」出來的 第一章：從此時此地 第二章：給自己一個人生羅盤 第三章：找出一條路 第四章：卡住怎麼辦 第五章：自己的人生，自己設計 第六章：打造原型 第七章：找「不」到工作的方法 第八章：打造夢幻工作 第九章：選擇幸福 第十章：萬無一失 第十一章：建立團隊 結語：好好打造生命之後 之前剛好有機會設計這堂工作坊，加上本身也是GCDF職涯規劃師，而這本書又與敏捷精神和設計思考是一致的。所以，就把運用在專案上的敏捷哲學經驗，加在本書提供的思考工具，整理成半天的工作坊，讓大家有機會重新思考、重新設計自己要的人生。 假如剛好正在人生迷途的路上，這本書是有機會協助你做整理，然後重新出發。不過呢，據經驗，能自己閱讀書後，照著步驟能把自己也重新整理一遍的，有這種自省能力的，通常在問題擴大前，已經把問題解決掉了。 所以呢，真的要是遇到瓶頸或問題，可以協助專業諮詢，或者跟好友聊天，請對方以第三者身份對你提問，或者參加類似的工作坊，都能讓你較快速的 自我察覺 到目前自己的身心狀態，然後做出適合的決策。 大部份的問題，其實可以不用到專家，只要請你信任的人，在安靜的環境下，單純的對你提些問題，都會有新的自我發現，對方可以不用回答任何問題，就只要光提問就行了，下次可以試試看。 不管是教練還是引導師，都是先相信，最好的答案一定是在自己身上，而不是別人給的。 以上相同的想法，套用在專案敏捷其實也都是一樣的，對於SM更是受用。 不藏私的說一下工作坊大概流程和本書的重點摘要，有興趣的也可以自己操作囉! 因為此工作坊是針對職涯設計的，所以先大概描述職涯相關的理念。 人生= 夢想 +想像+規劃+行動+意外。 是本書圍繞的重點 夢想是你的人生計劃的起點。 找出真正夢想 夢想，是你人生計劃的起點。它指的不是你「應該」做什麼，而是你「想要」做什麼。你心中真正的渴望是什麼？你想到達的地方是哪裡？除非把它找出來，否則，你很難發自內心做出承諾。而沒有承諾做後盾，隨便一個挫折，可能就會讓你打退堂鼓了。 職業生涯規劃（簡稱生涯規劃），又叫職業

【敏捷觀念 - 使用者故事User Story】 前一陣子替團隊整理了一下，關於User Story的觀念釐清，不小心就做了一百張簡報。 參考網站  Ruddy Lee 、 使用者故事對照 、 如何寫出 User Story 、 不可或缺的精益、敏捷需求實踐 ....，網路上資料很多，但也相對零散，所以需要的話，可以去上CSPO的課程，會有較系統性的資訊，或者去上相關課程也能讓觀念較為完整! 這次主要在做的事，是針對團隊狀況過濾訊息，依團隊目前狀態需要的資訊做系統性整理，大原則就是「夠用就好」。 既然取之於社會(網路)，那我也就用之於社會，回饋一下內容。 簡報內容大致如下： 先講結論，敏捷對於VUCA環境的適應性很大，所以，要跑敏捷前，請先確定好，你們是真的在VUCA環境，而不是為了潮而跑。否則，也只是會精通錯誤的技巧和觀念而已。 先確定好自己目前狀態位置是否適合。沒問題也認同的話，我們再來重新定義一下，對於User Story的想像一不一樣。 請記得一件事，聽一則好故事，是需要時間的。相同的，專案沒有足夠的討論時間與空間，就別太糾結一定要用"使用者故事"。適當的情況下，用正確的規格描述，做出同等價值的產品，這才是敏捷阿! 要用對故事和用對方法，不然它也是會變成隕石的可能。 既然是"故事"，我們就先來看場微電影吧!了解一下，什麼叫故事 - 阿嬤的衛生紙 ， 如果要拆解這故事，我們會用哪些方法來寫劇本呢? 大多數的人在說使用者故事的時候，會卡卡或不踏實的原因，是因為使用者故事本身就是一種抽像的描述，是拿來討論的，也必需是開放思考的描述。但忘了先給這個故事一個情境， 讓它還是在焦點內做發散討論。有時也沒給上下文的想像空間，造成做出來的功能不符，如果最後還沒討論，那就更慘了。 講故事前，請先把構想描繪出來(故事全貌)。 沒錯，就是用影響地圖(Impact Mapping)、使用者故事地圖(User Story Mapping)來做故事情境與上下文。 影響地圖：透過視覺化的方式，建立商業目標與產品功能的關係，以及背後關聯的假設。 使用者故事地圖：透過視覺化的方式，建立使用者場景與技術規格間的聯繫，輔助團隊有效溝通。 那..... 使用者故事 5C原則

【看板方法導入 PART 13 - 第n次回顧會議(期望)】 敏捷的精神是"持續改善"，這代表著流程中，一定有一個步驟是要"檢視歷史"，而且最好是即時且有效果的。如果要有效果產生效益，通常也是要設計一些方法或有技巧的引導，才能獲得最大群體智慧的回饋。 因此，就有人將回顧會議分為五個階段去進行，分別是： 設定會議基調（Set the stage） 蒐集資料（Gather data） 激發見解（Generate insight） 做出決策（Decide what to do） 結束會議（Close the retrospective） 可以 參考這裡 說明，另外也有國外網站好心的整理好許多技巧參考使用 Retromat ( Retromat ) 不過，要是每次都這麼"精實"的跑回顧會議，SM和團隊應該都會瘋掉吧!! 假如以Scrum指南建議的回顧會議時間，「對於為期一個 月的 Sprint 來説，這是一個最多三個小時的會議。 在長度更短的 Sprint，通常所需的時間 更短。 」，這樣算一算二個星期的Sprint最多也是1.5小時內要結束，一個需要燒腦的會議也差不多在1.5小時就會疲勞了，所以要真的跑完還真不容易，有時還會有些倉促感。 所以，建議遇到重大事件時，可以好好的來從頭到尾來思考一下，該如何用系統思考的方式來找出最佳解，這時就很推薦這五個步驟的落實。 回到一般狀況來說，提供我自己的經驗給大家參考囉! 設定會議基調（Set the stage） 這個步驟我會放入平常對團隊的觀察，關注每個事件的發生是否需要深入探討，或者只是稍微引導提醒即可，然後在回顧會議時，刻意的往該事件聚焦討論。也可以用來當作是事前的準備或情境與心情轉折應用。 蒐集資料（Gather data） 可以多多善用這步驟的方法，雖然是蒐集但成員在思考過程中，其實也是讓大家進入反思過程。定義好問題比找出解決方案更重要，這步驟通常也需要花較多時間，也應該要多花點時間。 激發見解（Generate insight）、 做出決策（Decide what to do） 這步驟的結果來自於引導的好壞，如果人多且也引導技巧也不熟悉，建議以工具來進行團