發表文章

目前顯示的是 4月, 2019的文章

看板方法導入 PART 9 - 第一次回顧會議(規則明確)

圖片
【看板方法導入 PART 9 - 第一次回顧會議(規則明確)】 上一次會議停留在" 問題共識 ",對於看板流程中應有的活動框架也規劃好了,但對於活動規則細節還沒有討論訂定。 看板活動階段目前分為六個(視團隊原本開發流程而訂),分別為"開案前"、"開案會議"、"站立會議"、"回顧活動"、"溝通原則"、"便利貼"、"其它",底下貼出要做哪些事情項目,這次要針對項目做具體規則。譬如說,站立會議要怎麼報告、規格確認的定義、便利貼要有哪些訊息和怎麼使用顏色...等等。這些都算是"優化",因為團隊先前已經進行過二個星期看板經驗,這次討論起來有更多想法去做回饋、修正。 這次會議聚焦在每個活動項目必須都明訂規則,然後依序落實,大致流程如下 ●分組討論主題 ●針對目前海報上便利貼,如果描述不夠清楚,重新寫下具體寫出行動或規則(人、事、時、地、物),順便補上建議的規則 ●觀看各組討論,並給予經驗建議 ●各組分享 ●各自投票,一人多票,決定接下來要聚焦執行項目(運用Design Sprint其中之一的概念) ●選出最高票前三項,依序落實執行(每個月輪流換項目) ●最後用PDCA來收斂過程,提醒大家要記得持續改善 結論: 團隊問題一定是團隊自己最知道怎麼解,只是需要先被教練協助釐清問題。當團隊自覺到問題後,自行提的方案一定又比顧問給的適當有效,且更樂意自我改變。只需要引出好奇心,再加以引導發覺,團隊投入、參與度會比一直被逼迫的高,且越往後走,越容易養成自我改善習慣。 看板是建立在原有開發流程與習慣上面,再去發現瓶頸改善進而提升效能,也就是說,如果原本習慣(體質)不好的話,建議初期先投資時間調整體質再來進行。從實體看板(開啟改變)→看板方法(有效應用)→看板系統(優化提升),一步步建立囉。 上一篇: 看板方法導入 PART 8 - 第一次回顧會議(問題共識) 下一篇: 看板方法導入 PART 10 - Daily 迭代(觀念、行為、習慣、態度...等非認知能力提升)

看板方法導入 PART 8 - 第一次回顧會議(問題共識)

圖片
【看板方法導入 PART 8 - 第一次回顧會議(問題共識)】 上一篇主要以問題蒐集為主,團隊累積一定數量的任務單與經驗後,開始利用這些過程經歷反應凸顯出已經存在已久問題。而看板目前也只是輔具工具,藉由它來開啟一連串的對話與討論,把體質先調整好,再來好好發揮看板應有效果。 有了一堆反應結果,怎消化又是一門學問,也需要團隊投資這時間成本,引導大家發覺,沒錯,這確實是目前團隊問題,有了這層共識後,也才好針對這些問題提出解法,並在看板搭配運用,定出六個核心實踐中的" 讓規則明確 "、" 管理工作流程 "。 所以,又另外拉了2個小時的問題收斂活動,以下提供大致流程 ●開場介紹 →愛因斯坦:「一直重複做相同的事情,卻期待會有不同的結果。這應該是瘋子。」,說明現況 →愛因斯坦:「每個人都身懷天賦,但如果用會不會爬樹的能力來評判一隻魚,牠會終其一生以為自己愚蠢。」,說明我們都用錯誤的方法 ●針對上次回顧會議蒐集的O與R進行收斂I與D →教導大量資訊情況下,如何進行有效思考收斂,讓大家進行20分鐘的獨自思考練習, →使用"關係流程圖"自行解讀並摘要關鍵元素,看看哪個元素被關聯最多 →把每個人的關係流程圖貼在ORID收斂海報旁,彼此分享觀看 →統計相同關鍵元素次數 →系統思考,依序把"現象"、"結果"、"事後"、"行動"相關的O,貼在相關位置底下,最後把四個狀態連接起來,用來表示目前的惡性循環,都是在錯誤的基礎下做出錯誤的決定 →最終結果D, "認知、資訊的落差"、"時間管理"、"消除浪費(技術提升、自動化、品質)" →釐清真正要解決的問題根源,有了這些共識,再來進行看板規範討論 ●看板流程收斂 →上次回顧會議各組討論的看板海報內容,用時間軸,匯整成一張 →分三組(每組約4-5人)討論六個看板相關議題"開案前"、"開案會議"、"站立會議"、"回顧活動"、"溝通原則"、"便利貼&quo

