ก่อนตอบว่า “ทำไม่ได้” ลองแยกคำขอออกเป็น 4 ช่อง

คำขอกับเป้าหมายจริงอาจเป็นคนละเรื่อง Framework 4 ช่องช่วยให้ Developer และ BA มองหา Solution ที่เล็กกว่า ปลอดภัยกว่า และยังส่งมอบผลลัพธ์ที่ Business ต้องการ

วันนี้อยากมาแชร์เรื่องราวที่เหล่า Developer ทุกคนต้องเคยเจอเมื่อต้องทำงานกับฝั่ง Business

หลายคนคงเคยเจอ BA หรือ PM ขอให้ทำบางอย่างกับระบบหรือฟีเจอร์ที่เสร็จไปแล้ว และนั่นคือความน่าปวดใจอย่างหนึ่ง

เพราะแม้กระทั่งคำขอเล็กๆ อาจกระทบหลายฟีเจอร์ที่ใช้งานได้และผ่านการทดสอบเรียบร้อยแล้ว

แต่ก่อนจะตอบว่า “ทำไม่ได้” ลองแยกคำขอออกเป็น 4 ช่องก่อน

เคยมีคนขอให้ตองทำ Flow หนึ่งในระบบให้ใช้งานได้จริง เพื่อให้อีกทีมเข้ามาทดสอบ ภายใต้ Environment ที่ไม่รองรับการทดสอบนั้น ทำให้การทดสอบลำบากมากขึ้น

ตอนแรกตองพยายามหาวิธีทำตามคำขอนั้นตรงๆ แต่พอไล่ดูข้อจำกัดแล้วพบว่า

Environment สำหรับทดสอบไม่รองรับ
Production ไม่เหมาะกับการนำมาใช้ทดสอบ
ถ้า Bypass Flow เดิม อาจกระทบระบบส่วนอื่น

ถ้ามองจากคำขอเพียงอย่างเดียว คำตอบอาจกลายเป็น “ทำไม่ได้”

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

แต่ก่อนจะสรุปแบบนั้น ตองลองกลับไปถามใหม่ว่า

“เป้าหมายของงานนี้คืออะไร”

คำตอบคือ อีกทีมไม่ได้ต้องการทดสอบ Flow ทั้งหมด

เขาแค่ต้องการข้อมูลที่มีสถานะหนึ่ง เพื่อนำไปทดสอบการดึงข้อมูลและแสดงผลในระบบของเขา

จากงานที่ดูเหมือนต้องแก้ Flow ใหญ่ จึงกลายเป็นการสร้าง Mock data ชุดเล็กๆ ที่ช่วยให้อีกทีมทดสอบต่อได้ โดยไม่ต้องเสี่ยงแก้ระบบหลัก

เหตุการณ์นี้ทำให้ตองเห็นว่า คำขอกับเป้าหมายจริงอาจเป็นคนละเรื่องกัน

ก่อนเริ่มประเมินหรือลงมือทำ ลองแยกคำขอออกเป็น 4 ช่อง

What they asked
เขาพูดว่าอยากให้เราทำอะไร
Desired outcome
ผลลัพธ์สุดท้ายที่เขาต้องการคืออะไร
Constraints / risks
วิธีที่ขอมีข้อจำกัด ใช้เวลามาก หรือมีความเสี่ยงกับระบบตรงไหนบ้าง
Smallest useful solution
มีวิธีที่เล็กกว่าและปลอดภัยกว่า แต่ยังส่งมอบผลลัพธ์เดียวกันได้ไหม

Requirement ที่เราได้รับไม่จำเป็นต้องกลายเป็นวิธี Implementation ตามคำพูดแรกเสมอไป

หน้าที่ของ Developer หรือ BA ไม่ใช่แค่รับคำขอแล้วรีบตอบว่าทำได้หรือทำไม่ได้

แต่คือการช่วยหาให้เจอว่า จริงๆ แล้ว Business ต้องการผลลัพธ์อะไร และมี Solution ไหนที่ตอบเป้าหมายนั้นได้ดีที่สุด

ก่อนเริ่มงานชิ้นถัดไป ลองถามเพิ่มอีกหนึ่งคำถามว่า

“ถ้าไม่ทำตามวิธีที่ขอ เรายังส่งมอบผลลัพธ์เดียวกันได้ไหม?”

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