Event Storming 可以幫助我們解決溝通與學習的問題，但一場需要激烈討論的會議要舉辦起來也並不是那麼地簡單。如果沒有達到幾點關鍵要素，那你將花掉的是跨團隊間的時間，成本不小。
本篇我將從反向案例來看，一場失敗的 Event Storming 會出現哪一些問題，接著再聊聊一些可以做得更好的細節。也歡迎大家給我回饋。
Event Storming 非常地耗費心神，所以很容易在不知不覺的情況下走偏。當遇到以下情況時，不管你身兼何種角色(主要是主持人)，都必須公開提出來讓會議導回正軌。
Event Storming 最原始的目標就是將領域專家腦中的想法具現化出來，讓在場的開發人員更好地吸收，甚至回饋。這邊不需要嚴格到程式設計的精準性，也不可能立即把所有的 Hotspot 都給解決。
所以這時候如果與會者的背景多元一些，就能多一些決策依據。比如領域專家可能只做商業決策，但對於客戶的理解不如業務，又或者對於串接外部系統的複雜度不如開發者。
當你發現這個問題已經討論了快半小時還未果，那可能這個問題不適合在這場會議解決。標記他，記錄討論的內容，待幾天後再回來。
Event Storming 不是開發產品的 Brain Storming。
當 Event Storming 變成個人秀時，就失去了原有跨領域學習的優勢。另外由於與會者彼此間的個性差異、又或者公司內的階級制度使然，甚至單純是總是有部分人更了解整個商業流程，有時候尤其是沒有太多經驗或自信的與會者可能會不敢自己做決定，反而事事都要問那些比較有聲音的人，或更糟地有一個委員會小團體決定這是否可以貼上去，這在無形間就違反了 Event Storming 的本意。
Event Storming 最大的優點之一就是打破團隊間的穀倉效應，讓知識不在各自掌握在手中，而是共同匯聚起來完成產品。
當你對於你手上便利貼的敘述不夠自信時，請不要怕，先貼再說。同時主持人也可以多多鼓勵大家先動手再討論。待到整合階段時，再一一檢視每一張便利貼。很多時候，不同的意見與想法反而可以找出系統潛在的問題或機會。
同時也很常發生一個場景，就是在探索階段有兩人一直互相問答，這樣一來，問答一旦拉長，很容易吸引其他人的目光，導致漸漸變成大家聽兩人的對話。記住，Event Storming 並不是一場圍繞著領域專家、以他為依據的活動。我反而認為，每一個人的平均發聲量才是評量一場 Event Storming 成功的標準。
在避免鎂光燈聚集在那些懂很多的人身上時，有時候也會發生一些懂很多的人不願意交流，認為之前他們都開會好幾遍，資訊都寫在文件裡面了啊，在這邊重講一遍很浪費時間。但事實上， Event Storming 本意是為了開發者的知識理解。畢竟對開發者而言，看 Spec 非常無聊且吸收效率很糟。
身為一名開發者，看到商業流程就會自動轉換為程式碼也是再正常不過了。甚至有時候看到「幾乎不能相容」於現有系統的商業流程時就會開始慌了手腳，想將會議暫停。
首先，我認為開發者如果能夠提出如「開發成本過高」等建議的確是實用的，但還是要先首重於先理解領域專家腦袋中的構想圖。我相信當開發者能夠看到更全面的商業模式後，自然可以在下一階段提出每個流程哪隱含的成本供領導層決策。
另外，當開發者開始進入細節要畫出 UML、快取、資料庫等等術語時，就相當程度地忽略了一旁的非技術人員。當人們發現自己無法加入話題時，自然參與的熱情就會下降，讓團隊交流的意義消失。
這點有可能是在 Event Storming 導入初期容易被受到質疑的地方。考量到不同人的體力狀況，要大家久站這麼長時間是一個不小的挑戰。我的經驗是，如果今天是開實體會議，那請還是務必遵守。
因為當你中間擺了張桌子，一來不便於走動，二來大家之間的距離又被凸顯出來。而椅子方面，對於一個要一直走動貼便利貼的活動來說，坐著這件事就是最大的殺手，一旦有位子坐我幹嘛站著？那這樣能夠「風暴」出的豐富性就會大打折扣。
我的建議是，可以適時地安排休息時間，讓大家能夠適度休息。但時間到了，務必要在有效率的時間內完成會議。
以下我會介紹一些我個人實作上踩過的雷與建議：
我非常建議大家不論是手繪還是列印，將各種便利貼的用法做成海報(或國軍小卡)張貼出來，讓大家可以第一眼就看到。
一來，可以減少你講解的時間，二來也可以減少事後跟別人解釋的時間。很多時候，即使是第一次參加的人，你都會訝異於他們學習如此的快速，很多時候你只需要點出某便利貼的關鍵特性，大家就可以很快地舉一反三，甚至找出你沒有想過的可能性。
前面提到，問問題在前期的探索階段會影響到 Event Storming 展開的效率，此時有一張圖示在那邊不但增加效率，同時也避免大家誤會便利貼的用法。
在 Event Storming 這場色彩遊戲之中，可能有些人因為色彩辨識比較不敏感，而難以加入會議。因此，在便利貼的一角加上一個可以區分類型的小圖標，可以讓大家更自在的溝通。當然，這也可以畫在你的圖示海報上，讓大家看到。
當你前幾個階段將大致的 Event 都標記上去後，你可以考慮用一個有色膠帶將畫面中特別重要或是關鍵的 Event 貼上標記起來，讓畫面分為數個空間，這樣有助於討論時一次聚焦在一個區段。
要當一名稱職的主持人並不容易，要隨時注意現場的狀況。尤其是一開始，大家還很沈默怕犯錯的，這時候主持人可以試著多問問題來引導大家。甚至，你不需要當一個「聰明」的人，問一些明顯的問題、貼一些可能有點問題的 Event 都是破冰的好方法。當然，如果你是老手，你也可以透過類似的手法引導大家。再次重申，Event Storming 不在於追求完美，而在於碰中出火花。
我們在乎的是溝通的過程，而非把成果放到美術展覽。
尤其注意那些聲量過大或聲量過小的與會者，盡量去搭起兩者間的橋樑，讓會議更平衡一點。很多問法諸如「如果這邊出錯會怎麼樣？」、「這件事總是會還是偶爾發生嗎？」、「這個 Event 發生前有什麼必要條件嗎？」，甚至用倒敘法將事件回朔也可以。
再來，雖然可以讓大家多多發揮，但主持人必須堅持 Event 在「過去式」的使用法則。因為這種用法並不是十分地直覺，有時即便是老手也可能犯錯，這時主持人要幫大家做品質把關。
最後，時間控管是主持人最重要的工作，所以這邊我不太建議主持人身兼領域專家。通常領域專家常會陷入討論的戰火之中，甚至還有些意猶未盡。這時候主持人要注意會議的時間，將一些明顯進入死結的問題先懸置起來，讓大家可以繼續往下討論。但有時候想要插入一個話題需要藝術等級的手法，因此使用個計時器，應用類似番茄鐘的計時法則可以幫助你在時間到的時候，自然地停止話題。
雖然說 Event Storming 沒有主角，但領域專家的確是整場會議的關鍵元素之一。主持人在事先籌劃時必須與領域專家達成共識，那就是領域專家是來解惑的不是製造疑惑的。領域專家在會議前也必須針對主題做調查，或是寫出幾份實際案例讓自己了解可能的使用情境。
領域專家必須要有自我意識，而非現場挑個人當。
在這裏，領域專家也可以考慮走 BDD 常用的 Spec By Example 的 Given When Then 語法，將業務規則的前因後果都寫出來，有助於自己理解。
Event Storming 的精神在於「溝通」與「學習」，為的就是讓開發人員可以更好地理解商業需求，同時也順便讓領域專家找出自己的盲點。
總結本篇，我認為有以下關鍵要素來衡量一場成功的 Event Storming：
iThome鐵人賽
看影片追技術