Event Storming กับคนแคระทั้งเจ็ด ตอนที่ 1

หากเปรียบ Event Storming เป็นนิทานเรื่องหนึ่ง บทเกริ่นนำคงจะเป็นการกล่าวถึง 3 ดินแดนสำคัญของจุดเริ่มต้นการเดินทางในครั้งนี้ ดินแดนเหล่านั้นได้แก่ Big Picture Level, Process Level และ Design Level

นิทานเรื่องนี้จะมีทั้งหมด 2 ตอน ครอบคลุมเนื้อเรื่องเกี่ยวกับ Big Picture Level และ Process Level ส่วนดินแดน Design Level อยากให้ทุกคนรอติดตามผ่านตอนพิเศษที่ชื่อว่า “How to Implement Modular Monolith”

Case Study

ในบทความนี้จะเล่าผ่านมุมมองของ 2 เรื่องราวที่แตกต่างกันโดยสิ้นเชิง ฝั่งซ้ายสุดคือ โลกของเวทมนตร์ ความรักและจุมพิต ผ่านมุมมองของสโนว์ไวท์กับคนแคระทั้งเจ็ด ฝั่งขวาสุดคือ โลกของ Software Development ที่กำลังพัฒนาระบบที่ชื่อว่า Gym Management

• สโนว์ไวท์กับคนแคระทั้งเจ็ด: สำหรับใครที่ไม่รู้จักนิทาน สโนว์ไวท์กับคนแคระทั้งเจ็ด ไม่ต้องอ่านต่อนะ กลับไปอ่านนิทาน https://baby.kapook.com/view245234.html ก่อนนะครับ
• Gym Management: แอปพลิเคชัน SaaS (Software as a Service) สำหรับให้ยิมต่าง ๆ นำไปใช้งาน เริ่มตั้งแต่การสร้างโปรโมทไปจนถึงการลงทะเบียนบัตรผ่านเพื่อเข้าใช้งาน

Event Storming

“กาลครั้งหนึ่งนานมาแล้ว มีเจ้าหญิงรูปโฉมงดงามน่ารักนามว่า สโนว์ไวท์ เธออาศัยอยู่ในปราสาทกับพระราชินี แม่เลี้ยงของเธอ”

นิทานหลาย ๆ เรื่องมักจะเริ่มต้นด้วยคำว่า “กาลครั้งหนึ่งนานมาแล้ว” เป็นส่วนเกริ่นนำเรื่อง บอกเล่าภูมิหลัง พาเราไปทำความรู้จักกับตัวละครต่าง ๆ กว่าสโนว์ไวท์จะได้พบเจ้าชายก็ต้องผ่านเรื่องราวมากมาย

เช่นเดียวกัน ก่อนทุกคนจะได้ข้อสรุปว่า Event Storming คืออะไร ก็ต้องไปรู้จักกับส่วนประกอบต่าง ๆ ของนิทานเรื่องนี้กันก่อน

Big Picture Level

ณ ดินแดน Big Picture Level

ดินแดน Big Picture Level คือส่วนเริ่มต้นของการทำ Event Storming Workshop โดยที่ใน Level นี้ เราจะให้ความสำคัญกับภาพรวม กระบวนการและวิธีที่เราทำธุรกิจอยู่ในปัจจุบัน เรื่องราวทั้งหมดจะถูกร้อยเรียงตั้งแต่จุดเริ่มต้น ไหลไปเรื่อย ๆ ผ่าน Post-it สีต่าง ๆ เราจะได้เห็นว่า ใคร แผนกอะไร รับผิดชอบส่วนไหน เห็นส่วนประกอบทั้งมุมมอง External และ Internal System กระบวนการนี้จะทำให้ทุกคนเห็นภาพตรงกันว่า Business เราทำงานและทำเงินอย่างไร

Events

หากใครเคยทำ Workshop ของ Event Storming มักจะคุ้นเคยกับคำว่า “ให้ทุกคนเขียน Events ลงบน Post-it สีส้ม”

คำว่า Event แปลเป็นภาษาไทยคือคำว่า “เหตุการณ์” ซึ่งมีความหมายถึง เรื่องที่เกิดขึ้นไปแล้ว เช่น ราชินีเกิดความริษยา, สโนว์ไวท์กินแอปเปิ้ลพิษ หรือ เจ้าชายจูบสโนว์ไวท์ เรื่องราวเหล่านี้คือ เหตุการณ์ที่เกิดขึ้นไปแล้ว

