Một lỗi nhỏ về UI – tưởng như không đáng để sửa – lại khiến mình và cả team 'đứng hình' trong buổi demo với khách hàng cấp cao. Từ đó mình không bao giờ xem nhẹ những chi tiết nhỏ nữa.
Khách ban đầu yêu cầu đẩy nhanh tiến độ, không cần kiểm thử chi tiết. Nhưng khi xảy ra lỗi, lại trách team thiếu kiểm tra. Mình đã ứng xử thế nào để giữ vững lập trường mà vẫn giữ được mối quan hệ?
Một tình huống tế nhị khi dev làm sai logic, nhưng khách lại hiểu nhầm rằng BrSE đã truyền đạt sai. Đây là cách mình xử lý để giữ uy tín – mà không đổ lỗi.
Một tình huống khó xử khi dev từ chối thực hiện task vì cho rằng đó không thuộc phạm vi công việc của mình. Là BrSE, mình đã phản ứng và giải quyết như thế nào để tránh mất tinh thần và vẫn đảm bảo tiến độ?
Một tình huống đau đầu khi khách ban đầu từ chối việc lập tài liệu vì cho là không cần thiết. Nhưng đến khi có sự cố, lại yêu cầu team giải thích chi tiết và trách vì không có gì để tra cứu.
Một tình huống rất thường gặp khi làm BrSE: khách đổi yêu cầu vào sát thời điểm release. Mình từng hoảng loạn – nhưng sau đó đã học được cách xử lý hiệu quả.
Một tình huống khó chịu nhưng rất thực tế: mình đã viết mail giải thích rất rõ yêu cầu và hướng xử lý. Nhưng khách vẫn yêu cầu gọi/gặp trực tiếp để 'nắm được đúng'. Vì sao lại như vậy – và mình đã rút ra gì?
Một tình huống gây ức chế nhưng rất hay gặp: khách hàng phàn nàn team xử lý chậm, trong khi bản thân họ chưa từng đưa task rõ ràng. Mình đã phản ứng và xử lý thế nào?
Khi trong team có mâu thuẫn – giữa dev và QA, hoặc giữa các nhóm offshore/onshore – BrSE nên phản ứng thế nào? Đứng về bên mạnh hơn, hay giữ trung lập? Mình đã rút ra được nguyên tắc gì?
Một trong những tình huống tệ nhất khi làm BrSE là phải tiếp nhận dự án khi không có tài liệu rõ ràng, không người chuyển giao. Làm sao để không bị hoảng loạn và bắt đầu một cách có chiến lược?