การจัดเวิร์กช็อป Event Storming

ห้าบทที่ผ่านมาเราคุยกันเรื่อง “สัญลักษณ์” และ “ไวยากรณ์” ของ EventStorming มาเยอะแล้ว แต่ความจริงข้อหนึ่งที่ Brandolini ย้ำเสมอคือ เวิร์กช็อปที่ล้มเหลวส่วนใหญ่ไม่ได้ล้มเพราะคนเข้าใจสัญลักษณ์ผิด — มันล้มเพราะ “การจัดวง” ไม่ดี ผิดคนมาประชุม พลังงานตก ลงรายละเอียดเร็วเกินไป หรือมีคนคนเดียวยึดปากกาไว้คนเดียว บทนี้คือคู่มือภาคปฏิบัติ: เตรียมยังไง ดำเนินยังไง และจะกันกับดักที่ทำให้วงพังได้อย่างไร

ใครต้องอยู่ในห้อง — “คนที่มีคำถาม เจอคนที่มีคำตอบ”

หัวใจของ Event Storming สรุปได้เป็นประโยคเดียว: เอาคนที่มีคำถามมาเจอคนที่มีคำตอบ ในห้องเดียวกัน เวลาเดียวกัน ถ้าขาดฝั่งใดฝั่งหนึ่ง เวิร์กช็อปก็ไร้ความหมายทันที

Domain expert ตัวจริง — คนที่ทำงานนั้นจริงๆ รู้ว่าเคสประหลาดเกิดตอนไหน รู้ว่าอะไรพังบ่อย นี่คือคนที่ “ขาดไม่ได้” ที่สุด ถ้าไม่มี expert ตัวจริง สิ่งที่ได้จะเป็นแค่ “การเดาของทีม dev” ไม่ใช่ความรู้ของ domain
นักพัฒนา (dev) — คนที่มีคำถาม เพราะสุดท้ายต้องแปลความเข้าใจนี้เป็นระบบจริง
PO / UX / คนออกแบบบริการ — ช่วยเชื่อมมุมธุรกิจกับมุมผู้ใช้ และช่วยจับ โอกาส ที่โผล่ระหว่างทาง

ขนาดกลุ่มที่เหมาะกับ Big Picture EventStorming อยู่ราว 6–10 คน มากกว่านั้นวงจะคุมยากและบางคนจะกลายเป็นไม้ประดับ น้อยกว่านั้นมุมมองก็ไม่หลากพอ เคล็ดลับของ Brandolini คือเชิญคนจาก “หลายแผนกที่ปกติไม่ค่อยได้คุยกัน” เพราะรอยต่อระหว่างแผนกมักเป็นที่ซ่อนของความเข้าใจผิดที่แพงที่สุด

🍔 ตัวอย่างฟู้ดเดลิเวอรี: ใครควรอยู่ในวง

ถ้าจะ storm ระบบสั่งอาหารเดลิเวอรี คนในห้องควรมีทั้ง คนดูแลฝั่งร้านอาหาร (รู้ว่าทำไมร้านบางร้านไม่กดรับออเดอร์), คนดูแลไรเดอร์ (รู้ว่าการจ่ายงานจริงติดขัดตรงไหน), ทีมชำระเงิน (รู้เคสคืนเงิน) และ dev ที่จะสร้างระบบ พอทุกฝ่ายมายืนหน้ากระดาษเดียวกัน คำถามอย่าง “ยกเลิกหลังจ่ายเงินแล้วคืนเงินยังไง?” จะโผล่ทันที — และนั่นคือทองคำ

เตรียมของ: กระดาษยาว Post-it และ “ห้ามนั่ง”

Event Storming เป็นกิจกรรมที่ใช้ร่างกาย ไม่ใช่แค่สมอง วัสเหมือนึงถูกออกแบบมาเพื่อ “ปลดล็อกพื้นที่คิด” ให้ไม่จำกัด

กระดาษม้วนยาวติดผนัง (unlimited modeling surface) — นี่คือกฎที่สำคัญกว่าที่คิด กระดานไวท์บอร์ดมีขอบ พอเต็มคนจะเริ่ม “ลบของเก่าทิ้ง” ซึ่งฆ่าความคิด กระดาษยาว 5–8 เมตรบอกกับทุกคนเป็นนัยว่า “มีที่พอเสมอ เขียนมาเลย”
Post-it หลายสี — ตามชุดสัญลักษณ์ที่เราวางไว้: ส้ม = Domain Event, ฟ้า = Command, เหลือง = Actor และ Aggregate, ม่วง = Policy, เขียว = Read Model, ชมพู = External System, แดง = Hotspot เตรียม สีส้มไว้มากที่สุด เสมอ เพราะ event คือสิ่งที่จะเกิดเยอะที่สุด และเราอยากให้ทุกคนเริ่มจากการยิง event ออกมารัวๆ
ปากกา Sharpie หัวใหญ่ — บังคับให้เขียนสั้น อ่านออกจากระยะไกล ปากกาลูกลื่นเส้นเล็กจะล่อให้คนเขียนประโยคยาวๆ ซึ่งไม่ใช่ภาษาของ event
พื้นที่ยืน ไม่มีโต๊ะ ไม่มีเก้าอี้ — ฟังดูโหดแต่จงใจ คนที่นั่งจะเฉื่อยและถอยออกจากวง คนที่ยืนจะเดินเข้าไปเขียน ไปชี้ ไปเถียงหน้ากระดาษ พลังงานของวงขึ้นกับข้อนี้มากอย่างไม่น่าเชื่อ