ในโลกของ Event Storming คำว่า Event มีไว้เพื่อ Represent ถึง Business Event ไม่ใช่ Technical Event

หากสมมุติว่าเรากำลังพัฒนาระบบ Gym Management ตัวอย่างของ Event ที่เกิดขึ้นได้ ก็จะเป็นประมาณ ร่างข้อเสนอขึ้นมาแล้ว หรือ เซ็นสัญญาแล้ว หากยึดตามหลัก Grammar ในภาษาอังกฤษ การเขียน Event คือเรื่องที่เกิดขึ้นและจบลงแล้วในอดีต เราเลยต้องเขียนให้อยู่ในรูปของ Past Tense หากเขียน Events เมื่อสักครู่ตามหลัก Grammar จะได้ Offer prepared และ Contract signed

สโนว์ไวท์: ทำไมต้องเริ่มด้วย Events? คนแคระทั้งเจ็ด: Events คือการเล่าเรื่องราวในธุรกิจว่าเกิดอะไรขึ้น เป็นภาษากลางที่ช่วยให้ Business, Developer, Designer ไปจนถึง Domain Experts สามารถเข้าใจตรงกันได้ง่ายกว่าการคุยเรื่อง Database หรือ Code มาดูตัวอย่างของ Events จากระบบ Gym Management

**กิจกรรม: **จาก List ของ Events ด้านบน ลอง Comment มาหน่อยว่า Events ไหนบ้าง ที่เป็น Technical Event

สโนว์ไวท์: “ทำไมต้องใช้ Post-it?” คนแคระทั้งเจ็ด: “ในระหว่าง Workshop เราจะ Discuss เพื่อสร้าง Shared Understanding ข้อดีของ Post-it คือสามารถดึง ขยับซ้าย ขวา ขึ้น ลง ได้สะดวก”

Hot Spot

Event Storming เป็นเครื่องมือที่ช่วยให้เราเห็นได้ทั้ง “แนวกว้าง” ตั้งแต่จุดเริ่มถึงจุดสิ้นสุดของระบบ หรือเราจะใช้เจาะลึกเป็น “แนวดิ่ง” ไล่ดูว่าจาก Event ใบที่เราสนใจมี Business Rules หรือใครยุ่งเกี่ยวกับกระบวนการนี้บ้าง ลงลึกได้ถึงระดับการเขียนโค้ดช่วยให้ Model ชื่อ Class หรือ Orchestration อยู่ที่ว่า ณ เวลานั้น เราให้ความสำคัญกับเรื่องอะไร

Hot Spot มีไว้เพื่อ Represent ถึงคำถาม, ปัญหา หรือจุดที่ยังไม่ชัดเจนที่เราไม่สามารถหาคำตอบได้ในตอนนั้น ช่วยให้เราไม่จมดิ่งจนลืมเป้าหมายที่แท้จริงของการทำ Workshop และยังช่วยให้มั่นใจว่าข้อกังวลเหล่านั้นจะไม่ถูกลืม

Hot Spot นิยมใช้ Post-it สีสันจัดจ้านโดดเด่นสะดุดตา เพื่อให้เห็นชัดว่าตรงนี้มีคำถาม เป็นจุดที่ยังไม่ชัดเจน ให้กลับมาดูด้วยนะ ตัวอย่างของ Hot Spot ในระบบ Gym Management

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

External System

“กระจกวิเศษ จงบอกข้าเถิด ใครงามเลิศในปฐพี?” และทุก ๆ ครั้งกระจกก็จะตอบว่า “ท่านนี่แหละ ไม่มีผู้ใดงดงามเกิน”

External System มีไว้เพื่อ Represent แสดงถึงระบบภายนอกที่เชื่อมต่อกับเรา อาจเป็น Application หรือ Platform ของภายนอกองค์กร (เช่น ระบบ Payment Gateway อย่าง PayPal หรือ Stripe) โดยมักจะใช้ Post-it สีชมพู

นอกจากซอฟต์แวร์แล้ว External System ยังสามารถหมายถึงองค์กรภายนอก หรือแผนกอื่นในบริษัทที่ไม่ได้เข้าร่วมใน Workshop ครั้งนี้ได้ด้วย

กรัมปี้: “ทำไม External System ยังสามารถหมายถึงองค์กรภายนอกได้ด้วย?” สลีปปี้: “เดี๋ยวจะเล่าให้ฟังนะในดินแดน Process Level แต่ตอนนี้ไปดูตัวอย่างกันก่อน”

