[ATH2016] Dev Better With Design Principle
“คุณค่า” ของโปรเจคที่คุณกำลังทำอยู่ คืออะไร ?
พี่พีท Designer จาก ThoughtWorks Sydney มาเล่าให้เราฟังว่า Design Principle เนี่ย จะทำให้ developer ทำงานได้ดีขึ้นได้อย่างไร ลองไปดูกันครับ
หมายเหตุ : บางส่วนผมเขียนเพิ่มตามความเข้าใจของผมเองด้วย หากมองว่าผิดพลาดอย่างไรก็ทักท้วงกันได้เลยนะครับ
Understand Your Users
เคยไหมครับ ที่เราส่งมอบงานที่เรารู้สึกว่ามันเจ๋งมากๆ แต่ฝั่ง business หรือ ลูกค้า ไม่ชอบเอาซะเลย
ปัญหานี้ดูเป็นปัญหาที่เกิดขึ้นได้ง่ายมาก และเกิดขึ้นบ่อยๆ แม้แต่ตัวพี่พีทเองยังบอกว่าเมื่อไม่นานมานี้ไปทำ prompt pay ให้กับ SCB เขาใช้เวลาไปพักใหญ่ในการ craft stepper ที่มี animation เท่ๆ ขึ้นมาสำหรับการสมัคร พอทำเสร็จแล้วรู้สึกว่ามันเจ๋งมาก แต่สุดท้ายแล้วก็ไม่ได้ใช้ เพราะว่าจริงๆแล้ว เป้าหมายของหน้าสมัครไม่ได้ต้องการ animation สวยๆ แต่ต้องการให้สมัครง่าย และเร็ว เลยทำต้องเสียเวลาไปโดยเปล่าประโยชน์ และกลับไปทำมาใหม่
เพราะอะไรครับ?
พวกเรา Developer มักจะคิดไปเองว่า สิ่งที่เราคิด ที่เราทำออกมามันเจ๋ง เราอยากให้คนใช้ชอบมันเหมือนกัน แต่เราเอาตัวเองเป็นที่ตั้ง โดยไม่ได้รู้เลยว่าจริงๆ แล้วผู้ใช้ต้องการอะไรกันแน่ เราทำเพื่อผู้ใช้หรือทำเพื่อตัวเองกันแน่?
แล้วเราจะรู้ได้ยังไงว่าผู้ใช้ต้องการอะไร ?
ฟังดูเหมือนง่าย ใครๆก็พูด แต่หลายๆครั้งเราก็มักจะลืมตัว แล้วละเลยมันไป
อีกตัวอย่างนึงก็คือ พัฒนา UI โดยที่ไม่รู้ว่าเครื่องที่จะใช้เป็นยังไง ก็ตั้งใจทำ responsive ไป พอผ่านไป 2 อาทิตย์ ได้ไปลองกับเครื่องที่ใช้งานจริงๆ ปรากฏว่า resolution เป็น 800x600 ทำให้กลายเป็น mobile layout เลยต้องกลับมาแก้ใหม่อีก ยังดีที่เป็นแค่ 2 อาทิตย์ ถ้านานหลายเดือน ปัญหาจะต้องใหญ่กว่านี้แน่ๆ เพราะฉะนั้น fast feedback ก็สำคัญมากนะครับ บางทีถามอย่างเดียวก็ไม่พอ เพราะ user เองก็ไม่รู้ปัญหาเหมือนกัน
สุดท้ายแล้ว ถ้าเราไม่รู้ว่างานที่เราทำนั้น เป้าหมายมันคืออะไร รู้เพียงแค่ว่ามี requirement มาเป็นตัวอักษร แต่ไม่เข้าใจความต้องการของผู้ใช้จริงๆ ไม่เข้าใจเป้าหมายจริงๆ ของ feature นั้นๆ งานที่ออกมาที่เราคิดว่ามีคุณภาพดีมากๆ ก็มีแนวโน้มว่ามันจะไม่ได้ถูกนำไปใช้ประโยชน์ได้อย่างเต็มที่ครับ
Understand Your Value Creation
รู้รึเปล่าครับว่า feature ที่เราทำเสร็จไป
- ถูกนำไปใช้จริงมากแค่ไหน?
- ทำเงินให้มากพอที่จะครอบคลุมใช้จ่ายในการพัฒนาหรือเปล่า?
ทำไมเราถึงต้องสนใจเหรอครับ? ถ้าเราตอบคำถามเหล่านี้ได้ เราจะเข้าใจคุณค่าของสิ่งที่เราทำครับว่าจริงๆ แล้วอะไรคือคุณค่าของ project นี้ คุณค่าตรงนั้นแหละก็คือเงินที่เขาเอามาจ่ายคุณ ถ้าเราเข้าใจมันดี นอกจากจะโฟกัสได้ถูกจุด ทำให้งานมีคุณภาพมากขึ้นแล้ว ยังเอาไปต่อรองเรื่องค่าจ้างได้อีกต่างหาก
Understand Your Stakeholders
stakeholders ในที่นี้ มองในมุมที่ว่า เป็นคนที่คอขึ้นเขียงอยู่ครับ ถ้างานออกมาดีเขาก็อาจจะได้โบนัส แต่ถ้างานออกมาห่วยเขาก็จะซวยก่อน
ประเด็นคือ แล้ว stakeholders ได้ให้เราคุยกับลูกค้าหรือเปล่า? เขาบอกปัญหากับเรา หรือบอกวิธีแก้ปัญหากับเรา?
ถ้าปกติแล้ว เขาคิดวิธีแก้ปัญหาให้เรา แล้ววันนึงเขาเจอคนที่ ถูกกว่า เร็วกว่า มีประสิทธิภาพมากกว่า ถ้าเป็นแบบนั้น เค้าจะจ้างเราไปทำไม ?
คุณค่าของเราคืออะไรกันแน่ ?
เราแค่ “ขายของ” ให้ stakeholders หรือเราจะเป็น partner ของเขาดีครับ ?
ถ้าเขามาบอกเราว่า อยากให้ทำ app ให้ app นึง เราจะตอบว่า
“ประมาณ 6 เดือนเสร็จครับ”
หรือ
“ผมรู้ว่า app นี้จะสร้างคุณค่าให้คุณยังไง อีกหนึ่งเดือนผมจะทำบางอย่างขึ้นมาเพื่อดูว่ามันได้คุณค่าที่ต้องการหรือเปล่า”
เลือกแบบไหนดีครับ ?
ให้คุณค่าที่เราต้องการจะสร้างเป็นตัวขับเคลื่อนให้เราใส่ความพยายามลงไปให้ตรงจุดและเกิดประโยชน์มากที่สุดครับ ดีกว่าลงแรงเยอะๆ โดยไม่รู้ว่าทำไปเพื่ออะไรแน่นอน
Facebook, Google, Twitter พวกเขาไม่เคยหยุดพัฒนา พวกเขาเพิ่มคุณค่าให้กับโปรเจคขึ้นไปเรื่อยๆ เพราะฉะนั้น อย่าจบโปรเจคครับ
Woolworth’s Case Study
Woolworth นี่คล้ายๆ กับ Lotus บ้านเรา ที่มี Lotus ใหญ่ แล้วก็มี Lotus express ที่เป็นร้านเล็กๆ คุณค่าที่เขาต้องการก็คือเพิ่มยอดขายให้กับร้านเล็กของ Woolworth
ทีนี้ ไม่ใช่ว่ามีใบสั่งมาว่าต้องทำอะไร แล้วก็ทำตาม แต่หาทางที่น่าจะสร้างคุณค่าให้กับลูกค้าได้มากที่สุด ทำยังไงลองไปดูกันครับ
Designer Can Help You!
ลองทำความเข้าใจบทบาทของ designer ใน agile environment แล้วดูว่าเรา developer จะร่วมมือกับพวกเขาได้ยังไงบ้างครับ
คนมักจะเข้าใจว่า designer เนี่ยจะต้องสร้างสิ่งใหม่ๆ ตลอดเวลา นั่นคือมองไปข้างหน้า แน่นอนว่าเป็นสิ่งที่ต้องทำ
แต่ designer เองก็ต้องอยู่กับปัจจุบันเช่นกัน developer อาจจะให้ designer มานั่งข้างๆ เวลาที่กำลังเขียน UI อาจจะ optimize ไปถึงระดับ pixel ถ้า designer ให้เหตุผลได้ว่าทำแบบนี้จะเพิ่มคุณค่าให้กับงานได้อย่างไร developer เองก็จะมีใจอยากแก้ครับ หรือบางครั้ง ถ้า designer อยากให้เพิ่มบางอย่างแต่ส่งผลต่อ response time มากเกินไป developer เองก็ต้องแย้งครับ ประเด็นคือทีมต้อง share common goal ไม่ใช่ว่าเป้าหมายของ designer คือสวย ส่วนของ developer คือ performance ดี สุดท้ายก็จะเกิด conflict
อันนี้เป็นเรื่องของ วัฒนธรรมองค์กร และการวัดผลด้วย ถ้าทีมถูกวัดผลด้วยคุณค่าที่ผลงานของทีม generate ออกมา ทุกคนก็จะมีเป้าหมายเดียวกัน แล้วก็จะเดินไปทางเดียวกันครับ
นอกจากนี้ designer เองก็ต้องมองกลับไปเหมือนกันครับว่า ผลลัพธ์ของสิ่งที่ได้ทำไปแล้วเนี่ย มันเป็นอย่างที่ต้องการหรือเปล่า
ส่งท้าย
สุดท้ายนี้ คงต้องลองถามตัวเองให้แน่ใจว่า สิ่งที่เรากำลังทำอยู่มันสร้างคุณค่าให้กับลูกค้าหรือเปล่า ? หรือว่าเรากำลังหลงทางอยู่ แล้วเราได้ร่วมมือกับ designer แล้วหรือยัง เพื่อให้ผลงานของทีมนั้นสร้างคุณค่าออกมาได้มากที่สุด
