UX จะเปล่งแสงในทีม Agile ได้อย่างไร
คนที่ทำงานด้าน Design หรือด้าน User Research มักถูกจับให้อยู่นอกทีม Agile (Development Team) เป็นประจำ หน้าที่ของเราคือช่วย PM เตรียมของ ออกแบบหน้าจอให้เสร็จก่อนที่ทีมจะเอาไปพัฒนา
แล้วมาวันนึงเค้าก็มีแนวโน้มจะให้เราเข้าไปอยู่ในทีม Agile หรือใคร ๆ ก็บอกว่า UX ต้องอยู่ในทีมนะ ที QA ยังอยู่ในทีมเลย แล้วทำไม UX ไม่อยู่ด้วยล่ะ… 😅เอาแล้วไง ถ้าเข้าไปอยู่ในทีมแล้วยังทำเหมือนเดิมต้องไม่ทันแน่ ๆ เลย กว่าเราจะตีโจทย์ กว่าจะออกแบบเสร็จ ไหนจะต้องทดสอบอีกว่าผู้ใช้เข้าใจจริง ๆ หรือเปล่า เราน่าจะเหลือเวลาให้ทีมพัฒนาแค่นิดเดียวแน่ ๆ… 🤔 แสดงว่าเค้าไม่ได้ทำแบบที่เราคิดสินะ
ก่อนจะไปดูว่าควรทำอย่างไร มาดูพื้นฐานความคิดของคนที่ทำ Agile กันก่อนดีกว่า คนที่เลือกนำแนวคิดนี้มาใช้เค้ามีความเชื่อเหมือนกันอยู่ 4 ข้อ เรียกว่า Agile Manifesto (อ่านฉบับแปลไทย) เป็นแนวคิดพื้นฐานที่ทำให้เรามองการพัฒนาโปรแกรม ไม่เหมือนกับการพัฒนาถนนหรือตึก เพราะธรรมชาติของมันไม่เหมือนกัน ตัวแปลต่าง ๆ ไม่เท่ากัน เช่น ราคาค่าเปลี่ยนมันแพงขึ้นได้ถูกลงได้ หรือมันไม่ต้องทำให้เสร็จมันก็ใช้งานได้เยอะแล้ว หรือทีมวิศวกรรมไม่ได้ทำหน้าที่ออกแบบแต่เป็นคนสร้างมันเองกับมือ เป็นต้น
แทนที่จะจำเป็นข้อความผมอยากให้ลองจำเป็นรูปภาพดูครับ ภาพด้านบนจะแบ่งเป็น 4 รูป แต่ละรูปจะบอกว่าให้พยายามให้น้ำหนักกับการทำงานด้านซ้าย ให้มากกว่าด้านขวา เราลองมาลงรายละเอียดที่ละความเชื่อนะครับ
1. Individuals and interactions over processes and tools
แปลไทยว่า “คนและการมีปฏิสัมพันธ์กัน มากกว่าการทำตามขั้นตอนและเครื่องมือ” นั่นคือทีม Agile จะให้ความสำคัญกับความคิดของแต่ละบุคคล และการพูดคุยสื่อสารทำความเข้าใจซึ่งกันและกัน มากกว่าการกฏของการทำงาน (โดยเฉพาะกฏที่ทำต่อ ๆ กันมาโดยที่เราก็ไม่เข้าใจว่าทำไมเค้าออกกฏแบบนั้น) หรือการอ้างว่าเครื่องมือมันบังคับให้เราทำแบบนี้ เราจึงไม่คุยกัน
ส่วนนี้คนทำ UX เข้ามาช่วยได้มากครับ เพราะเราชอบเข้าใจคนอยู่แล้วทำให้เราเข้าใจทั้งคนออกแบบ คนสร้าง และคนคิดแผน โดยเฉพาะอย่างยิ่งการยึดผู้ใช้เป็นจุดร่วม มันจะเป็นกาวใจให้ทุกคนในทีมหันมาร่วมมือกัน
2. Working software over comprehensive documentation
แปลไทยเป็น “ซอฟต์แวร์ที่นำไปใช้งานได้จริง มากกว่าเอกสารที่ครบถ้วนสมบูรณ์” ในงานก่อสร้าง หรืองานโรงงาน สิ่งที่วิศวกรต้อทำมันให้เสร็จคือแบบแปลน ในนั้นต้องมีรายละเอียดที่ครบถ้วน เก็บรายละเอียดในทุกแง่มุม เพื่อให้แน่ใจว่ามันจะใช้งานได้ หลังจากที่โรงงานเอามันไปผลิต
ดังนั้นในการพัฒนาโปรแกรมในยุคแรก ๆ ที่เรายืมกระบวนการมาจากโรงงาน หรือการก่อสร้าง เราจึงให้ความสำคัญกับเอกสารมากๆ แต่แล้วเราก็มาพบความจริงว่าในโลกของโรงงานเราไม่ได้สนใจของชิ้นแรกเอกสารต่าง ๆ ของเราสร้างมาเพื่อทำให้ของชิ้นที่สองออกมาเหมือนชิ้นแรก ตัวแปลต่าง ๆ เราจึงรู้หมด ควบคุมได้หมดแล้วสามารถเขียนเอกสารได้ แต่การพัฒนาซอร์ฟแวร์มันไม่เคยมีชิ้นที่สองเราทำแต่ของชิ้นแรก ซึ่งไม่เคยมีมาก่อนมันจึงมีตัวแปลที่ไม่รู้ค่าเยอะมาก
ดังนั้นแทนที่จะสนใจตัวเอกสาร เราจะมุ่งความสนใจไปที่ตัวซอร์ฟแวร์ที่นำไปใช้งานได้ซะเลย แล้วทำเอกสารเท่าที่จำเป็น เอกสารไหนทำแล้วไม่มีคนใช้ หรืออ่านแค่รอบเดียวก็เลือกที่จะไม่ทำดีกว่า
3. Customer collaboration over contract negotiation
แปลไทยได้แบบนี้ “ร่วมมือทำงานกับลูกค้า มากกว่าการต่อรองให้เป็นไปตามสัญญา” พื้นฐานสำคัญของข้อนี้ (ที่คนทำ UX จะรู้ดี) คือคำตอบไม่ได้มีแบบเดียว และของดีที่สุดมันขึ้นอยู่กับสถานการณ์ ไม่ได้มีอะไรตายตัว ดังนั้นการทำตามสิ่งที่ตกลงกันไว้ก่อนแล้วจึงมีความเสี่ยงสูงมาก เวลาพัฒนาจริงจะไปเจอปัญหาที่คาดไม่ถึงแน่ๆ หรือตอนใช้งานจริงมันมักจะไม่ได้ผลอย่างที่คิดเอาไว้
ใน Agile เราเลยเชื่อว่าการทำงานร่วมกับลูกค้า มีปัญหาอะไรก็ช่วยกันปรับปรุงแก้ไขคำตอบ ให้มันเข้ากับสถานการณ์ แทนที่จะบอกว่า “คุณเซ็นแล้ว ต้องทำตามสัญญาสิ” การทำแบบนั้นก็จะทำให้เจ็บกันทั้งสองฝ่าย นักพัฒนาก็ต้องจำใจทำของที่ทำยากทั้งๆ ที่ทำแบบง่าย ๆ ก็ได้ผลเหมือนกัน และ เจ้าของโปรแกรมก็ปรับเปลี่ยนไม่ได้แม้ว่าสิ่งที่กำลังทำอยู่มันจะเอาไปใช้จริงได้ยากก็ตาม
ถ้าใครทำ UX อยู่แล้วยึดตามเอกสารเป็นสำคัญ เมื่อมีปัญหาอะไรแทนที่จะหาทางแก้กลับไปยึดเอกสารเป็นตัวตั้ง อันนี้เราก็จะทำงานกับทีม Agile ยากหน่อย แต่เรื่องนี้มักเจอน้อยครับ เพราะทีม UX มักเสียงเบา ปัญหาที่มักจะเจอคือทุกคนอยากเปลี่ยนหมด แต่ค่าทำเอกสารเพื่อเปลี่ยนมันดันแพงกว่าค่าเปลี่ยนนี่สิ เนื่องจากกระบวนการในการเปลี่ยนมันออกแบบมาให้เปลี่ยนอย่างรอบคอบ สุดท้ายเลยไม่ได้เปลี่ยนทำให้เสียกันไปมด
4. Responding to change over following a plan
ข้อนี้คือ “การตอบรับกับการเปลี่ยนแปลง มากกว่าการทำตามแผนที่วางไว้” ผมมองว่าข้อสุดท้ายนี้ลึกซึ้งมากๆ การจะตอบรับความเปลี่ยนแปลงได้เราต้องวางแผนให้ระบบของเรามีค่าเปลี่ยนที่ไม่แพงมาก คือออกแบบมาให้เปลี่ยนตั้งแต่แรก
ลองมาคิดดูนะครับ ถ้าสิ่งที่เราออกแบบไม่ได้วางแผนแค่ “เปลี่ยนได้” แต่กลายเป็น “เปลี่ยนแน่นอน” เราจะใส่พลังลงไปในแผนแต่ละช่วงไม่เท่ากัน ของที่ใกล้จะเอาไปทำเราก็จะลงรายละเอียดเยอะหน่อย ส่วนของที่อีกนานกว่าจะเอาไปทำเราก็จะใส่พลังน้อยๆ เพราะมันอาจจะไม่เคยเอามาทำเลยก็ได้
ถ้ามองลึกลงไปมากกว่านั้น การที่เราจะเปลี่ยนแผนมันควรเกิดจากการที่เราเอาของที่เราสร้างขึ้นมาแล้วไปทดสอบว่ามันใช้งานได้หรือไม่ได้อย่างไร มันให้คุณค่ากับผู้ใช้อย่างที่เราวางแผนเอาไว้หรือเปล่า เมื่อเราได้คำตอบเราถึงจะย้อนกลับมาปรับแก้มันได้อย่างถูกต้อง
ลึกลงไปมากกว่านั้นอีก เราจะหั่นของตามงานที่ทำไม่ได้แล้ว เช่น ทำ database ทำ business logic ทำ frontend แต่ต้องมาหั่นของตามคุณค่า เราอยากมอบเครื่องมืออะไรให้ผู้ใช้นำไปแก้ปัญหา เมื่อเค้าใช้ของชิ้นที่เราหั่นออกมาแล้ว มันต้องมอบคุณค่าให้เค้าได้สมบูรณ์ในชิ้นนั้นเลย เราจึงจะเอาไปทดสอบได้ ซึ่งคุณค่าเหล่านี้คนทำ UX รู้ดีเพราะเราเข้าใจว่าผู้ใช้มีปัญหาอะไรและต้องการอะไรไปแก้ปัญหา
จากทั้ง 4 ข้อ ผมคิดว่าคนทำงานด้าน UX จะเริ่มรู้แล้วว่าพวกเรามีบทบาทขนาดไหนในการที่จะช่วยให้ทีมสามารถทำงานแบบ Agile ได้ ทั้งหน้าที่ในการสื่อสาร หน้าที่ในการพาคนมาคุยกัน หน้าที่ในการพาผู้ใช้มาเป็นกาวใจ หน้าที่ในการนำของไปทดสอบ แต่หน้าที่ทั้งหมดให้ทำในเวลาสั้น ๆ คงเป็นไปได้ยากหน่อย
หน้าที่ของคนทำ UX จึงแบ่งเป็น 3 ช่วงเวลา
ช่วงแรกคือการเตรียมของ (ขวาสุด, Future sprint) เพราะยังไงทีมก็ต้องวางแผนล่วงหน้า ของที่ใกล้ๆ จะเอาเข้าไปทำเราก็ต้องลงรายละเอียดเยอะหน่อย ส่วนของไกลๆ เราก็ลงไว้คร่าวๆ หรือลองเอาไปทดสอบก่อนก็ได้ ถ้ามันมีแนวโน้มที่จะไม่สำเร็จเราจะได้ไม่ต้องให้ทีมเอาไปทำ ส่วนอะไรที่มั่นใจมากแล้วเราและทีมก็จะได้ใส่พลังลงไปให้เต็มที่
ช่วงที่สอง ทีมกำลังสร้างของ (กลาง, Current sprint) แน่นอนทีมยังไม่เคยทำของสิ่งนี้มาก่อน เค้าจะต้องไปชนตอแน่ ๆ ตอนแรกอาจคิดว่าไม่มีปัญหาเพราะเคยทำมาแล้ว แต่กลายเป็นว่าโปรแกรมที่เคยใช้อยู่มันเปลี่ยนเวอร์ชั่น ทำให้ทำแบบเดิมไม่ได้ ของที่ว่าจะง่ายกลายเป็นยากสุด ๆ อันนี้ทีม UX สามารถเข้าไปช่วยได้ ถ้าตรงไหนที่ยากก็ปรับไปใช้แบบอื่นที่ง่ายขึ้นสิ คำตอบไม่ได้มีแบบเดียวนี่นา
ช่วงที่สาม เป็นตอนที่ทีมทำเสร็จแล้ว (ซ้ายสุด, Past sprint) คนทำจะรู้ดีว่าของที่ทำเสร็จไม่ได้แปลว่ามันมีคุณค่า ถ้าผู้ใช้ไม่ยอมใช้มันของชิ้นนั้นก็มีคุณค่าเท่ากับศูนย์ ดังนั้นเราจึงมีหน้าที่เอามันไปทดสอบให้แน่ใจว่ามันแก้ปัญหาให้ผู้ใช้ได้จริงมัน มันตอบแทนคนที่ลงทุนจ้างเรามาพัฒนาได้แค่ไหน และจะทำให้มันดีขึ้นได้อย่างไร
ถ้าเราเข้าใจเบื้องลึกของการทำงานแบบ Agile การที่เราจะเข้าไปอยู่ในทีมก็ไม่ใช่เรื่องยาก มันอาจจะยากหน่อยที่คนทำ UX จะต้องไปเข้าใจทั้งผู้ใช้ ธุรกิจ และ เทคนิคอล แต่ถ้าทำได้เราเองจะมีบทบาทสำคัญในการลดงาน ลดความเสี่ยง ลดปัญหาให้กับทีมได้อย่างมากมาย เป็นหนึ่งในผู้เล่นที่เปล่งแสงของความหวังและความมั่นใจ ให้กับผู้ร่วมทีมครับ
ถ้าสนใจเรื่อง UX หรือเรื่องการพัฒนา Software Product อยากให้ลองอ่านบทความอื่นๆ ของเราดูนะครับ หรือถ้าสนใจ Workshop อยากให้ลองดูของ UX Academy หรือ Skooldio นะครับ
😁👍
