อย่าทำของแพง

คนเราชอบซื้อหวย ยิ่งเรารีบร้อนอยากจะรวยก็จะยิ่งซื้อบ่อย การพัฒนา Software เราก็รีบร้อนเหมือนกัน เราจึงพยายามทำงานแค่รอบเดียวให้เรียบร้อยสุด เพราะคิดว่านั่นเป็นหนทางที่สั้นที่สุดที่จะทำให้โครงการเสร็จ

ผมลัพธ์ที่ตามมาเป็นเรื่องปกติคือถูกกิน โครงการมักจะเสร็จไม่ทันเพราะโอกาสที่จะถูกในครั้งเดียวมันน้อยมาก มันจะต้องถูกแก้เป็นสิบรอบกว่าจะเริ่มลงตัว และการแก้แต่ละรอบก็ใช้เวลาในการแก้นาน ลองคิดดูว่าแก้แต่ละรอบต้องย้อนไปแก้ Sketch แล้ว export file ใหม่ ส่งให้กัน Programmer พอพัฒนาเสร็จก็ส่งไปตรวจอีกรอบ…แล้วก็แก้อีกรอบ…

ปัญหานี้เกิดซ้ำแล้วซ้ำอีก ดูเหมือนมันต้องเป็นแบบนี้อยู่แล้ว แต่ไม่จริงครับ ถึงแม้ว่าการแก้บ่อยๆ จะเป็นสิ่งจำเป็น แต่เราสามารถทำให้การแก้แต่ละครั้งมันราคาถูกได้ ปัญหาคือทีมงานถูกฝึกให้ทำของแพงมาตลอด ไม่รู้ว่ามีของถูกอยู่ในโลก จึงใช้เวลามากมายในการทำให้มันสวย ทำให้มันเหมือนจริง กว่าจะรู้ว่ามันยังไม่ใช่ก็เสียเวลาไปนานแล้ว

ทางออกของปัญหานี้คือการฝึกทำของราคาถูกครับ ผมจะเรียกของที่ใช้เวลาน้อยๆ ว่าเป็นของราคาถูกเพราะสิ่งที่แพงที่สุดสำหรับโครงการคือเวลา

แต่การจะทำของราคาถูกก็ไม่ใช่เรื่องง่ายๆ ครับ โดยเฉพาะกับผู้เชียวชาญ​หรือคนที่ทำงานสวยมาเยอะๆ อย่างในรูปตัวอย่างข้างบน ผมพยายามวาด Wireframe ด้วยโปรแกรม Sketch ครับ ตอนแรกพยายามวาดให้ออกมาเร็วๆ เพื่อให้เห็นภาพรวม แต่สุดท้ายก็เผลอลงรายละเอียดแบบ pixel perfect จนได้ พอเราเห็นว่ามันวางตำแหน่งมันไม่ลงตัวเราก็หยุดไม่ได้ที่จะปรับแต่งโน่นนิด นี่หน่อย หรือพอสีมันไม่ลงตัวเราก็จะเผลอปรับสีอยู่นั่นละ สุดท้ายแทนที่จะออกมาเร็วๆ ก็กลายเป็นช้า และกลายเป็นของราคาแพงจนได้ แล้วก็ใช่ว่าของแพงที่ทำออกมาจะใช้ได้เลย สุดท้ายก็ต้องถูกแก้อีกหลายรอบอยู่ดี

เพื่อป้องกันปัญหานี้เกิดขึ้นอีก ผมลองสรุปเทคนิคในการป้องกันการสร้างของแพงมาสามข้อ

ข้อแรก ให้เราคิดอยู่เสมอว่างานไม่มีทางถูกต้องในครั้งแรก ผมเคยเจอ supplier ที่เข้ามาทำ mobile application เค้าบอกว่าจะทำโปรแกรมออกมาเลย ไม่ต้องวาด Wireframe มาตรวจกันก่อนเพราะเสียเวลา!!! ผมนี่สยองขึ้นมาเลย สุดท้้ายก็ต้องแก้อยู่ดี แถมแก้ที่ระดับ code ซึ่งราคาแพงสุดเพราะใช้เวลามากที่สุด แพงกว่าการวาด sketch และ wireframe หลายเท่า ดังนั้นถ้าเราฝังหัวตัวเองว่า เราไม่ใช่ผู้ใช้ ยังไงการทดสอบแรกๆ มันมีความเสี่ยงสูง ทำให้ต้องถูกได้ยาก ทำยังไงก็ต้องถูกแก้ เมื่อเรารู้ว่ามันต้องถูกแก้อีกหลายรอบ เราจะเริ่มไม่ทำของแพงโดยอัตโนมัติ

