ปกติเวลาทำระบบ ผมไม่ได้มี “เฉลยวิธีสร้าง” อยู่ในมือครับ ผมเริ่มจาก ข้อกำหนดและความต้องการที่ระบบควรทำได้ แล้วใช้ความสามารถทั้งหมดที่มีออกแบบการทำงานให้ตอบโจทย์ หาทางออกที่พอเหมาะกับลูกค้า งานของผมจึงมีทั้งการคิดว่าควรได้อะไรจากระบบ และการช่วยหาว่าจะทำให้เกิดขึ้นอย่างไร
แต่รอบ Trip Planner ผมตั้งใจยืนในระดับ User ครับ บทบาทหลักของผมคือคิดว่าสิ่งที่ควรได้จากระบบมีอะไรบ้าง เขียนเป็น ข้อกำหนดและความต้องการที่ระบบควรทำได้ แล้วตอบคำถาม AI จากนั้นอ่านสิ่งที่ AI สรุปกลับมาว่าตรงกับที่ผมต้องการหรือไม่
ช่วงอ่าน ข้อกำหนดและความต้องการที่ระบบควรทำได้ ผมได้ความรู้สึกแบบ User ทั่วไปจริงๆ ครับ อ่านแล้วเหมือนจะรู้เรื่อง เหมือนสิ่งที่คุยกันถูกจับลงกระดาษครบแล้ว แต่พอปล่อยให้ AI ทำงานและเห็นหน้าจอที่สร้างขึ้น ความเข้าใจจากเอกสารก็ยังไม่รับประกันว่าผมจะใช้งานระบบได้
โปรแกรมรุ่นแรกที่สร้างขึ้นตาม Requirement ใช้งานไม่ได้สำหรับผมครับ ตอนลองมีทั้งจุดที่แก้ข้อมูลแล้วการ์ดยังไม่อัปเดต กับทางเดินในหน้าจอที่ผมหาไม่เจอ ผมจึงยังทำงานตามโจทย์ไม่สำเร็จและต้องคุยทำความเข้าใจกันยกใหญ่ ผมบอกว่ากำลังพยายามทำอะไร อะไรในหน้าจอทำให้สับสน และสิ่งที่เห็นตอบโจทย์ที่ตั้งไว้หรือยัง ช่วงนี้ทำให้ผมเห็นว่า ข้อกำหนดและความต้องการที่ระบบควรทำได้ ที่อ่านเข้าใจได้ กับระบบที่ผู้ใช้ลงมือทำงานได้ เป็นคนละด่านของการตรวจรับ
หลังจากนั้นผมปล่อยให้ AI ทำงานต่อ แล้วกลับมาทำหน้าที่อีกครั้งในขั้น การทดลองใช้และตรวจว่าระบบทำงานตามความต้องการหรือไม่ ตรวจระบบที่เตรียมส่งมอบว่าพอเห็นและเข้าไปใช้งานแล้วตอบโจทย์ผมจริงไหม งานเดินคล้าย วงจรพัฒนาซอฟต์แวร์ ตั้งแต่เก็บความต้องการ ออกแบบ สร้าง ทดสอบ ไปจนส่งมอบ ที่คุ้นเคยครับ เพียงแต่รอบนี้ผมยืนอยู่อีกฝั่งหนึ่งในฐานะ User และยังมีอีกขาที่คอยคุมงาน AI โดยไม่ต้องเข้าไปคุมวิธีทางเทคนิค
สำหรับผม การได้เล่นบท Real User สนุกไปอีกแบบครับ ก่อนหน้านี้ผมอยู่ฝั่ง Developer เกือบตลอด พอมายืนอีกฝั่งถึงเห็นความต่างระหว่างการรู้ว่าระบบควรทำอะไร กับการมองหน้าจอแล้วต้องหาทางทำสิ่งนั้นให้สำเร็จ ผมยังใช้ประสบการณ์เดิมช่วยคุมงาน AI อยู่ แต่ได้สัมผัสมุมที่ผู้ใช้ต้องเจอจริงมากขึ้น
ในวงจรพัฒนาซอฟต์แวร์ การตรวจรับเป็นหน้าที่สำคัญของ User ครับ เพราะเมื่อรับ Software ไปแล้ว ผู้ใช้ต้องทำงานกับระบบนั้นต่อไปอีกนานจนกว่าจะมี Version ใหม่ การตรวจรับจึงควรดูว่าระบบตรงกับงานจริงและใช้งานต่อเนื่องได้หรือไม่ ไม่ใช่เพียงดูว่าทีมพัฒนาทำงานเสร็จแล้วหรือยัง บทบาทของ User ในการยืนยันความต้องการและทดลองใช้ก่อนรับมอบจึงสำคัญกับซอฟต์แวร์ที่จะต้องอยู่กับผู้ใช้ต่อไป
