เนื่องจากผู้เขียนได้มีโอกาสไปเข้าร่วมงาน UXTH Conference 2024 จัดโดย UX Thailand x Gang Connecter x Soldoutt และได้ไปฟังเรื่อง Ubiquitous Language มา จึงอยากมาเขียนเล่าสิ่งที่ผู้เขียนเรียนรู้ให้ทุกคนได้อ่านกัน
สิ่งที่ทำให้ผู้เขียนสนใจคือ Speaker (พี่รูฟ) ได้กล่าวว่าในทุกวันนี้ โลกของ Software Development ถูกพัฒนามาไกลแล้ว แต่สิ่งที่ขาดหายไป คือ Lingua Franca ไว้สื่อสารกันอย่างชัดเจน ระหว่าง UX และ Developer
Lingua Franca คืออะไร?
Lingua Franca คือ Bridge language/Common language ที่ทำให้เราสามารถใช้สื่อสาร ระหว่างคนที่อยู่คนละเผ่ากันได้ หรือมีภาษาถิ่นที่ต่างกันได้ เช่น สำหรับคนทำงานในครัว มี Lingua Franca คือสูตรอาหาร ไม่ว่าจะเป็นคนล้างผัก เชฟ หรือ คนเสิร์ฟ เมื่อเขาอ่าน เขาจะเข้าใจตรงกัน ว่าสูตรอาหารนี้มันทำมายังไง หรือ ในงานก่อสร้าง มี Lingua Franca คือแบบ/แปลนก่อสร้าง ทุกตำแหน่งจะมีความสามารถในการสื่อสารผ่านแบบนี้ได้
แล้วใน Software Development สถานการณ์เป็นแบบไหน?
พี่รูฟ อธิบายผ่านการยกตัวอย่าง สถานการณ์ การเริ่มสร้าง Application ตั้งแต่ ศูนย์เลย
UX Designer จะเป็นคนกลุ่มแรกที่ทำงาน ในการดราฟท์แบบ ผ่าน User Experience Design Process สุดท้ายสิ่งที่ได้ออกมา คือ แบบร่างว่านี้คือ หน้าตา Application ที่เราอยากได้ ซึ่งพอเสร็จจากขั้นตอนนี้แล้ว ส่วนใหญ่ทีม UX Designer ก็จะส่งต่องาน ให้กับ Delivery team โดยเล่าให้ Developer ฟังว่า นี้คือผลลัพธ์ที่เราได้มาจากการทำ Research นะ เป็น UI Design เอาไปทำต่อได้เลย
พอผ่านจุดนี้ไป UX Designer ก็จะไม่รู้แล้วว่าหลังจากนี้มันเกิดอะไรขึ้น สิ่งที่เขา Design ไปมันจะออกมาหน้าตาเป็นยังไง เห็นอีกทีก็ตอน Review แล้ว เขาจะไม่รู้ว่าก่อนที่จะออกมาเป็น App ได้ Developer ต้องผ่านกระบวนการอะไรบ้าง
ซึ่ง Developer ก็จะมีภาษา และวิธีการคิดของเขา และเมื่อ Developer จะเห็นแค่ Screen Design สิ่งที่เขาจะทำ คือ พยายามจินตนาการว่า จากหน้าจอนี้มัน map ออกมาเป็นภาษาของ Developer ได้อะไรบ้าง และอาจเก็บรายละเอียดไม่ครบว่าคน Brief พูดถึง Business Process แบบไหน รู้แค่ว่าหน้าที่เขาคือ ต้องเปลี่ยน Design ออกมาเป็น Application และทำให้มันทำงานได้ ภายใต้ระยะเวลาที่กำหนด
“ทำให้โลกของ UX และ Developer จะค่อยๆห่างออกจากกันขึ้นเรื่อยๆ“
เกิดเป็น Pain Point ที่เรียกว่า Language Mismatch
หมายถึง ภาษาที่ใช้ใน Business Level ที่ UX ไปคุยมา กับภาษาที่ Developer ใช้ไปคนละทางกัน แต่ละคน จะมีภาษาที่อยู่ในหัวต่างกัน เขาจะมองปัญหา ในคนละมุมมองและออแบบปัญหาออกมาด้วยภาษาที่เขาใช้อยู่
จุดเริ่มต้นของปัญหา เกิดจากภาษาที่ UX ใช้อธิบาย Developer ตอนมอบหมายงาน มันไม่ได้ถูกส่งต่อไปให้ Developer อย่างชัดเจน ส่วนใหญ่จะเป็นการเล่าให้ฟัง แล้วก็ส่งต่อแค่ Screen design จึงทำให้ภาษานี้ไม่ถูกกำหนดไว้ให้เป็นรูปธรรม ตอน Developer ฟังตอนแรกก็รู้เรื่อง แต่พอทำงานไปสักพักข้อมูลเหล่านี้ก็ค่อยๆหายไป
ดังนั้น สิ่งที่ Developer ทำคือพยายามไป Map ให้เข้ากับภาษาของตัวเอง เช่น UX เคยบอกให้ทำสิ่งนี้ เรียกว่า “Create to do” แต่ Developer เปลี่ยนไปใช้คำว่า “Reset state”
ปัญหาที่ตามมาคือ คนใหม่ในทีม / ใครที่ต้องมาทำงานต่อ ไปอ่านเอกสาร Brief ของ UX เป็นอย่างดี แต่พอไปเปิด Source code ที่ Developer ทำไว้ เขาจะหาไม่เจอ ว่าคำที่ UX ใช้ อยู่ตรงไหนของ Code ทำให้ต้องไป Debug ไปรื้อ Code เพื่อที่จะได้เข้าใจ ทำให้เสียเวลาและเกิดความมึนงงอย่างมาก และประโยชน์จากการไปคุยกับ User จะหายไป เพราะสุดท้ายภาษาที่ใช้กับ User กับ ภาษาที่ใช้ในการเขียน Code มันต่างกัน
เห็นได้จากภาพว่า เมื่อเวลาผ่านไป ภาษาที่ใช้ในการทำงานทั้ง 2 ส่วน จะยิ่งห่างออกจากกันไปเรื่อยๆ และจะเริ่มคุยไม่รู้เรื่องในที่สุด ทำให้ความเป็นไปได้ที่ระบบจะสามารถถูก maintain ในระยะยาวลดลงไปเรื่อยๆ
รูปนี้แสดงให้เห็นว่า คำว่า Experience ไม่เคยถูกมองกลับมาด้านหลังที่เป็นทีมที่ Deliver อยู่ เพราะกำแพงของ process ในการทำ software ของเรามันถูกกั้น ทำให้เมื่อเราใช้ process แบบนี้ ช่องว่างระหว่างทีม Discovery กับ Delivery จะยิ่งห่างกันไปเรื่อยๆ
เป็นไปได้มั้ยที่เราจะหาเครื่องมือบางอย่างที่เราจะทำให้ ทั้งสองส่วน มาเติมเต็มกัน?
พี่รูฟ แนะนำเครื่องมือตัวนึง ที่ช่วยแก้ปัญหาตรงนี้ได้ คือ “Event Storming“
Event storming สามารถทำได้หลายอย่าง แต่จะเข้ามาใช้แก้ปัญหานี้ได้ ใน Part “Critical Software Design”
Event Storming Flow ทำงานยังไง?
เราจะใช้วิธีการคิดว่า แทนที่เราจะเริ่ม Model ด้วย Journey หรือ UI Design / Screen Design เราจะเริ่มด้วย Event Storming ด้วย Sticky note ตามสีในภาพ
เริ่มจากสิ่งที่เรียกว่า “Event” คือสิ่งที่เกิดขึ้นใน System ไล่เป็นลำดับเหตุการณ์แล้วจะใช้ sticky note สีส้มเสมอ และ จะถูกเขียน เป็น Standard ด้วย Past tense
*ขั้นตอนนี้ เราจะยังไม่เริ่มเขียน UI Design อะไรเลย เราจะเริ่มคิดก่อนว่า มีอะไรเกิดขึ้นในนั้นบ้าง แล้วเราค่อยเอาของเหล่านั้น มาประติดประต่อกันเป็น Journey แล้วค่อยเอา Event มา Drive ให้ออกมาเป็นของรอบข้าง (สนใจแค่สีส้มก่อนนะ)
นึกถึง Event อะไร ให้แปะออกมาก่อนเลย ไม่ต้องสนใจว่ามันจะเริ่มก่อนหรือเริ่มหลัง
Event ที่เราได้ออกมา ะเกิดมาจากการนั่งคิดว่า Journey ของการทำ To do application ของเรา มันมี Event เกิดขึ้นมากี่อย่าง (ตัวอย่างที่พี่รูฟเล่า จะเล่าเป็นการสร้าง Application สำหรับทำ To do list)
หลังจากนั้น ให้คิดต่อว่า Event อยู่ดีๆมันจะเกิดขึ้นมาเองไม่ได้ มันจะต้องถูกสร้างขึ้นมา ซึ่งการถูกสร้างขึ้นมา จะถูกสร้างขึ้นมาผ่านสิ่งที่เรียกว่า “Command (คำสั่ง)” (แปะ Sticky note สีน้ำเงิน) เช่น
- Event = Task Deleted
- Command = Delete Task (Task จะถูกลบได้ ต้องมีคำสั่งนี้ไปลบ Task)
พอเราได้ชุด Command ออกมาแล้ว จะเห็นว่า Command นั้น อยู่ดีๆ จะไปสร้าง Event โดยตรงเลยไม่ได้ จะมีทางเลือกอยู่ 2 อย่าง ว่าต้องใช้ชุดข้อมูลใดหรือต้องไปแตะกับ System อื่นหรือไม่ ที่ Command มีส่วนเกี่ยวข้องด้วย
UX จะถูกบังคับโดยปริยายว่า เขาต้องเข้าใจบริบทโดยรวมของ System ว่า System ที่เขากำลังออกแบบอยู่ มีปัจจัยภายนอกอะไรบ้างที่เกี่ยวข้อง (ระบบอื่น, ชุดข้อมูล หรือ Action จากฝั่งผู้ใช้งาน) เพื่อให้เขาได้มาซึ่ง Event ที่เขาอยากได้
- ชุดข้อมูลจะถูกเขียนผ่านสิ่งที่เรียกว่า Read model (กระดาษสีเขียว) ที่จะระบุ information ที่ต้องถูก Query มาจากระบบ เพื่อที่จะใช้ใน Decision Making Process ไม่ว่าจะเป็นในหัวของเรา หรือ System เอง
- ส่วน Reaction ว่า “เมื่อเกิดเหตุการณ์ X เกิดขึ้น เราจะทำ Y” ซึ่งจะนำไปสู่การไหลของข้อมูล ระหว่าง Event และ Command โดยจะเรียก Automated process ว่าเป็น Policy (กระดาษสีม่วง) แต่ถ้า Trigger แบบ Manual จาก User เราจะเรียกชื่อว่า Actor (กระดาษสีเหลือง)
ตัวอย่างการใช้ Event storming ในการ สร้าง Action ของ To do application จะได้เห็นภาพกันมากขึ้น
ตัวอย่างที่ 1
Event ของการสร้าง Task ใน To do (Task created inTodo ใบสีส้ม) จะเกิดนั้นต้องมาจาก
- User ของเราเห็น UI และกดปุ่มมาเพื่อสร้าง Task
- (ใบสีน้ำเงิน) เกิด Command ที่ชื่อว่า Create Task In Todo
- (ใบสีเขียว) ใช้ชุดข้อมูลได้แก่ Title และ State เพื่อนำไปสร้าง Task in to do
- (ใบสีส้ม) สร้าง Task in To do สำเร็จ
ตัวอย่างที่ 2
Event ของการ Assign Owner ของ Task นั้นๆ (Owner Assigned) จะต้องเกิดมาจาก
- ต้องมีคน Assign (มี UI ให้เรา assigned owner)
- (ใบสีน้ำเงิน) เกิด Command ที่ชื่อว่า Assign Owner
- (ใบสีเขียว) ใช้ชุดข้อมูลได้แก่ ID, Name, Owner (ซึ่ง UI ก็ต้องมีข้อมูลให้ User ระบุเข้ามา หรืออย่างน้อยต้องมีข้อมูลในระบบอยู่แล้ว)
- (ใบสีส้ม) เกิด owner assigned
ตัวอย่างที่ 3
ต่อจากตัวอย่างที่แล้ว พอ Owner ถูก assigned ก็จะต้องถูก notified ว่าเขาถูก assigned แล้ว ซึ่งเกิดมาจาก
- (ใบสีม่วง) Event ‘Owner Assigned’ Trigger สร้าง policy ให้ไปบอกคนเมื่อกี้หน่อยว่าถูก assigned แล้ว
- (ใบสีน้ำเงิน) เกิด Command ที่ชื่อว่า Notify Owner
- Owner policy ก็จะไป Notify owner ผ่าน Notification Gateway (ใช้ใบสีชมพูกับ External System)
- (ใบสีส้ม) เกิด Event ที่ชื่อ “Owner Notified”
เมื่อเราใช้วิธีนี้แล้ว เราจะไม่ได้ส่งต่อ แค่ Screen design ให้กับทีม Delivery
แต่เราจะแปะการเล่าเรื่องผ่าน Event Storming Flow ไปให้เขาด้วย 🙂
หน้าที่ของ UX จะกลายเป็นคนที่ช่วย Facilitate ให้ User ดึงภาษาที่อยู่ในหัว UX ออกมา Model ไว้ อยู่ในรูปแบบที่ Developer เข้าใจ เพราะสิ่งที่ยากที่สุดของ Developer คือการ “ตั้งชื่อ” ว่าจะตั้งยังไงให้ Make sense และคนที่ตั้งชื่อได้ดีที่สุด คือ UX, QA หรือ User
จากนั้น Developer จะเอาชื่อเหล่านี้ ไป map เข้ากับ code ได้เลย!
จะทำให้ความเหมือนของภาษา ตั้งแต่ Level บนที่เราได้มา จนถึง Level ที่เราเขียน Code เหมือนกัน หมายความว่า ใครก็ตามที่มาอ่าน Journey ที่เราสร้างไว้ด้วย Event storming language กับอ่านจาก source code ก็จะเหมือนกัน
ส่งผลให้ เกิดเป็น Ubiquitous Language หรือภาษาที่ทำให้เราสื่อสารกันได้ ระหว่างคนที่อยู่ใน Domain ของ Business กับคนที่อยู่ใน Domain ของ Delivery ผ่านการคุยกันด้วย “Event”
กราฟจะกลายร่างเป็นแบบนี้ จะเห็นว่า ภาษาที่เกิดขึ้น จะไม่ห่างออกจากกันแล้ว ยิ่งถ้าเราเอาทั้ง 2 ทีม มาทำ Event storming flow ร่วมกันภาษาเหล่านี้ จะถูกเข้าไปอยู่ใน Flow ของ Developer ตั้งแต่ช่วงต้นๆ นั่นเอง
สำหรับบริษัทที่ยังแยก discovery กับ delivery ออกจากกันอยู่ ควรทำยังไง?
พี่รูฟแนะนำให้ คนที่ทำ Discovery พยายาม มีส่วนร่วมมากกว่า การแค่ Deliver UI ก็คือไปจนถึงการ Model Language ที่อยู่ในหัว user หรือของตัวเอง ออกมาด้วย แล้วส่งต่อสิ่งนี้ ไปให้ Developer
เมื่อสามารถทำได้ คำว่า “User Experience” ที่ focus ว่า ทำยังไงให้ user มีความสุขกับการใช้ Application ของเรา หรือ รู้สึกว่า Application ช่วยแก้ปัญหาให้เขาได้ จะไม่ได้อยู่เฉพาะ level บนแล้ว แต่จะครอบคลุมไปจนถึง level ของคนที่ทำ Delivery ด้วย ทำให้ Developer มี Experience ที่ดีในการพัฒนา Software
คำถามที่อาจจะสงสัยเกี่ยวกับ Event Storming
Q: Event storming ควรเกิดขึ้นในช่วงขั้นตอนไหน ของการทำงาน?
A: จริงๆ Event storming สามารถประยุกต์ใช้ได้กับทุกๆ part แต่สำหรับเนื้อหาในวันนี้ ควรจะอยู่ใน Part ที่เรากำลัง Release plan ว่าจะมี Journey ไหนบ้าง ที่กำลังจะมอบหมายเข้ามาใน Delivery team
Q: ควรระวังอะไรในการใช้งาน Event storming?
A: ต้องชวนคนที่มาทำให้เหมาะสม ทางที่ดีควรเป็นคนที่ทำงานใน Cross functional มาทุก Party
Q: นอกจาก Event storming แล้ว ยังมี tools อื่นๆอีกมั้ย ที่ช่วยแก้ปัญหานี้ได้?
A: ยังมีเครื่องมืออีกหลายตัวที่สามารถเข้ามาช่วยได้ เช่น Domain story telling (คล้ายๆ Sequence diagram ที่ไม่ซับซ้อนมาก คนทั่วไปสามารถอ่านได้) และ User Story Mapping ที่สามารถเอามาใช้ร่วมกับ event storming ได้
“สุดท้ายแล้ว สิ่งที่เราต้องพยายามทำ คือ ผสานคนที่ทำ Discover (UX Designer) กับคนที่ทำ Deliver (Developer) เข้าหากัน พูดภาษาเดียวกันได้”
คนฝั่ง UX ไม่จำเป็นต้องเขียน Code ได้ แต่สิ่งสำคัญคือ UX จะต้องส่งต่อภาษาที่ใช้อยู่ในหัว สร้างออกมาเป็นรูปเป็นร่าง แล้วส่งต่อมาให้ Developer ด้วย ถึงจะเป็นประโยชน์ต่อ Developer ได้ เพราะ Developer เก่งมากเรื่อง Tool แต่สิ่งที่ไม่ชำนาญคือไม่สามารถแปลงภาษาที่อยู่ที่ฝั่ง Business แปลงลงมาที่ code ได้ ถ้าเราทำได้ ของหลายๆอย่างใน Software Development จะถูก Unlock เพราะเรามีเครื่องมือในการสื่อสาร ระหว่าง Layer ที่อยู่ด้านหน้า (User) มาจนถึง Layer ที่อยู่ด้านหลังได้อย่าง Seamless มากขึ้น
และหากคุณชอบคอนเทนท์นี้ อย่าลืมกดไลก์ กดแบ่งปันให้เพื่อนๆ หรือคอมเมนต์กับพวกเราได้นะคะ และสามารถติดตาม content update ใหม่ๆ จาก PM Corner ได้จาก Facebook Page: PM Corner Thailand หรือทาง PM Corner Library ได้เลย!
