​📝ลูกค้าขอแก้ Requirement ตอนจะ Deploy! BAทำยังไง😱

หลายครั้งที่ปัญหา “ลูกค้าขอแก้ก่อน Deploy” ไม่ได้เกิดจากความดื้ออย่างเดียว แต่เกิดจากการ “เก็บ requirement” ตอนแรกยังไม่ครบ หรือยังไม่ชัดพอ พอใกล้ใช้งานจริงเลยเพิ่งนึกออกว่าอยากได้อะไรเพิ่ม/อยากตัดอะไรออก ฉะนั้นถ้าอยากลดดราม่าช่วงท้าย ๆ เราต้องกลับมาดูวิธีเก็บ requirement ให้แน่นตั้งแต่ต้นค่ะ สิ่งที่เราใช้เป็นประจำเวลาเก็บ requirement คือเริ่มจาก “เป้าหมายทางธุรกิจ” ก่อนเสมอ ไม่ใช่เริ่มจากหน้าจอหรือฟีเจอร์ เช่น ถามว่าอยากแก้ปัญหาอะไร, วัดผลความสำเร็จยังไง (KPI), อะไรคือสิ่งที่ห้ามพลาด (must-have) แล้วค่อยไล่ลงมาที่ flow การทำงานจริงของผู้ใช้ (as-is / to-be) วิธีนี้ช่วยให้เวลามีการเปลี่ยน จะย้อนกลับไปคุยบนเป้าหมายเดียวกันได้ ไม่ใช่เถียงกันด้วยความรู้สึก ระหว่างเก็บ requirement เราจะถามให้ครบ 5 มุมนี้เพื่อกันหลุด: 1) Who: ใครเป็นคนใช้ ใครอนุมัติ ใครรับผิดชอบข้อมูล 2) What: อยากได้ผลลัพธ์อะไร หน้าจอ/รายงานต้องมีข้อมูลอะไรบ้าง 3) When: ใช้เมื่อไหร่ ความถี่ ช่วงเวลาที่ระบบต้องรองรับ 4) Where: ทำบนอุปกรณ์ไหน/สาขาไหน/ช่องทางไหน 5) Why: ทำไมต้องมีฟีเจอร์นี้ ถ้าไม่มีจะกระทบอะไร อีกทริคที่ช่วยมากคือ “ยืนยันขอบเขต (scope) เป็นลายลักษณ์อักษร” ตั้งแต่ต้น เช่น มี in-scope / out-of-scope ชัด ๆ, เกณฑ์รับงาน (acceptance criteria) แบบข้อ ๆ และนิยามคำสำคัญ (เช่น “ลูกค้า” หมายถึงใคร, “ยอดขาย” นับจากอะไร) เพราะหลายเคสที่ต้องแก้ก่อน Deploy มาจากการตีความคำเดียวกันไม่เหมือนกันค่ะ ถ้างานมีความเสี่ยงเรื่องเปลี่ยนบ่อย เราจะทำ mini sign-off เป็นระยะ เช่น หลังจบ workshop ส่งสรุป requirement + open issue + decision log ให้ stakeholder ตอบกลับในอีเมลหรือคอมเมนต์ใน Jira/Confluence เพื่อให้มีหลักฐาน และช่วยล็อกความเข้าใจร่วมกัน สุดท้าย แนะนำให้เตรียม “คำถามกันพลาดก่อนขึ้นโปรดักชัน” ไว้ใช้เสมอ เช่น มีข้อมูลจริงทดสอบครบหรือยัง, มีเคสสุดโต่ง (edge case) อะไรบ้าง, ถ้าลูกค้าขอเพิ่มตรงนี้จะกระทบ timeline/budget/quality แค่ไหน เพื่อให้ตอนเกิด change request เราตอบได้เร็วและคุยกับทีม IT แบบมืออาชีพมากขึ้น