คำเตือนก่อนทำ Sprint !
หลังจากลองทำ prototype เสร็จ เราก็ test กับ user เพื่อหาคำตอบว่าตกลงสิ่งที่ช่วยกันทำมานั้นถูกทางแล้วหรือยัง ปัญหามันอยู่ตรงที่ว่า prototype ที่เราทำขึ้นมานั้น ไม่ได้แก้ปัญหาตั้งต้นที่เราคิดกันไว้….
สำหรับผู้อ่านที่ยังไม่รู้ว่าอะไรคือ Sprint ผมขออธิบายคร่าวๆว่า sprint เป็นกระบวนการคิดที่จับกลุ่มกันประมาณ 5- 10 คนเพื่อหาคำตอบและทดสอบกับ target user ว่าคำตอบที่ช่วยกันคิดมานั้นสามารถแก้ปัญหาได้หรือไม่ ข้อดีก็คือทั้งทีมได้ข้อสรุปที่ชัดเจนและช่วยตัดการเถียงกันเองภายในทีม โดยปกติแล้ว sprint จะใช้เวลาประมาณ 5 วัน ถ้าให้สรุปสั้นๆคือ วันที่ 1 — ค้นหาปัญหาหรือตั้งเป้าว่าต้องการจะทำอะไร, วันที่ 2 — หาทางออกของปัญหา, วันที่ 3 — เลือกทางออกที่ดีที่สุดเพื่อทำ prototype, วันที่ 4 — สร้าง prototype ที่ง่ายและรวดเร็ว แต่ใกล้เคียงกับทางออกสุดท้ายมากที่สุด, วันที่ 5 — ทดสอบ prototype กับ user และเก็บ feedback
เรื่องราวมีอยู่ว่า…
แรกเริ่มเดิมทีเราเริ่มทำ sprint เพราะกำลังจะมี feature ใหม่เสริมเข้าไปในระบบเพื่อทำให้ user ใช้ระบบได้มีประสิทธิภาพยิ่งขึ้น แต่ช่วงที่ทำ sprint กันคงจะเพลินเกินไปหน่อย เลยกลายเป็นว่าเราดันไปแก้ปัญหา UI ของเดิมแทนที่จะโฟกัสกับ feature ใหม่ ซึ่งส่วนหนึ่งอาจจะเป็นเพราะว่าสิ่งนี้เป็นปัญหาที่ติดอยู่ในใจมาสักพักแล้วแต่ต้องใช้เวลานานในการแก้ไขเลยโดนมองข้ามมาตลอด ไม่ว่าจะยังไงเมื่อเราแก้ปัญหากันผิดจุด สิ่งที่ตามมาก็คือปัญหาที่จำเป็นต้องแก้ก็ไม่ได้คำตอบ ส่วนคำตอบของปัญหาที่เราหากันมาได้ก็จบแบบครึ่งๆกลางๆ เพราะว่าไม่มีเวลาเอาไปพัฒนากันต่อ
เลยได้เป็นข้อคิดว่าถ้ามีโอกาสทำ sprint กันอีกครั้ง คงต้องเตือนกันเองให้ไม่หลุดหรือหลงทางไปกลางคัน บางทีถ้าเราแปะกระดาษแผ่นใหญ่ๆที่เขียนปัญหาไว้หน้าห้องที่ทำ sprint ตอนเริ่มต้น เราอาจจะได้คำตอบไปแล้วก็ได้…