Show An Example

ด้านล่างคือจำนวน Events ทั้งหมดจากเรื่องราวของหญิงสาวที่กัดแอปเปิลและได้พบรักกับเจ้าชายบนหลังม้าสีขาว

Timeline

Timeline คือการนำเอา Events ที่เกิดขึ้นใน Workshop มาเรียงลำดับต่อกันตามเวลาที่เกิดขึ้นจริง โดยจะเรียงจาก ซ้ายไปขวา หรือ จากขวามาซ้าย ก็ได้ แต่ผลลัพท์สุดท้ายจะเหมือนกัน คือ เราเห็น Events ทั้งหมดตั้งแต่จุดเริ่มต้นไปจนถึงจุดสิ้นสุด

• From Left to Right: เริ่มต้นจาก Event แรก เรียงถัดไปเรื่อย ๆ จนถึง Event สุดท้าย เป็นเทคนิคการเล่าเรื่องตามธรรมชาติของสมอง ทำให้สามารถเล่าเรื่องราวได้อย่างละเอียดและดูเป็นธรรมชาติ เหมาะสำหรับการเรียง Events ทั้งหมดให้ครบถ้วน
• From Right to Left: เริ่มต้นจาก Event ท้ายสุด ไล่ย้อนกลับมาเรื่อย ๆ จนถึง Event แรกสุด เป็นเทคนิคที่เอาไว้ช่วยในการ Validate เนื่องจากเทคนิคนี้ขัดกับธรรมชาติของสมอง จึงทำให้เราค่อย ๆ ไล่ย้อนไปทีละใบ และมีโอกาสเจอ Event อื่น ๆ เพิ่มเติมได้มากกว่าปกติ เราเรียกเทคนิคนี้ว่า Reverse Narrative

Emerging Structure

ในนิทานหรือภาพยนตร์เปรียบจุด Climax คือจุดพีคของเรื่อง สำหรับ Event Storming แล้วความสนุกไม่ใช่การรอให้ถึงจุด Climax แต่เป็นการหาสิ่งที่เรียกว่า Lines of Demarcation of Responsibility

ในธุรกิจหนึ่ง ๆ ไม่ใช่หนึ่งคนที่ทำทุกอย่าง มักจะมีเส้นแบ่งความรับผิดชอบระหว่าง Actors, System, Departments หรือบลา ๆ แต่ ณ ตอนนี้ผมขอเรียกเส้นแบ่งตรงนี้ว่า Boundaries ก่อนแล้วกัน เส้นแบ่งตรงนี้มีความสำคัญมาก ๆ ใน Level ถัดไป แต่ก่อนอื่น มาดูเทคนิคที่ใช้ในการมองหา Boundaries กันก่อน ผมจะหยิบแค่ 2 เทคนิคที่ผมรู้จักคือ Pivotal Events และ Swimlanes

Pivotal Events

Pivotal Events หากเรานำ Event มาเรียงต่อกันเป็น Timeline มักจะมีจุดที่สะท้อนถึงการเปลี่ยนผ่านจากสถานะหนึ่งไปสู่อีกสถานะหนึ่ง

Tips ในการสังเกต Pivotal Events ส่วนนี้เป็นแค่ Tips ในตำรา แต่ใน Workshop จริงต้องอาศัยพลังวัตรของ Facilitator และผู้เข้าร่วม

• Switch of Actors: จุดที่มีการส่งต่องานระหว่างบุคคล ตัวอย่างเช่น พนักงานต้อนรับอัปเดตข้อมูลความคืบหน้าของสมาชิกเสร็จสิ้น แล้วส่งต่อให้เทรนเนอร์เข้ามาเป็นผู้ตรวจสอบข้อมูลนั้นต่อ
• Subprocess Event: Event ที่เป็นผลลัพธ์ของ Event ทั้งหมดที่อยู่ทางฝั่งซ้ายมือ ตัวอย่างเช่น Offer prepared → Offer reviewed → Offer corrected → Offer approved ชุดของ Events ก่อนหน้าทั้งหมดที่เกิดขึ้นเพื่อให้ได้เป้าหมายสุดท้ายคือ Event ที่ชื่อว่า Offer published
• Terminology: Event ที่เป็นจุดต่อของการส่งงานข้ามแผนก ให้สังเกตการใช้คำศัพท์ที่ไม่ตรงกันระหว่างฝั่งซ้ายและขวาของเหตุการณ์ ซึ่งใน DDD เราเรียกสิ่งนี้ว่า Ubiquitous Language

