看板方法導入 PART 14 - 看板蛻變與進化(Design Sprint)工作坊

【看板方法導入 PART 14 - 看板蛻變與進化(Design Sprint)工作坊】

人們對於一件全新的領域或知識，當有一定的熟悉度後，就會開始產生一些想法，想去嘗試對目前現狀做出些不一樣的改變。以「守、破、離」三學習階段來描述，是最適合不過的形容。

「守」，就是完全遵守教條；

「破」，要你重新設定以往學到的東西；

「離」，才能脫離過往，確立自己的風格。

對於一個團隊，經過九個月的看板方法洗禮，會有兩種反應，

一、習慣於現況，沒有想特別想法。

二、團隊成員開始自發性的表達，想要對目前的看板做些調整。

第一種狀況就需要客觀看一下，是趨於穩定還是淪於流水型式。如果是穩定的話，倒也不是什麼壞事，不一定特別要做出些什麼改變。反之，就需要反思一下目前到底發生什麼狀況。

可以從結果、產出來反推是穩定還是流水。

當團隊發出第二種訊息時，表示團隊要從震盪期(Storming)進入到規範期(Norming)，是最好重新檢視看板的時機；如果是強推改變，通常都不會有意願與沒動力想去調整。當然，如果教練或主管已經早就嗅到這機會，缺臨門一腳的話，可以多製造(挖坑)不同的觸發點或加深痛點，讓團隊自己提會是最好的方式。強求總是不會幸福的。

先前的幾篇看板方法導入，都是以「守」的方式漸進提功相關敏捷知識，應用在專案執行上，讓團隊慢慢吸收消化。而第一版的看板樣貌，也有很大的可能是由教練以經驗值直接提供適合目前團隊的看板格式，尤其是在大型團隊(快三十人)，就不好共識出看板樣貌。如果所有成員又幾乎是第一次才接觸敏捷，再改變原本行為與適應新環境、新流程的壓力下，要同時做好看板，難度更高。所以傾向以教練經驗製做第一版的看板樣貌，先讓團隊有些概念後，時間到了，自然會展出團隊希望的格式。

也許有人會疑問，為何快三十人團隊沒有拆看板或分組?

當然，答案也沒有一定，只有適不適合與要不要這麼做。拆，還需看場地、團隊成熟度、專案特性與專業能力等，取較符合目前成本的方式進行。如真要拆的話，以只有看板方法拆分，也相對單純許多。可以依產品線或職能進行劃分，這又有延伸的議題需要去考慮，之後再來分享。

拉回今天想說的重點，當一個大型團隊有想法要調整看板樣貌時，該如何讓他們有效的凝聚共識，且能親自動手做出屬於自己的看板格式呢?

沒錯，就是用設計衝刺(Design Sprint)，不僅能獲得團隊智慧的結晶，且在過程中就動手做完得到產出。

不過礙於時間限制，所以刪減與調整原本Design Sprint的步驟，讓流程能夠符合目前團隊狀態去設計。

先來看看活動後大家部份的回饋，

1.我們今天學習到什麼?未來可以應用在哪個地方?

2.你會如何描述我們這半年來的敏捷過程?

3.未來我們還可以做些什麼強化/改變來持續成長?

  ●集思廣義、專案開發上。

  ●同理的重要。

  ●HMW，用在會議上。持續成長。讓成員更有參與感。

  ●學到HMW。

  ●發散討論在收斂可得到更多想法。

  ●對於專案開發流程可以更聚焦想法。

  ●運作了一段時間的看板，收斂的訊息反饋可以幫助了解目前工程流程的問題。

  ●解決問題就是了解現況，不帶情緒才能思考出答案。Change、包容、優化。持續收集問題和優化。

  ●發現問題解決問題。

  ●守為主，破離還沒。

  ●從不看好看板到希望它更好，它可以讓單位更好!

  ●自己參加外面的工作坊。

  ●學到運用群體智慧來探索問題以至於解決方案。可以運用到未來的團隊改善規劃。