ทำไม Post-it ไม่ใช่กระดานวาดสวยๆ

Post-it ถูกออกแบบมาให้ “ถอดง่าย ย้ายง่าย ทิ้งง่าย” ความไม่ถาวรนี้แหละคือคุณสมบัติ มันบอกทุกคนว่า model นี้ยังแก้ได้ ไม่ต้องกลัวเขียนผิด พอเทียบกับการวาดกล่องลากเส้นในเครื่องมือสวยๆ คนจะรู้สึกว่ามัน “เสร็จแล้ว” และหยุดคิดต่อ

ลำดับการดำเนิน: จาก “มั่ว” สู่ “ระเบียบ”

รูปแบบที่ได้ผลคือ เริ่มให้มั่วก่อน แล้วค่อยจัดเรียง ไม่ใช่พยายามทำให้เป็นระเบียบตั้งแต่แรก การรีบจัดระเบียบเร็วเกินไปคือการปิดกั้นความคิดที่ยังไม่ทันโผล่

flowchart TD
  A["Kick-off: อธิบาย legend และตั้งโจทย์คำถาม"] --> B["ระเบิดไอเดีย chaotic exploration: ทุกคนเขียน event พร้อมกัน"]
  B --> C["จัดเรียงตามเส้นเวลา enforce the timeline"]
  C --> D["ทำเครื่องหมาย Pivotal Event และจอด Hotspot ไว้"]
  D --> E["ไล่เล่าเรื่องซ้ำ walkthrough เพื่อหาช่องโหว่"]
  E --> F["Wrap-up: สรุปและจัดลำดับสิ่งที่ต้องคุยต่อ"]
  classDef pivotal fill:#e8743b,stroke:#b45309,color:#1a1a1f;
  classDef hot fill:#f87171,stroke:#b91c1c,color:#1a1a1f;
  class D pivotal;
  class A hot;

Kick-off (5–10 นาที) — facilitator อธิบาย legend สั้นๆ (โฟกัสแค่ event สีส้มก่อน) ตั้งขอบเขตของเรื่องที่จะ storm และตั้ง timebox ให้ชัด อย่าบรรยายทฤษฎีนาน คนอยากลงมือ
ระเบิดไอเดีย (chaotic exploration) — ให้ ทุกคนเขียน event พร้อมกัน ไม่ต้องรอคิว ไม่ต้องผลัดกันทีละคน กระดาษจะเต็มไปด้วย Post-it ส้มแบบไม่เรียงลำดับ นี่คือช่วงที่ “เสียงดังและวุ่นวาย” และมันควรเป็นแบบนั้น
จัดเรียงตาม เส้นเวลา (enforce the timeline) — เริ่มดัน Post-it ให้เรียงจากซ้าย (อดีต) ไปขวา (อนาคต) event ซ้ำจะถูกรวม event ที่ขัดกันจะเผยตัว และช่องว่างในเรื่องจะปรากฏ
ทำเครื่องหมาย Pivotal Event และจอด Hotspot — ขีดเส้นแนวตั้งที่ event สำคัญซึ่งแบ่งช่วงของเรื่อง เช่น OrderPlaced, PaymentCaptured, FoodDelivered ส่วนคำถามหรือข้อขัดแย้งที่ยังตอบไม่ได้ ให้แปะ Post-it แดงไว้ แล้วเดินต่อ อย่าหยุดถกยาว
ไล่เล่าเรื่องซ้ำ (walkthrough) — เดินจากซ้ายไปขวาเล่าเรื่องเป็นคำพูด “แล้วอะไรเกิดต่อ?” การเล่าซ้ำจะเจอรูโหว่ที่ตายังไม่เห็น
Wrap-up — สรุปสิ่งที่ค้นพบ จัดลำดับ Hotspot ว่าอันไหนต้องคุยก่อน และนัดหมายก้าวถัดไป

🍔 จอด Hotspot ไม่ให้ขัดจังหวะ