看板方法導入 PART 7 - 第一次回顧會議(問題蒐集)

圖片
【看板方法導入 PART 7 - 第一次回顧會議(問題蒐集)】 看板方法中沒有定議回顧會議,所以取用Scrum替團隊定個正式會議,提高重視度做好每次的檢視與改善。看板方法中也沒有Sprint衝刺期,那要如何規定一個時間呢? 時間視團隊和專案狀況來開會囉! 如果團隊是既有產品持續維運的話,看板欄位中的上線欄是個好判斷點。當它被貼滿或一定數量時,就表示該來清一清回顧一下。透過回顧會議把上線欄位中的便利貼做一波整理,檢視、討論、調整做經驗回饋修正,讓團隊經驗越來越好。 當然,團隊如果是新創或是特殊任務型(通常看板較適合一直持續的長期任務),有需要時就拉個會議特別檢視一下,每個團隊都有自己的步調與節奏,倒也不用特別被拘束,也或者可以不用有回顧會議,但要記得回頭檢視就好。 記得,六個核心實踐之" 落實回饋 "、" 由協作改善,經實驗演進 "。 第一次的回顧會議,最好是在執行看板後的2~3星期,大家對於看板至少有一定概念與經驗,加上累積一定量TASK便利貼,搭配一起描述,會讓問題描述能更具體,以便於修正出屬於團隊的看板方法。也就是六個核心實踐之" 讓規則明確 "、" 管理工作流程 "。 所以,這次的回顧會議主軸是: 透過描述任務單過程,定出規則與工作流程。 第一次開會地點盡量在看板面前,讓環境與討論是融入的,如當下有任何看板的反應問題,也都能馬上指出來說明。 以下提供大概的步驟 ●任務回顧檢視 - 使用ORID →請大家先來認領上線欄位中自己的任務單 →底下聽的人分二組,一組用O(黃單),一組用R(紅單)分別紀錄 →每個人講完就到ORID海報底下貼上位置 →中間如果有講到看板相關,需要做觀念引導,別人講完後,主持人再上去補充說明 →全部講完後,休息時間,請大家把I 、D補上 ●看板規則討論 - 使用world cafe討論方式 →延伸回顧會議的想法與改善,放到看板應該要有的流程、元素、規則、問題處理...等等 →分四組(一桌長一副桌長,組長與EP,不動) →輪三次,主題分別為:流程、元素、規則、問題與整合 →最後一次輪桌,請大家畫上時間軸,把剛剛討論的貼到相對應位置,並補上不足夠的活動

看板方法導入 PART 6 - Daily 迭代(資訊與認知落差)

圖片
【看板方法導入 PART 6 - Daily 迭代(資訊與認知落差)】 每天的站立會議與看板創造了一個很好互動、溝通的參與式合作場域。 在大多的專案開發情境下,通常都是有事(不管大小事)、有需要才特別拉一個會議,邀請相關人來參加討論,勞師動眾,且到那個時候,都已經累積不少要討論的事項。如果沒有一定的經驗主持,讓會議進行有效討論,結果都是又臭又長,大家就開始排斥開會。更糟糕的是還沒有結論,會而不議、議而不決、決而不行,相信大家對於會議慢慢就敬而遠之,遑論說要好好坐下來討論了。 如同地震,有多次小震來釋出能量,才不會久久才來一次大震,嚇到不知所措。而所謂的地震,在我心中,如同「資訊與認知的落差」,這落差越大,釋放出來威力越是驚人。既然有了每天的站立會議,那就好好來善加利用,別讓這落差越來越大。 套用引導學一書中對"問題"的定義:「 所謂的問題就是期望與現實間的差距。 」 在專案開發中,我想,應該有六、七成以上的問題就是這個了。尤其是跨越多部門越嚴重,你腦中的期望、我腦中的想像、他手中的項目,常常有機會是不同的。 所以,我們來好好利用這短短的15分鐘,發揮8*60=480分鐘的價值,讓今天都在正確的軌道上。 在剛導入看板方法初期時,我會在Daily後做三種訊息(10分鐘內): ●專案、跨部門資訊同步、變化跟上計畫 ●看板方法相關知識陸續導入 ●行為、觀念應用 [專案、跨部門資訊同步,變化跟上計畫] 所有資訊每天重新校準一次,並做上即時對應改變,降低專案的風險與成本。如果無法在Daily中討論、釐清,也能在Daily後馬上安排相關人員做詳細討論與對策。 [看板方法相關知識陸續導入] 看板方法如果允許且有時間的話,盡量一點一滴的進行變革,讓大家慢慢感受到改善變化,而不是被滿滿不確定、不安感失焦佔據。一口氣大量新資訊進來,並立即應用在專案上,大多是來不及消化而排斥,也容易錯把焦點放在未知項目。把看板元素做拆分,例如: ●基本欄位開發價值流 ●便利貼、看板排版 ●便利貼資訊 ●Daily討論的型式 ●便利貼流動與問題敏感度培養 ●看板的規則、規範 ●WIP ●看板整合 每個元素的導入,都會有一些困惑與屬於這團隊的應用。依序才能清楚看到問題,對症下藥才有效,否則容易被複雜化看不見問題根源,反而不