因應時間與主題，有做項目的調整，大致流程如下，

●破冰 - 即興力的"關係雕像"，用來隱喻彼此應該要用YES，AND的精神，來支持對方的想法，也許或會得不一樣又驚奇的結果。

●分組，每組5~7人左右，每組人員盡可能多元，如果有像官方建議的Designr*2、Enginner、Prototype、Sprint Master、Researcher會更好。不過這次是以看板為主題，所以每組簡單分企劃與RD。

●Design Tinking/Sprint簡介

●Design Sprint步驟 - 有遵守大原則「理解目標」、「分開發想」、「選出最佳」、「製作原型」、「用互測試」，時間關係有做些調整。

●理解目標 - 

    *組內各自分享目前看板的想法，其它聽著人使用同理心地圖來紀錄。

    *各組討論出目前看板的流程示意圖。

    *同理心地圖的便利貼分群後，再請團隊成員利用"我們該如何How might we(HMW)"替分類的便利貼重新擬定問題的描述。

    *再把HMW對應到示意圖位置

●分開發想 - 

    *獨立思考HWM的解法(如果需要的話，可以適時的先補上一些資訊，讓團隊成員有概念可以發揮或尋找)

    *Light Talk，各自介紹自己的點子，其它人可以用便利貼寫下、補充有興趣或不錯的觀點。

●選出最佳 - 

    *每人兩票，投票前要先說明原因

    *整合最佳解到示意圖

●製作原型 - 從同理心地圖、HMW、方案圖、示意圖統整希望看板的格式與規則

●用戶測試 - 

    *請各組人員交換2~3成員來驗證一下設計好的看板，獲得回饋後再回去重新調整

    *再次合併各組的看板

【後記】

帶完工作坊後，再去觀察團隊狀況，大家似乎都重新加滿油，活力滿滿自發性、積極的做討論與改變，很快就落實到現在看板上做嘗試與修正，親手做出來真正屬於自己的看板。

最後稍微列一下9個月來，同理心地圖的內容

●容易管控開發狀態

●專案名稱不統一，進度沒法追蹤

●紅黃藍單連結度不高

●統一格式可以好理解

●積極度提高

●單子需要統一

●便利貼敘述內容要訂統一格式

●單上名稱不一致導致查看困擾

●看板可以幫助人員工作時程安排不會亂

●便條資訊資訊雜亂

●看板欄位不符需求

●便利貼不夠同步

●外單位插件看板不能顯示完全

●插件可但見但未解決

●掌控度變高，有固定時間可以交流

●協查類型工作無法反映

●新人看板不了解

●新人對於看板使用疑惑

●外單位交辦事項未列入看板

●外單位協辦預定項目未列入

●專案時間長看板太固定

●大案導致看板死水不動

●需要其他單位加入看板活動，獲得資訊同步

●未能體現大專案重要性

●部門目標未與看板做連結

●組內自主提高

●聽到其他產線的反饋，並未有效反應實際工作狀況

●想要大家從中思考如何優化工作流程發現更多問題

●有助於工作提升，降低工作干擾

●大案一貼就是一個月

●工作項目代在workflow裡太久

●再更細分工作內容才有效益

●企劃項目需細化

●企劃的單位有WIP有改善空間

●快速了解今日工作

●工作項目較清晰，需求以外的項目未反應在看板上

●RD優化自我提升

●看不出下週整體工作

●需求很雜，看板可以視覺化看出其他人力是否可以分配支援

●覺得對自己沒什麼幫助，對於主管或PM可以掌握時程

●工作內容&人力資源透明化

.....

大部份都不是看板該解決的，但透過看板方法，反應出很多未來可以更好的現象，讓開發端人員不僅僅只面向coding優化，更有機會從已經視覺化的工作流程，讓原本難以溝通的議題變的輕鬆，也能進一步做系統思考，找出最小槓桿解，讓整體開發達到最大效益。

上一篇：看板方法導入 PART 13 - 第n次回顧會議(期望)