พอถึง PaymentCaptured แล้วมีคนถามว่า “ถ้าร้านไม่กดรับใน 5 นาทีทำยังไง?” อย่าให้วงจมอยู่กับคำถามนี้ 20 นาที แปะ Post-it แดง ร้านไม่กดรับใน 5 นาที ทำยังไง? ไว้ตรงนั้นแล้วเดินเรื่องต่อ Hotspot สีแดงเรียงกันบนกระดาษคือ “วาระการประชุมครั้งหน้า” ที่ทีมสร้างขึ้นเองโดยไม่รู้ตัว

บทบาทของ Facilitator

Facilitator ไม่ใช่ “คนที่รู้คำตอบมากที่สุด” และไม่ใช่ “คนที่เขียน Post-it เก่งที่สุด” หน้าที่จริงคือคุมพลวัตของวงให้ความรู้ไหลออกมาจากคนอื่น งานหลักมีสี่อย่าง

ตั้งคำถาม ไม่ใช่ให้คำตอบ — “แล้วก่อนหน้านั้นเกิดอะไร?” “ใครเป็นคนสั่งให้สิ่งนี้เกิด?” “มีเคสที่มันไม่เป็นแบบนี้ไหม?” คำถามที่ดีดึง event ที่ซ่อนอยู่ออกมา
จัดเส้นเวลาและรักษาการไหลของเรื่อง — คอยดันให้ model เดินหน้าตามเวลา ไม่วนอยู่จุดเดียว
กันไม่ให้ลงรายละเอียดเร็วเกินไป — พอมีคนเริ่มพูดเรื่องตาราง database หรือชื่อ API ให้ค่อยๆ ดึงกลับมาที่ภาพใหญ่ “จดไว้เป็น Hotspot ก่อน เดี๋ยวเรากลับมา”
กันคนใดคนหนึ่งครอบงำวง — ถ้ามีคนพูดคนเดียวตลอด facilitator ต้องเปิดพื้นที่ให้คนเงียบๆ ได้เขียนบ้าง เพราะ expert ตัวจริงบางคนพูดน้อยแต่รู้ลึก

สิ่งที่ facilitator ไม่ควร ทำคือเขียน Post-it แทนทุกคน เพราะทันทีที่ปากกาไปกระจุกอยู่คนเดียว ความเร็วของวงจะตกลงมาเท่าความเร็วมือของคนคนนั้น และคนอื่นจะกลายเป็นผู้ชม

ผลพลอยได้ที่ห้ามมองข้าม: Ubiquitous Language

ระหว่างที่วงเถียงกันว่า “รับออเดอร์” กับ “ยืนยันออเดอร์” ต่างกันไหม facilitator ควรเงี่ยหูฟังเป็นพิเศษ เพราะนั่นคือ ภาษาที่ทุกฝ่ายใช้ร่วมกัน กำลังก่อตัว จับคำที่ทีมตกลงกันได้ แล้วเขียนลง Post-it ให้ตรงกัน — คำเหล่านี้จะกลายเป็นชื่อ class ชื่อ event และชื่อ API ใน code จริงต่อไป

กับดักที่พบบ่อย

ต่อไปนี้คือกับดักที่ทำให้เวิร์กช็อปกลายเป็นการประชุมน่าเบื่อ facilitator ที่ดีจะจับสัญญาณเหล่านี้ได้ตั้งแต่เนิ่นๆ

ห้ากับดักที่ฆ่าเวิร์กช็อป

1. ลงรายละเอียดเร็วเกินไป — วงเริ่มถกเรื่อง schema ฐานข้อมูลหรือ endpoint ตั้งแต่ 15 นาทีแรก ภาพใหญ่ยังไม่ทันเห็นก็จมอยู่กับเทคนิคแล้ว จับกลับมาที่ event ก่อนเสมอ

2. dev ครอบงำ domain expert — เมื่อทีมเทคนิคพูดมากจน expert เงียบ ความรู้ที่เราตั้งใจมาขุดจะถูกกลบด้วยการเดาของ dev เอง facilitator ต้องเปิดไมค์ให้ expert

3. ไม่มี expert ตัวจริงในห้อง — ส่งตัวแทนที่ “พอรู้เรื่อง” มาแทนคนที่ทำงานจริง สุดท้ายได้ model ที่ดูดีแต่ผิดจากความจริง นี่คือกับดักที่ร้ายที่สุด เลื่อนวันดีกว่ามาแบบไม่มีคนตอบ

4. เขียน event ผิดรูป — เขียนเป็นกริยาปัจจุบันหรือคำนาม เช่น ชำระเงิน หรือ การชำระเงิน แทนที่จะเป็นอดีตกาล PaymentCaptured event ต้องเป็น “สิ่งที่เกิดขึ้นแล้ว” เสมอ ไม่งั้นเส้นเวลาจะสับสน