看板方法導入 PART 5 - Daily 迭代(時間管理)

圖片
【看板方法導入 PART 5 - Daily 迭代(時間管理)】 初期導入看板或Scrum時,最好運用的時間就是每天站立會議時間,雖然只有短短15分鐘左右,但我都會細心觀察團隊資訊內容、遭遇的事件、相對應處理動作,來做為觀念或行為強化或引導。 比方說,有人反應TASK上面看不出關鍵日期,不確定有沒有壓線。 觀察到此反應後,就會運用Daily完後的五分鐘說明。如果需要,可以加上日期來判斷,但Task都是親自寫上,理論來說,當事人會最知道哪些關鍵日期快到,需要注意提醒,每天會議應該也會互相提醒。當然,加會比較好,但有機會還是會透過問句來讓大家反思。 一開始進行看板時,都會使用最簡單、基本滿足就好的規則和欄位,由團隊遇到問題後,慢慢思考然後自行加入。這有幾個重點, 一來是,既然有需求要導入看板,想必團隊狀況可能呈現混亂狀態。所以一開始用「減法思考」方式來進行收斂,也就是用最小原則執行看板。當不足時,再來討論思考是否加入規則。因為「 加法思考 」對於大腦相對容易處理,「 減法思考 」則需要多花幾步去思考原因,才能決定該如何刪減動作。 二來是,讓團隊親自動手創造出屬於自己的看板方法,會提高認同度,進一步積極參與改善流程。 以上概念簡化說,其實就是善用站立會議所觀察到的反應,持續做改善。 上一篇看「 板方法導入 PART 4 - Daily 迭代(消除浪費) 」,而這篇主要焦點在「時間管理」,站立會議除了 專案資訊同步→重新計劃任務 以外,還可以做體質調整,有了正確觀念和習慣,看板才能發揮更大效益。 先列一些實際情境會反應的時間相關問題: ●開發進行中的TASK是只有今天?還是所有開案後的? ●已經做完的任務,但一個月後才要上線? ●零散的工作項,但會佔掉很少時間是否該貼? ●覺得目前效率有受到影響,因為每天要Daily花時間 ●開會是否也要貼上TASK單? ●TASK在開發欄位停留太久? ●TASK在自測欄位停留太久? ●看不出任務單要花多少時間做? ●順手做掉的事情是手要貼? ●看板上無法呈現工時表現 ●時程不合理 ●會議太多沒結果 ●看板需求單不容易搜尋 以上有些是看板、有些是現況反應、有些是問題,即使這樣,我們還是要非常清楚知道,看板能處理什麼,不能處理什麼,可千萬不要覺得套入看板,萬事OK。 透過

看板方法導入 PART 4 - Daily 迭代(消除浪費)

