Bối cảnh

  • Dự án chạy gấp – khách yêu cầu ưu tiên release sớm

  • QA lên test case chi tiết nhưng khách bảo:

    “Không cần test kỹ đâu. Làm nhanh là được.”

  • Team làm đúng yêu cầu, kiểm tra cơ bản, release bản chính thức

  • 2 tuần sau: lỗi phát sinh trong môi trường thật → ảnh hưởng đến đơn hàng

👉 Khách quay lại phàn nàn:

“Tại sao lại không kiểm tra kỹ phần này?”

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

  • Mình phản ứng có phần hơi gay gắt:

    “Hồi đó bên mình đã confirm là không cần test kỹ rồi ạ.”

➡️ Khách im lặng – không phản hồi nữa, nhưng mình cảm thấy không khí không còn cởi mở

Cách mình xử lý lại sau đó

1. Gửi lại log các trao đổi trước đó

Để làm rõ rằng quyết định test nhẹ là có xác nhận – không phải team chủ quan

2. Không nói theo kiểu ‘đổ lỗi’ – mà chuyển sang hướng đề xuất cải thiện

“Để tránh tình huống tương tự, bên em đề xuất luôn có checklist QA tối thiểu, kể cả khi dự án gấp.”

3. Tạo cơ chế “ghi nhận rủi ro” khi khách yêu cầu bỏ qua bước kiểm tra

Gọi là ‘risk acknowledgment’ – có thể nhẹ nhàng dưới dạng checkbox xác nhận qua mail

Bài học rút ra

  • Là BrSE, bạn phải bảo vệ quyền được kiểm thử của team – bằng cách ghi nhận rõ trong log
  • Không ai thích nghe “đã nói rồi mà” – nên luôn chuyển hướng sang đề xuất giải pháp
  • Dù khách gấp gáp – vẫn cần nhắc lại: “đẩy nhanh có rủi ro gì – ai là người chấp nhận?”

Kết luận

BrSE không chỉ là người truyền đạt – mà còn là người giúp team giữ chuẩn mực nghề nghiệp ngay cả khi khách muốn cắt giảm.
Hãy luôn ghi nhận rõ ràng, có phương án dự phòng, và dùng cách giao tiếp tích cực – để giữ được cả chất lượng và mối quan hệ.

👉 Bài tiếp theo: “Khi nội bộ tranh cãi – BrSE nên đứng về phía ai?”