When to use Event Modeling?

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

Event Modeling ไม่ใช่เครื่องมือที่แก้ได้ทุกปัญหา เกิดมาเพื่อแก้ปัญหาบางอย่าง บทความนี้จะขอยก 3 สถานการณ์ที่สามารถนำเครื่องมือนี้ไปใช้งานได้

Documenting an existing system

สำหรับระบบใหญ่ ๆ บางคนเรียกเค้าว่า คุณปู่ เป็นคุณปู่ประจำองค์กรหรือปีศาจที่ไม่มีใครอยากเข้ายุ่งวุ่นวาย เปรียบเสมือนมรดกที่ได้รับสืบทอดมาจากรุ่นพี่และรุ่นพี่ไปไหนแล้วก็ไม่รู้ จะต่างจากในภาพยนตร์ก็ตรงที่ไม่ได้มรดกเป็นบ้าน 10 ล้าน คนที่ดูแลก็เริ่มหลงๆ ลืมๆ จำถูกจำผิดหรือจำไม่ได้ว่าระบบทำงานอย่างไร คนที่เข้ามาใหม่ก็ต้องใช้เวลานานมากกว่าความเข้าใจมั้ง!! ถามพี่แต่ละคนก็อธิบายไม่เหมือนกัน ค้นหา Confluence หรือ Jira ก็เจอ 10 กว่า Version เหมือนตั๋วพาสู่ความมืดมน ไม่ต้องพูดถึงการเพิ่ม Feature ใหม่แค่จะเพิ่ม Console สักบรรทัดแล้ว Push ขึ้น Git ยังไม่กล้าเลย

Event Modeling เป็นหนึ่งในเครื่องมืออีกหลาย ๆ ตัว ที่อยากจะแก้ปัญหานี้ คนมักเข้าใจผิดว่า การนำเอาแนวคิดนี้ไปปรับใช้จะต้องมีระบบที่ถูกออกแบบการทำงานแบบ Event-driven หรือ Event-sourcing จะบอกว่าไม่จำเป็น จุดเด่นของเครื่องมือนี้คือการนำเอา Visual language เข้ามาช่วยอธิบาย Data flow ใน System ทำให้เห็นว่าระบบที่เรียกว่าปีศาจ มีขั้นตอนการไหลของข้อมูลเป็นอย่างไร เห็นถึงข้อมูลที่ได้จาก External systems เข้าใจรายละเอียดแต่ละหน้าจอว่าได้ข้อมูลมาจากไหน หลังจากทำ Event Modeling เราจะสามารถจิบกาแฟแล้วอธิบายระบบเป็น Story จากซ้ายไปขวาตาม Timeline ของระบบ

Planning a New System

คงจะสนุกน่าดู หลังจากทำ Product Discovery ตัด MVP ตกลงร่วมกันว่าในอีก 2 อาทิตย์ อยากได้อะไรไปเก็บ Feedback จาก User Segment

เรามี Post-it ที่เขียนว่า เข้าสู่ระบบ, Place order หรือ Restaurants register คำถามต่อไปคือ ระบบมันทำงานอย่างไร? ก่อนที่เราจะเริ่มเขียน Code บรรทัดแรก เรามาลองทำ Wireframes ง่าย ๆ เพื่อให้ทุกเห็นภาพเดียวก่อนดีไหม หน้าเข้าสู่ระบบที่คุยกันมาทั้งวันเนี่ย!! ต้องกรอกข้อมูลอะไรบ้าง หรือจริงๆ มีแค่ปุ่ม Sign in with Google ผู้ใช้งานต้องผ่านขั้นตอนหรือต้องมีข้อมูลอะไรถึงจะกดปุ่ม Place order ได้

อย่าพึ่งเข้าใจผิดนะ Event Modeling ไม่ได้การันตีว่าหลังทำสิ่งเหล่านี้เสร็จ ตอนที่ไปเริ่มเขียน Code จะไม่มีอะไรเปลี่ยนแปลง Wireframes มีจุดประสงค์เพื่อคุยกันถึงรายละเอียดของข้อมูล เห็น Data Flow เป็นคนละเรื่องกับ UX/UI สิ่งนี้ช่วยทำให้ Start discussing จาก Visual Language แล้วจึงค่อย ๆ ไล่ไปทีละขั้นตอนตาม Timeline ตั้งแต่จุดเริ่มต้นที่มีแค่ข้อมูล Email/Password ไปจนถึงข้อมูลที่สำคัญอย่าง Amount หรือ Platinum member เห็นเรื่องราวของผู้ใช้งาน เห็นขั้นตอนหรือมีกระบวนการอะไรที่ทำให้ผู้ใช้งาน 2 คนเห็นข้อมูลไม่เหมือนกัน ร่วมไปถึงการพูดคุยเรื่อง Business policy ภาพในฝัน ณ วันที่ทำ Workshop จะมี Whiteboard อันใหญ่ ๆ มี PO, Stakeholder, Domain expert และ Team นั่งจับเข่าคุยกัน