ตัวอย่างจาก Gym Case Study ให้สังเกตตัว “P” นั่นคือ Pivotal Events

ความต้องการเบื้องต้นของระบบคือ การสร้างและโปรโมตข้อเสนอ (Offers), การทำสัญญา (Contracting), การออกบัตรผ่านเข้ายิม (Pass Registration), การจัดการบัตรหมดอายุหรือต่อสัญญาและการออกรายงานพื้นฐาน

Swimlanes

Pivotal Events เป็นวิธีที่ใช้ในการแบ่ง Timeline โดยใช้เทปกาวตัดเส้นเป็นแนวตั้ง เพื่อบอกว่าจบ Process หนึ่งแล้วและกำลังจะเริ่ม Process ถัดไป แต่ในธุรกิจจริง ๆ งานไม่ได้เรียงเป็นเส้นตรงแบบ A ไป B เสมอไป เพราะจะมีงานที่ทำแบบ Parallel Processes ควบคู่กันไปได้ ซึ่งเราสามารถใช้ Swimlanes มาแบ่งเป็นเส้นแนวนอนเพื่อแยกตาม Actor หรือแผนกที่รับผิดชอบ ซึ่งวิธีนี้จะช่วยให้เราอ่าน Flow ได้ง่ายขึ้นมาก

Swimlanes จะ Model ของได้ดีในกรณีที่เรามี Process ชัดเจนเพียงไม่กี่อย่างที่ทำไปพร้อมกันกับ Flow หลัก ดังนั้น เราควรหาเรียง Timeline และหา Pivotal Events ให้เสร็จก่อน แล้วจึงค่อยนำ Swimlanes มาใช้ในภายหลัง

Tips การแบ่ง Swimlanes ส่วนนี้เป็นแค่ Tips ในตำรา แต่ใน Workshop จริงต้องอาศัยพลังวัตรของ Facilitator และผู้เข้าร่วม

• Actors: การสร้าง 1 เลนต่อ 1 กลุ่ม Actor (เช่น Customer, Trainer หรือ Sales จะช่วยให้มองเห็นการส่งต่องานข้ามทีมหรือตัวบุคคลได้ชัดเจนขึ้น
• Alternative Paths: ใช้แยกเส้นทางที่ให้ผลลัพธ์ต่างกันออกจากกัน เช่น เลนสำหรับกรณี “ขอคืนเงินสำเร็จ” ทำงานขนานไปกับเลน “ขอคืนเงินไม่สำเร็จ”
• Parallel Processes: ใช้เพื่อแสดงกระบวนการที่ต่างคนต่างทำพร้อมกัน เช่น ลูกค้ากำลังดำเนินการชำระเงินผ่านระบบภายนอก และฝ่ายขายกำลังตรวจสอบความถูกต้องของเอกสารสัญญา โดยงานเหล่านี้จะกลับมารวมกันที่ Pivotal Event ซึ่งในตัวอย่างนี้คือ Contract Started

ในหนังสือยังมีเทคนิคอีก 2–3 หากใครสนใจลองไปตามอ่านเพิ่มที่ Introducing Event storming

ย้อนกลับไปตอนต้นของบทความ ผมได้เล่าเกี่ยวกับสีต่าง ๆ ของ Post-it และวัตถุประสงค์ในการใช้งาน หลังจากเรานำ Event มาเรียงบน Timeline และหา Lines of Demarcation of Responsibility แล้ว ขั้นตอนต่อไปเราสามารถเขียน External System หรือ Hot Spot สำหรับคำถาม, ปัญหา หรือจุดที่ยังไม่ชัดเจน แปะตาม Event ดังรูปด้านล่าง

Next Step

หลังจากได้ข้อมูลที่จำเป็นจากดินแดน Big Picture Level แล้ว ก็ได้เวลาเตรียมตัวเก็บกระเป๋า โบกมือลาสโนไวท์กับคนแคระทั้งเจ็ด เพื่อออกเดินทางไปสู่ดินแดน Process Level ดินแดนที่จะพาเราไปลงลึกถึงโลกของ Actors, Read Model, Command และ Policy

Refs

• https://leanpub.com/introducing_eventstorming
• https://leanpub.com/eventstorming_handbook
• https://leanpub.com/understand-your-domain-first