5. Facilitator เป็นคอขวด — facilitator ยึดปากกาไว้คนเดียว เขียนแทนทุกคน วงเลยเดินช้าเท่ามือคนเดียว หน้าที่คือ “คุมวง” ไม่ใช่ “เขียนแทนวง”

สรุปเป็นภาพว่าอะไรควรทำและอะไรควรเลี่ยง

flowchart LR
  subgraph GOOD["ควรทำ do"]
    direction TB
    G1["ทุกคนยืน ไม่มีเก้าอี้ให้นั่งเฉื่อย"]
    G2["ทุกคนเขียน Post-it พร้อมกัน"]
    G3["เริ่มมั่วก่อน แล้วค่อยจัดเรียงทีหลัง"]
    G4["จอด Hotspot ไว้ ไม่ถกยาวกลางวง"]
    G1 --> G2 --> G3 --> G4
  end
  subgraph BAD["ควรเลี่ยง dont"]
    direction TB
    B1["ผลัดกันพูดทีละคน"]
    B2["ลงลึกรายละเอียดเทคนิคเร็วเกินไป"]
    B3["facilitator เขียนแทนทุกคนจนเป็นคอขวด"]
    B4["ไม่มี domain expert ตัวจริงในห้อง"]
    B1 --> B2 --> B3 --> B4
  end
  classDef good fill:#86efac,stroke:#15803d,color:#1a1a1f;
  classDef bad fill:#f87171,stroke:#b91c1c,color:#1a1a1f;
  class G1,G2,G3,G4 good;
  class B1,B2,B3,B4 bad;

Remote / Online Event Storming

โลกจริงบางทีทุกคนมารวมตัวในห้องเดียวไม่ได้ Event Storming ทำแบบออนไลน์ได้ แต่ต้องยอมรับว่ามัน “ช้ากว่าและฝืดกว่า” เสมอ เพราะเราสูญเสียพลังงานของการยืนหน้ากระดาษเดียวกันไป

ใช้กระดานออนไลน์ ที่จำลอง modeling surface แบบไม่จำกัด และให้หลายคนแปะ Post-it พร้อมกันได้ วางชุดสี legend ไว้ให้หยิบง่าย
ต้องคุมวงให้แน่นขึ้น — บนจอ คนหลุดโฟกัสง่ายและเงียบง่ายกว่าเดิมมาก facilitator ต้องคอยเรียกชื่อ ถามความเห็นเป็นรายคน และคุมจังหวะให้กระชับ
จำกัดขนาดกลุ่มให้เล็กลง — วงออนไลน์ 5–6 คนมักได้ผลดีกว่าวงใหญ่ เพราะคุมการพูดทับกันได้ง่ายกว่า ถ้าคนเยอะ ให้แตกเป็นหลายรอบย่อย
แบ่งเป็น session สั้นหลายครั้ง — ยืนหน้าจอสามชั่วโมงรวดพลังงานหมดไว ซอยเป็นหลายรอบสั้นๆ จะรักษาคุณภาพได้ดีกว่า

ถ้ารู้สึกว่า Event Storming แบบภาพใหญ่ยังไม่พอเจาะลึกกระบวนการเฉพาะเรื่อง อีกเครื่องมือที่เข้าคู่กันได้ดีคือ Domain Storytelling ซึ่งเล่าเรื่องผ่านตัวละครและการกระทำเป็นลำดับ ช่วยเสริมมุมที่ ES ยังไม่ละเอียดพอ

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดต่อได้ที่คลังอ้างอิง DevIQ:

Event Storming — สรุปรูปแบบและวิธีนำไปใช้ทั้งกระบวนการ ใช้ทบทวนภาพรวมก่อนไปจัดวงจริง
Domain Storytelling — เครื่องมือทางเลือกและตัวเสริมเมื่อ Event Storming ยังเจาะกระบวนการได้ไม่ลึกพอ
Ubiquitous Language — ผลพลอยได้สำคัญที่ facilitator ต้องคอยจับระหว่างวง เพราะคำที่ทีมตกลงกันจะกลายเป็นภาษาใน code จริง

เช็กความเข้าใจ — บทที่ 5

ข้อ 1 / 3

ในเวิร์กช็อป Event Storming ใครคือคนที่ ‘ขาดไม่ได้’ ที่สุด?

การ​จัด​เวิร์กช็อป Event Storming

ใคร​ต้อง​อยู่​ใน​ห้อง — “คน​ที่​มี​คำถาม เจอ​คน​ที่​มี​คำ​ตอบ”

เตรียม​ของ: กระดาษ​ยาว Post-it และ “ห้าม​นั่ง”

ลำดับ​การ​ดำเนิน: จาก “มั่ว” สู่ “ระเบียบ”

บทบาท​ของ Facilitator

กับดัก​ที่​พบ​บ่อย