Preparing Refinements

การรอให้เริ่ม Project ใหม่แล้วค่อยจัด Workshop หรือการกลับไป Modeling Existing system ดูเป็นเรื่องที่ต้องใช้ Effort มหาศาล หากเริ่มศึกษาและสนใจ Event Modeling ได้ลองทำ Workshops มาบ้าง ๆ แล้ว จนเกิดความรู้สึกอยากลองนำไปปรับใช้กับงานสามารถลองใช้ในช่วงของการทำ Refinement ได้นะ

Product Backlog Refinement เป็นช่วงที่ทีมหยุดวิ่งและเงยหน้าขึ้นมาทำความเข้าใจปัญหา ลองเอา Step ที่ 7. Elaborate Scenarios ใช้ Give-When-Then เพื่อตรวจสอบ Use Case ต่าง ๆ หรือในกรณีที่ยังไม่เข้า Workflow ลองวาด Wireframes คร่าว ๆ เพื่อให้เห็น Data flow เอาเรื่อง Business policy โยนเข้า Use Case ที่คุยกัน

จากตัวอย่างของขั้นตอน Place order ผู้ใช้งานทำ Action อะไรมาก่อนถึงจะสามารถกดปุ่ม Place order เกิด Command อะไร หรือว่า Event ที่ในระบบมีข้อมูลที่เราต้องการแล้วหรือยัง ขั้นตอนเหล่านี้ทำเพื่อให้เราเข้าใจปัญหามากขึ้น ถ้าเราเข้าใจปัญหาดีแล้วใน Next Sprint เราจะออก Solution เพื่อแก้ปัญหาได้ตรงจุด

Conclusion

คำถามที่สำคัญกว่า When to use คือ Why to use ทุก ๆ Tools หรือ Framework มันเกิดมาเพื่อแก้ปัญหาบางอย่าง ไม่ได้แก้ได้ทุกอย่าง ควรเข้าใจปัญหาก่อนที่เลือกเครื่องมือเข้ามาช่วยแก้ปัญหา

Event Modeling เป็นแค่ Tools ตัวหนึ่ง ที่ช่วยเรื่องเห็น Workflow และ Dataflow ตาม Timeline และช่วยให้เราแบ่งขั้นตอนต่าง ๆ เป็น Atomic steps จากที่เราจะคุยกันผ่านอากาศหรือให้ Team ไปนั่งเทียนแล้วคิดเอง กระบวนการนี้ทำให้เราได้มีโอกาส Discussions ไปกับ PO/Stakeholder ไปทีละขั้นตอนผ่าน Visual language และ Ubiquitous Language เดียวกัน

ในปี 2024 เครื่องมือนี้ไม่ใช่ทางเลือกเดียวที่สามารถนำมาแก้ปัญหาเหล่านี้ได้ ยังมีเครื่องมือตัวอื่น ๆ เช่น Event Storming, Domain Storytelling เครื่องมือเหล่านี้เกิดมาเพื่อแก้ปัญหาเดียวกันคือ “to improve the status quo in the IT industry. We can do better.” สิ่งสำคัญ!! ไม่ว่าเราจะเลือกใช้เครื่องมือใด ๆ ถ้าเราเริ่มใช้มันอย่างจริงจัง เราต้องลืมพฤติกรรมเดิม ๆ ของเรา เมื่อต้องการ Change something in the system สิ่งแรกที่เราควรทำไม่ใช่การแก้ Code แต่คือการเข้าใจปัญหาผ่านเครื่องมือที่เราเลือกและแก้ไขให้ตรงตาม Business Process ที่อยากได้ จากนั่น Go to code.

ความยากของการทำ Documents ไม่ได้อยู่ที่ตอนสร้าง แต่อยู่ที่เราจะทำอย่างไรให้มันเป็นจริงตลาดเวลา เอ๊ะ!! ตลอดเวลา ผมไม่ได้กล่าว

Refs: https://eventmodeling.org/

https://leanpub.com/eventmodeling-and-eventsourcing