背景資訊
在 2022 年底時，有一個機會和 DDD Taiwan Community 的社群朋友聊天，本來是聊天，但聊到最後變成邀請他來幫團隊帶了幾次 Event Storming。
因為有了當時的經驗，後續順利將這項「引導工具」引入公司、團隊，甚至是客戶端，因此秉持著「取之於社群，回饋於社群」的想法，將自身獲得的經驗，於 2024.02.29 回饋分享至 DDD Taiwan Community。
因為這是一個來自於我個人、團隊及運用在客戶端的經驗談，因此我將主題與內容設定為較軟性的主題「Event storming 是個好東西：幫助團隊看見全貌，引發團隊變革新契機」，主題的簡介如下：
當你想要導入 CI/CD、DevOps 或 OOXXOps 時，你會如何幫助所有的夥伴建立相同的共識？讓大家可以看見相同的全貌及痛點？
當團隊開始重視 DevOps 核心精神中的「交付價值、持續改善」時，我們確實需要一些不同於傳統會議與組織溝通的方法，來輔助不同的部門及團隊打破 silos 共同看見整體流程的完整面貌，畢竟我們都知道 DevOps 從來都不是一條龍工程師自己的事情。
在本次的 Meetup，我將會聊一聊幾個來自真實場景的小故事，分享這段由 Event Storming 所觸發的團隊變革旅程。
內容分享
因為這次分享的經驗都來自於目前任職的職場，因此針對內容有做了一些去識別化，就請容我不公開釋出完整的簡報，下面就以幾張簡報快速說明這次分享的內容。
如前面提到的，這次設定的是一個很軟性的主題，主軸就是想要分享這一段時間以來，基於 Event Storming 得到的一些經驗與學習。
其中，最深的感受就是，Event Storming 是一個很棒的「引導工具」（好東西），這個好東西它好在哪裡呢？它好的地方在於，透過它我們有機會能幫助團隊「看見全貌」，藉此為「變革」這件事，創造一個「契機」。
同樣如前面所述「取之於社群，回饋於社群」，我個人能夠認識與學習 Event Storming，歸功於過去在社群中認識的國昭與 Tim，再次特別感謝他們兩位。
本來 DevOps Taiwan Community 二月底也要舉辦 Meetup，但後來因為原定的講師時間喬不攏，再加上剛過完農曆新年，也不容易臨時安排其他備援講師，最後因緣際會的就跟 DDD Taiwan Community 的組織者 Kim 談定，二月底就由 DDD Taiwan 主辦 + DevOps Taiwan 協辦的方式來結束這一回合，這裡也再次感謝 Kim 接受我的臨時提議。
既然是兩個社群一起辦活動，這次活動的報名者來自兩邊社群，所以特別在暖場時放了上面這張迷因圖。
我想來自 DDD Taiwan Community 的朋友一定都知道 Event Storming 是啥，但 DevOps Taiwan Community 的朋友可能就不一定知道了？（其實大家一定都知道啦，我只是準備在演講開場時，讓現場輕鬆一下XD）
開場丟出來的第二個梗，即是這句來自 Ruddy 老師的經典名言「專案開始之初，首重看見全貌」！
透過 Ruddy 老師的名言，將現場與會者的思考聚焦到「全貌」兩個字之後，緊接著立刻端出第三個梗——「什麼是『全貌』？」
全貌啊全貌，你覺得「什麼是『全貌』」有標準答案嗎？不同的團隊或在不同的場景中，我們需要的「全貌」是相同的嗎？
更近一步追問，如果真的有一個名叫「全貌」這麼重要的東西，是我們一定要去「看見」的，那我們有哪些方法可以用來「看見全貌」？
最後，第三個提問，其實是直接破題，我認為「看見全貌」就是其中一個能夠幫助我們「溝通有效」與「有效溝通」的前提要件。
在這次的分享中，我總共分享了三段經驗談，分別來自三種場景。
- 自己團隊首次體驗 Event Storming
- 我個人抽取了 Event Storming 中的一些手法，應用在團隊夥伴身上
- 我們團隊帶著客戶進行 Event Storming
在第一段經驗中，我認為團隊有了上圖中的三項學習
- 看見專案的全貌
- 發掘容易卡住的瓶頸點
- 認識不同角色的位置
簡單來說，透過 Event Storming，我們順利盤點了過往的專案歷程，當最終我們在會議室的牆壁上呈現出專案事前、事中、事後的所有事件與其中的關鍵產出時，所有的團隊夥伴眼睛都發亮了。
好比探險隊終於拿到了一張標示清楚的地圖；上面不只告訴你會走過哪些路線，亦包含過程中有哪些關卡，哪邊是最容易卡關的天險；另外這份地圖還顯示了，來自探險隊各種不同專家留下的各種專業提示，你能一目瞭然團隊內的每個人各自負責的角色。
在團隊的 Event Storming 首次體驗中，我們強制要求專案的每一個角色都要來參加這場活動，老實說我們也多少有些擔心是否會有夥伴感到反彈，或對活動本身無感、不願意積極參與。
然而最終，整體的回饋都是正面的。
- 業務表示更理解未來可以怎麼協助團隊與客戶溝通。
- 業務及專案經理皆表示自己更理解團隊是如何執行專案。
- 各個工程師也表達透過這個活動，更理解其他工程師或其他角色對於同一個事件的不同觀點。
- 至於老闆，則是嘖嘖稱奇，直接嚷嚷著這活動應該要在每個專案都來一次！這能有效的幫助團隊回顧與整理這些重要的專案經驗、知識與產出。
至於第二段經驗，它並非 Event Storming，而是我個人參考了 Event Storming 的手法，像是「事件」、「按時間軸回顧」、「使用多種顏色便利貼」等⋯⋯，在幾位夥伴離開時，邀請他們以自己為中心，做了一次從到職到離職為止的個人覆盤。
雖然這不是一個 Event Storming 案例，但在幾次經驗中，還是有了一些學習與觀察，其中我有兩個最大的收穫
資訊 / 知識傳遞的瓶頸點、斷層。
我相信很多企業也都有這個議題，不論你在知識管理、知識傳承、員工教育訓練做了多少努力，但總還是有力有未殆或做得不夠好的地方。透過這幾次的經驗，再一次更深的感受到這個議題的重要性。
視覺化是盤點事務的好工具。
將你所思考所講的事物，寫成便利貼，然後貼在牆上的某個位置，並且在過程中調整移動相對應的便利貼位置；這整段動作絕對不是「浪費時間」與「浪費便利貼」，反而是藉由這些動作，能有效的刺激人們不斷思考與整理想法。
最後一段經驗談，來自我們團隊帶著客戶做 Event Storming，比較特別的是這次盤點的場景，是跨兩個不同部門的案例。
可以發現，跟前面的經驗相同，Event Storming 再次幫助我們「看見全貌」；讓兩個不同部門，彼此認識雙方的角色、出發點與觀點差異，發現彼此有共同的困境與各自的困境。
而其中我覺得最美好的是，透過這樣的活動，幫助這兩個部門開啟了對話，這正是我這次分享的副標題「幫助團隊看見全貌，引發團隊變革新契機」。
在這次分享的最後，我整理了六項學習：
你需要不同的方法來幫助團隊「看見」全貌
作為知識工作者，我們需要靠知識的堆疊來產生價值，在這個變化快速、知識大爆炸的時代，傳統的會議方法、傳統的組織溝通很可能會越來越難產生好的效果。想要「有效溝通」或「溝通有效」，我們需要更多不一樣的方法。
當某些不可見的東西被「具象化」之後，看見就有機會帶來一些不同的影響與變化。
好比「發言權杖」，它將「發言權」具象化成為實體，藉此改變了會議室內的溝通方式、溝通氛圍、提升與會者的專注力⋯⋯，當我們嘗試將不可見的東西「具象化」時，也是在創造一個引入變化的契機。
擴大「視野」，避免被困在細節之中。
全貌如此重要，因為它能幫助我們退後 N 步，從細節中釋放出來。當視野轉變之後，你才能看見真正重要的東西。
你想要引導別人，也要別人願意被你引導
引導也不是萬能的銀彈，人依然是一個不易處理的議題。最糟的溝通之一，就是不願意溝通。
變革，並非一條龍工程師自己就能搞定的事情
真的不要再幻想只要請一位 DevOps 工程師就能搞定一切了。
有效溝通基礎之一，大家站在同樣的高度看事情
站在同樣的高度、同樣的起點、同樣的基準線，這都只是對齊大家的基礎而已，不然大家的天線頻道根本沒接在一起，怎麼溝通都是在鬼打牆。
小結
老實說，回顧這幾段 Event Storming 的經驗，我覺得自己是幸運的，從好的老師身上學習、遇到好的團隊、好的客戶，讓這段學習過程有許多美好的體驗。
本來打算多寫一點內容，但在看完筆記女神 Anna Su 的筆記文之後，覺得好像想講的內容很多都已經被寫下來，我似乎可以節省一點墨水，少寫一點。（謎之音：部落格是要啥墨水）
這次挑戰了一個非技術的軟性主題，對我個人而言也是一次自我檢視與自我學習的機會。透過現場的互動、Q&A、收到的回饋意見，其實我自己也很訝異，原來針對這些軟性主題，我在不知不覺也累積了一些經驗與學習。
最後，再次老王賣瓜一次，如果你也有想要讓團隊看見全貌的需求，Event Storming 是個好東西，推薦你不妨也嘗試看看，也許它也能為你的團隊帶來一些「引發團隊變革的新契機」！
