Bối cảnh

  • Hệ thống đã được dev xong, UT xong, đang chờ release
  • Khách bất ngờ gửi mail vào 6h chiều thứ 6:

    “Sau khi kiểm tra lần cuối, xin lỗi nhưng chúng tôi muốn đổi lại cách xử lý phần import.”

👉 Mình sững người. Vì nếu đổi logic đó thì ảnh hưởng đến cả mapping và cấu trúc dữ liệu.

Phản ứng ban đầu (sai lầm)

  • Mình trả lời ngay lập tức trong lúc đang hoảng: “OK, chúng tôi sẽ xử lý.”
  • Dev thì đã về – không ai confirm được độ ảnh hưởng
  • QA thì cũng đã freeze test case

➡️ Cả team quay lại làm, sửa gấp → cuối cùng bug phát sinh vì test không kịp cập nhật.

Mình rút ra điều gì?

  1. Đừng trả lời khi chưa xác minh tác động
    → Tốt hơn nên trả lời:

    “Cảm ơn anh/chị. Mình sẽ xác minh độ ảnh hưởng và phản hồi sớm nhất vào sáng thứ 2.”

  2. Cần check các phần liên quan trước khi đồng ý bất cứ thay đổi nào

    • Có ảnh hưởng logic khác không?
    • Dev có resource không?
    • QA có kịp viết lại test?

  3. Việc gấp không có nghĩa là phải gật đầu ngay
    → Khách tôn trọng người có lý lẽ hơn người chỉ biết nói vâng.

Lần sau – mình xử lý khác đi

  • Gửi mail xác nhận lại request rõ ràng (bằng tiếng Nhật)
  • Gọi 15’ với dev lead để đánh giá độ ảnh hưởng
  • Gửi proposal cho khách:
    • A. Có thể làm trước deadline với cách A
    • B. Nếu muốn full change thì cần delay X ngày

👉 Kết quả: khách chọn giải pháp A đơn giản hơn – team không bị overtime.

Kết luận

Làm BrSE – bạn sẽ gặp những “cú xoay bất ngờ”.
Việc của bạn không phải là xoay theo ngay lập tức, mà là giữ trục và hướng cả team xử lý hợp lý.

👉 Trong bài tiếp theo, mình sẽ chia sẻ một tình huống khó: “Khi khách phàn nàn team làm chậm, dù task không rõ ràng”.