Bối cảnh
- Mình nhận yêu cầu từ khách: xử lý A theo logic B, có mail confirm rõ
- Truyền đạt cho dev bằng document + review OK
- Nhưng dev implement sai – logic bị đảo điều kiện
- Khi demo, khách phản ứng:
“Hình như anh hiểu nhầm yêu cầu rồi, không phải như thế.”
👉 Cảm giác choáng nhẹ. Vì mình chắc chắn mình hiểu đúng, nhưng khách lại nghi ngờ mình.
Cách mình phản ứng (sai)
- Mình nói: “Dev làm sai ạ” → phản xạ phòng vệ
- Khách im lặng, nhưng không vui
- Dev cũng khó chịu vì bị nêu tên trước mặt khách
➡️ Kết quả: tạo ra không khí mất tin tưởng từ cả hai phía
Mình đã thay đổi cách xử lý sau này như sau:
1. Không đổ lỗi – phản hồi trung lập và xác nhận lại logic
“Chúng tôi sẽ xác nhận lại phần xử lý này ngay và phản hồi lại trong hôm nay.”
2. Review lại logic và log, xác minh mức độ sai lệch
Nếu chỉ là lỗi nhỏ → sửa nhanh, không cần nêu tên Nếu là logic bị hiểu sai nghiêm trọng → gửi lại confirm ban đầu
3. Gửi lại logic chuẩn kèm so sánh A/B
“Bản hiện tại đang xử lý theo logic: X
Logic đúng theo confirm trước là: Y”
👉 Truyền đạt vấn đề, không chỉ ra ai làm sai – để giữ uy tín cho cả team
Bài học rút ra
- Là BrSE, bạn đại diện cho team khi đối thoại với khách
- Việc đổ lỗi có thể giúp bạn “thoát” một tình huống, nhưng sẽ phá vỡ niềm tin lâu dài
- Cách đúng: xử lý sai sót như một nhóm chuyên nghiệp – không đổ lỗi, không trốn tránh, chỉ tập trung vào giải pháp
Kết luận
Bạn sẽ gặp lúc team làm sai – dù bạn đã làm đúng.
Quan trọng là: bạn ứng xử thế nào để giữ được sự tin tưởng từ cả hai phía.
👉 Trong bài tiếp theo, mình sẽ chia sẻ tình huống thực tế: “Lúc nhận dự án mới – không tài liệu, không người bàn giao”