📝 customers ask to fix Requirements when will Deploy! BA do?😱
The problem of the BA and IT team. When you experience "Requirements," don't panic! Try 4 Step to cope with the pro.
✅ 1. Stop & Listen (Calm down and listen)
Don't immediately refuse (Say No) to listen to the "business reasons" why he needs to solve it now. Sometimes it can be critically urgent that we really need to solve.
✅ 2.Impact Analysis (Impact Analysis)
Inform the impact to the Stakeholder. Don't just say "can't do it," but say:
⏰ Timeline: How many days will Deploy have to be postponed?
Budget 💰: Is there an extra cost or resource required?
🛠️ Quality: Is there any point of increased risk of collapse?
✅ 3.The Trade-off (Offer Win-Win Alternative)
A good BA has to offer a solution. Let's talk about it:
"If you want to take this feature quickly, can we put the B feature on the front Sprint instead?"
Alternative negotiation reduces conflict better than just rejection.
✅ 4.Document Everything (Record of Evidence)
Most importantly! Once agreed, don't forget to always make a Change Request (CR) or Memorandum through Email / Jira to prevent future "Unrecognizable" or "Unsaid" problems.
💬 Who has ever encountered a peak case like this? How does the team handle it? Comment share experience!
# BA # BusinessAnalyst # IT # Working age # Work life review# Office # SoftSkill # Office man # Developer
หลายครั้งที่ปัญหา “ลูกค้าขอแก้ก่อน 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 แบบมืออาชีพมากขึ้น