ข้อที่สอง กำหนดระยะเวลาในการทำให้สั้นที่สุด ข้อนี้จะต่อจากข้อแรกคือเมื่อเราไม่ต้องการทำของแพงหลายรอบ เราก็จะหาทางแก้งานที่ราคาถูกที่สุดโดยอัตโนมัติ เช่นเราจะเริ่มกำหนดในใจว่างานต้องราคาไม่เกิน 3 วินาที

ในตัวอย่างแต่ละ post-it จะแทนแต่ละส่วนของหน้าเว็บ ซึ่งราคาไม่เกิน 3 วินาที เอามาต่อๆ กันในรูปแบบพร้อมแก้ นอกจากราคาในการสร้างจะถูกแล้ว ราคาในการแก้ก็ถูกด้วย แค่ย้าย post-it ราคาไม่เกิน 2 วินาที

เมื่อเราฝึกทำบ่อยๆ เราจะมีเทคนิคในการทำของราคาถูกมากขึ้นเรื่อยๆ และเริ่มตั้งสมติฐานก่อนการทำงานเพื่อจะได้เลือกวิธีที่ถูกที่สุดในการพิสูจน์สมติฐานนั้นๆ (มีเทคนิคในการทำของราคาถูกมากมาย ไว้จะมาเล่าใน blog ถัดๆ ไปนะครับ)

ข้อที่สาม ปรับราคาของงานตามผู้ทดสอบ หลังจากทำมาแล้วก็ต้องเอาไปทดสอบ การทดสอบกับทีมงานภายในโครงการ ที่นั่งวาดอยู่ด้วยกัน หรือนั่งอยู่ข้างๆ เราสามารถใช้การทดสอบแบบ postit เหมือนรูปในข้อสองได้เลย เพราะทีมงานที่ทำงานด้วยกันมาสามารถเข้าใจได้ง่าย สามารถวาดไปพร้อมๆ กันได้ และสามารถให้ feedback หรือช่วยกันปรับแก้ได้ทันที

แต่เมื่อเราเริ่มทดสอบกับคนนอกทีม เช่น Product Owner ที่มาคุยกับเราวันเว้นวัน เราก็จะวาดให้เห็นภาพรวมง่ายกว่า post-it ขึ้นมาอีกหน่อย

ส่วนของแพงอาจจะเก็บเอาไว้ให้ผู้บริหารที่มาคุยกับเราอาทิตย์ละครั้ง หรือลูกค้าที่เราเอางานไปส่ง ส่วนมากก็จะเป็น wireframe วาดบนคอมพิวเตอร์ หรือบน Powerpoint/Keynote แล้วของแพงสุดๆ ที่เห็นหน้าจอคล้ายจริง เริ่มมีข้อความอ่านรู้เรื่อง จะเก็บไว้ทดสอบกับผู้ใช้ (end user) ซึ่งราคาแพงเพราะต้องเชิญมาทดสอบ

ในการทำงานจริง ถ้าเราต้องแก้ซัก 100 รอบ ก็ขอให้แก้ใน postit ซัก 80 รอบ แล้วที่เหลือค่อยแก้บน Wireframe ราคาแพง ถ้าทำแบบนี้ได้เราจะประหยัดเวลาได้มาก และที่สำคัญคือประหยัดเวลาในการแก้บน code ไปมหาศาล

ดังนั้นถ้าโครงการไหนมีเวลาน้อยหรือมีงบน้อย ให้วาด wireframe กันเยอะๆ นะครับ อย่าคิดว่าทำงานรอบเดียวแล้วจะผ่าน อย่าพยายามซื้อหวยเลย โอกาสถูกมันน้อยมาก