Vì sao dev muốn chuyển sang BrSE? Muốn tiếp xúc với khách hàng, hiểu sản phẩm sâu hơn Mong muốn phát triển kỹ năng mềm, định hướng quản lý Cảm thấy bế tắc với việc chỉ code – muốn thử vai trò mới 👉 BrSE là một hướng đi phù hợp nếu bạn muốn kết hợp kỹ thuật + giao tiếp + tư duy hệ thống. Cần chuẩn bị gì để chuyển đổi? 1. Tiếng Nhật (ít nhất là N3, tốt nhất là N2) Không cần trôi chảy ngay, nhưng cần đủ để hiểu tài liệu và họp cơ bản ...
1. Không bắt đầu từ ngữ pháp – mà từ giao tiếp đơn giản Hồi đó mình nghĩ phải học hết ngữ pháp rồi mới dám nói. Thật ra nếu được học lại, mình sẽ: Bắt đầu từ các mẫu câu hay dùng trong hội thoại Học theo tình huống: tự giới thiệu, hỏi ý kiến, báo cáo Ngữ pháp quan trọng – nhưng không phải thứ cần hoàn hảo từ đầu. ...
Hướng nội – có phải là điểm trừ? Khi nói đến BrSE, mọi người thường nghĩ: “Phải hoạt bát, giỏi nói, hướng ngoại mới làm được.” 👉 Nhưng thật ra, hướng nội không phải là rào cản. Mình biết rất nhiều BrSE giỏi là người hướng nội. Hướng nội có điểm mạnh gì? Lắng nghe tốt – hiểu rõ điều khách/ dev thật sự muốn Suy nghĩ kỹ trước khi nói – tránh phát ngôn thiếu chính xác Giao tiếp bằng văn bản tốt hơn lời nói – lợi thế trong viết mail, tài liệu Nhiều khách hàng Nhật thích cách làm việc “thầm lặng mà chắc chắn” – điều mà hướng nội làm rất tốt. ...
Tình huống thực tế Khi còn là BrSE junior, mình từng nghe khách hàng nói qua Zoom về tính năng “ユーザー管理画面” (màn hình quản lý người dùng), và mình dịch ngay cho dev là “admin screen”. Dev làm đúng – nhưng hoá ra khách hàng lại muốn “mỗi user tự quản lý thông tin của mình”, chứ không phải “admin quản lý tất cả người dùng”. 👉 Kết quả: phải làm lại gần như toàn bộ giao diện và luồng xử lý. ...
Tình huống thực tế Vì quen thân với team dev và hiểu kỹ thuật, mình thường xuyên giải thích theo hướng có lợi cho team, ngay cả khi khách chưa hiểu lý do chậm trễ. Nhiều lần, mình vô thức đứng hẳn về phía dev và cố gắng “bao che”. 👉 Sau một vài lần như vậy, khách bắt đầu đặt câu hỏi: “Bạn có thực sự đại diện cho chúng tôi không?” ...
Tình huống thực tế Khách hàng gửi mail hỏi: “Tôi muốn thêm một cột mới trong màn hình danh sách, có được không?” Lúc đó mình chưa chắc chắn nên định hỏi dev trước rồi mới trả lời. Nhưng do bận task khác, mình để đó 2 ngày không trả lời gì. Đến lúc khách hỏi lại, thì mới vội xử lý. 👉 Kết quả: Khách hàng cảm thấy không được quan tâm, mất sự tin tưởng. ...
Tình huống thực tế Khách Nhật gửi mô tả: “Chỗ này làm giống như site A là được.” Mình vào site A, thấy có biểu đồ dạng thanh → đoán là khách cũng muốn biểu đồ thanh, nên mình confirm rất sơ sài rồi bảo dev làm theo. 👉 Kết quả: khách muốn biểu đồ đường, và format chỉ lấy 3 giá trị chính, không đầy đủ như site A. Cả team phải làm lại UI. ...
Tình huống thực tế Dự án có deadline gấp. Team dev cần xác nhận khách muốn layout form theo mẫu A hay B. Mình định để họ cứ làm mẫu A trước, rồi hỏi khách sau – vì nghĩ “không sao đâu, khách dễ lắm”. Nhưng khi gửi cho khách, họ trả lời: “Tôi tưởng sẽ giống mẫu B. Giờ làm lại giúp.” 👉 Kết quả: team mất 2 ngày chỉnh lại, ảnh hưởng kế hoạch. ...
Tình huống thực tế Trong một buổi họp, khách Nhật nói: “ここの処理はちょっと甘い気がします。” Mình dịch thẳng với dev: “Khách bảo xử lý phần này hơi ngọt.” 🤦♂️ Tất nhiên là sai. Ý khách là: “Xử lý chưa chặt chẽ lắm”. 👉 Dev không hiểu, và mình cũng lỡ cơ hội để yêu cầu làm rõ. Bài học rút ra ❌ Dịch word-by-word = dễ gây hiểu sai hoàn toàn ❌ Không giải thích ngữ cảnh = dev bối rối ✅ BrSE cần hiểu rõ ý định, rồi truyền đạt lại bằng cách phù hợp với team Cách cải thiện Nghe kỹ giọng điệu và ngữ cảnh khi khách nói ...
Tình huống thực tế Khách Nhật yêu cầu sửa xử lý CSV export: “Bổ sung thêm cột ID người tạo”. Mình ghi ticket cho dev: “Thêm cột ID người tạo vào CSV.” Dev hỏi: “Lấy từ bảng nào?” → mình trả lời. Nhưng kết quả cuối cùng vẫn không đúng như mong đợi của khách. 👉 Vì mình không nói lý do khách muốn cột đó: “để đối chiếu với bảng quyền hạn bên hệ thống khác”. Dev không biết nên format/đặt vị trí sao cho phù hợp. ...