圖片
【看板方法導入 PART 4 - Daily 迭代(消除浪費)】 豐田汽車副會長-大野耐一,創造了「 豐田生產方式(TPS) 」: 是提高企業生命力的一整套概念和方法的體系。它是豐田公司通用的製造方法,其基本思想是"徹底杜絕浪費",通過生產的體整化,追求產品製造的合理性以及品質至上的成本節約。 TPS涵蓋即時性(JIT)、自動化、看板方式、標準作業、精益化等生產管理。 其中豐田的浪費指的是以下七項: ●運輸 (把原本沒有必要的物資運送到生產流程中) ●庫存 (所有零件、半成品和成品在儲存中的浪費) ●運動 (人員和設備搬來搬去,超過生產必要的人員走動) ●等待 (等待下一個生產環節) ●生產過剩 (生產比需求多) ●多餘加工 (來源於設計問題、生產工具有誤產生的復工) ●瑕疵 (耗費了參與檢查和修復瑕疵的投入) 既然我們在資訊業跑的看板方法是來自於豐田,也確實成功改善並運用在許多公司,那就要先對"浪費"有些概念,套用到資訊業會是怎樣的情境,才能讓我們從容應對看板導入團隊時,有可能會產生的任何問題。 轉換一下上面七項浪費變成資訊業的語言,大概就是 佈署、半成品功能、來回無效溝通、需求定義、Bug、分析、等待、不必要的流程 。有這些概念後,再來對應到實際看板導入過程來消除浪費,藉由每天的Daily來培養對問題的敏感度。 提供實際反應過的問題給大家參考: ●DB開發分析做完後怎辦? ●零散的工作項,佔的工時很小,是否要貼TASK任務單? ●為何整合欄位一堆單,都沒進入到自測狀態? ●有組別開發欄位是空的? ●提前做完,離上線還有一段時間的需求單放哪? ●自測欄位的單子停很久? ●開發欄位單子停很久? ●有張任務單不曉得現在狀態在哪,該放哪邊? ●需求單從完成欄位又被拉回來開發狀態? ●一直停留在追蹤狀態? ●如果分析完後的任務單,不用上線也沒有後續發展,如何處理? ●看不到環境、佈署狀態 ●驗收狀態停太久,中間有問題卻沒在Daily反應,反而是在回顧會議提出? ●開發欄位滿出來? ●待確認需求單與開案中需求單的定義? ●欄位間的流動似乎不順暢,彼此等待的時間影響? 以上問題視看板的欄位還有團隊原本的開發狀態而不同,但背後反應出來的本質差不多。 那&

看板方法導入 PART 3 - 第一次Daily

圖片
【看板方法導入 PART 3 - 第一次Daily】 團隊看板建置完成後,開始要來驗證看板作用,但看板方法裡面其實也沒提到Daily這種會議。所以我們取用Scrum的Daily Scrum來落實看板六個實務。 ●視覺化 ●限制半成品WIP ●管理工作流程 ●讓規則明確 ●落實回饋循環 ●由協作改善,經實驗演進 透過每天站立會議來把團隊原本就存在的問題,一一浮上檯面,再透過視覺化看板,進一步去思考該如何改善。原本抽像且僅口頭討論的資訊,搭配視覺化看板,一切變得很聚焦,讓所有人都容易進入看板情境思考。 但這種聚焦初期有二種反應, 一種是正面的,會建立在看板基礎之上,思考該如何搭配運用,才能把症狀減緩、克服 另一種是負面的,則用挑戰的心態一直放大檢視看板,不能這樣改、那樣做、解決不了問題....等等。 負面的反應,運用恰當的話,可以借力使用,讓大家對看板更加信任,所以不要太排斥或否定每個帶有情緒的回饋。好好正面思考該如何讓扭轉觀念,讓背後真正要解決的問題探究出來改掉。 如果反應的人很多且情緒激動,那要回頭想一想,前置作業做的夠不夠充足,大家理解狀況有沒有一致,是否該再把看板方法或團隊狀態再交錯檢視一次,把遺漏的部份再次補齊,再來重新起動看板。 我們只要先有個心理準備要面對這樣的狀況就行了,其它就見招拆招。 實際上,看板其實倒也不會反彈太大,反而是每天的站立會議讓人反感。這也是工程師本身習慣和文化的關係,工程師一般來說,是習慣每天都黏在位置上面工作,有任何事情就用電子化或電子溝通方式,多一事不如少一事,已經是突破原本的舒適圈。況且工程師也都自認為已經把事情同步交代好,為何還要特定在固定時間重複做一次? 沒錯,這就是「罰站」,要先好好思考這感受該如何消除。我們來重擬一下「罰站」這無效想法,轉換一下「 我們如何有效運用短暫的資訊同步時間來改善我們的問題? 」 在實際情境中,說也奇怪,當罰站這感受消除後,變革的門檻也就過了一半以上,開始願意去多思考、多嘗試不同的方法。所以,可以把這當做一個檢核的依據,也是心態改變的開始。 來說說該如何好好運用每天早上15分鐘左右大家共同聚集時間。以教練身份,歷時一個月,就陸續列出執行過程所發生的情境囉!! 轉變過程,從每天1小時到最後每天15分鐘內開完。分二次討論,組長和組員(10分鐘)、