Không có dự án nào không có bug.
Nhưng cách bạn phản ứng khi bug xảy ra mới là điều quan trọng nhất.
Tôi từng trải qua một lần mà khách hàng Nhật thể hiện sự tức giận công khai trong họp, và tôi đã học được rất nhiều từ lần đó.
💥 Tình huống
Một chức năng quản lý đơn hàng được triển khai xong, lên production.
3 ngày sau, khách phát hiện:
- Không hiển thị đơn hàng của người dùng cũ (do thiếu điều kiện filter).
- Hơn 100 đơn hàng bị hiểu nhầm là mất dữ liệu.
Khách gọi họp khẩn, và mở đầu bằng giọng căng thẳng:
「これはちょっと信じられません。御社の品質管理、どうなっているんですか？」
(“Chuyện này thật khó tin. Bên bạn đang quản lý chất lượng kiểu gì vậy?”)
🧯 Tôi đã phản ứng thế nào?
1. Không đổ lỗi – không bào chữa
Tôi không nói: “dev làm sai”, “test sót”, mà trả lời:
“Tôi xin lỗi vì để sự việc xảy ra. Tôi xin phép xác nhận lại logic và phản hồi sớm nhất trong ngày hôm nay.”
2. Tạm thời giải thích bằng dữ kiện trung lập
Tôi nói rõ:
- Dữ liệu vẫn còn – không bị mất.
- Chỉ là điều kiện lọc hiển thị thiếu case.
- Đã tạm thời rollback để tránh ảnh hưởng thêm.
→ Làm khách bình tĩnh lại phần nào.
🔍 Sau cuộc họp: Tôi làm gì?
✅ 1. Gọi nội bộ để tìm nguyên nhân ngay
- Check log, confirm lại thiết kế ban đầu.
- Rà lại test case, review logic.
✅ 2. Gửi báo cáo điều tra (原因調査報告書)
- Nêu rõ nguyên nhân (thường gọi là “root cause”).
- Viết lại bằng tiếng Nhật rõ ràng.
- Nêu biện pháp ngăn chặn tái phát (再発防止策).
✅ 3. Gọi lại cho khách (nếu cần)
Thay vì chỉ gửi mail, tôi xin gọi lại để:
- Trình bày báo cáo.
- Cam kết hướng xử lý.
- Lắng nghe thêm yêu cầu bổ sung từ khách.
🧠 Bài học tôi rút ra
- Khách giận không phải vì bug, mà vì mất niềm tin.
- Cách bạn xử lý mới quyết định niềm tin có thể phục hồi hay không.
- Sự chủ động và minh bạch sẽ giúp lấy lại uy tín.
🧭 Kết
Là BrSE, bạn không viết ra bug, nhưng bạn đại diện cho toàn bộ team khi nó xảy ra.
Bạn có thể chọn im lặng hoặc phản ứng chuyên nghiệp. Tôi đã từng sợ hãi, nhưng nhờ lần đó, tôi hiểu được sức mạnh của sự bình tĩnh, rõ ràng và trách nhiệm.
Còn bạn, đã từng đối mặt với sự giận dữ từ khách hàng chưa?