📝 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

2/13 Edited to

จากประสบการณ์จริงที่เคยทำงานในโปรเจ็กต์ IT หลายครั้ง พบว่าการที่ลูกค้าแก้ Requirement แบบกะทันหันก่อน Deploy มักทำให้ทีมเกิดความเครียดและเกิดความสับสนได้ง่ายมาก สิ่งแรกที่เราควรทำคือใจเย็นและเปิดรับฟังเหตุผลอย่างละเอียด เพราะหลายครั้งเหตุผลเหล่านั้นมักเกี่ยวข้องกับความจำเป็นทางธุรกิจที่ลูกค้าต้องเจอจริง ๆ ซึ่งการเปิดใจรับฟังจะช่วยให้เราเข้าใจภาพรวมของงานมากขึ้น และสามารถแปลงความต้องการใหม่ให้อยู่ในขอบเขตที่เป็นไปได้ ขั้นตอนถัดมาคือการวิเคราะห์ผลกระทบที่แก้ไขดังกล่าวจะส่งผลอย่างไรต่อแผนงาน ไม่ว่าจะเป็นเรื่องของระยะเวลา (Timeline) ที่อาจต้องเลื่อน Deploy, งบประมาณ (Budget) ที่อาจเพิ่มขึ้น หรือปัญหาด้านคุณภาพ (Quality) ที่อาจเกิดขึ้น โดยการแจ้งข้อมูลที่ชัดเจนให้กับทุกฝ่ายช่วยให้ตัดสินใจด้วยข้อมูลจริงและลดความเข้าใจผิด อีกประเด็นสำคัญคือการนำเสนอทางเลือกที่ทำให้ทุกฝ่ายได้ประโยชน์ เช่น แลกเปลี่ยนฟีเจอร์บางอย่างไปยังรอบถัดไปหรือปรับลดขอบเขตงานในบางส่วน เพื่อให้โครงการยังเดินหน้าได้ในกรอบเวลาที่กำหนด วิธีการนี้ช่วยลดความเกิดความขัดแย้งและสร้างบรรยากาศการทำงานแบบร่วมมือกันมากขึ้น สุดท้ายอย่าลืมบันทึกข้อตกลงและการเปลี่ยนแปลงลงในระบบที่ใช้งาน เช่น Change Request, Email หรือ Jira เพื่อป้องกันความสับสนที่จะเกิดขึ้นภายหลัง เพราะหลายครั้งปัญหาใหญ่มีสาเหตุมาจากการไม่มีเอกสารยืนยันการตกลงแก้ไข ส่วนตัวผมมองว่า การรับมือสถานการณ์เปลี่ยน Requirement ก่อน Deploy นั้น ต้องอาศัยทั้งทักษะการสื่อสาร การวางแผน และความพร้อมในการปรับตัวตามสถานการณ์จริง เทคนิคเหล่านี้ไม่ได้ช่วยแค่ BA เท่านั้น แต่ยังมีประโยชน์สำหรับทีม IT และผู้มีส่วนเกี่ยวข้องในการผลักดันโครงการให้สำเร็จอย่างมีประสิทธิภาพครับ