Một quan niệm sai lầm phổ biến “BrSE chỉ cần giao tiếp tốt, biết tiếng Nhật là đủ.” Nhưng thực tế công việc cho thấy: Bạn giao tiếp cả ngày, nhưng nếu không hiểu logic – bạn chỉ là người chuyển lời Bạn viết tài liệu, nhưng nếu không biết nghiệp vụ – tài liệu bạn mơ hồ Bạn họp xác nhận với khách, nhưng nếu không thể phân tích và đặt câu hỏi đúng – buổi họp vô nghĩa 👉 Vì vậy, phân tích là kỹ năng sống còn nếu bạn muốn trở thành BrSE giỏi ...
Vấn đề thường gặp: “Khách đọc spec mà vẫn hỏi lại: ‘Rốt cuộc hệ thống sẽ làm gì?’” Lý do? Tài liệu quá thiên về kỹ thuật Viết theo kiểu code, không theo kiểu người dùng 📌 Nếu mô tả nghiệp vụ mà dev hiểu – nhưng khách không hiểu → bạn chưa hoàn thành vai trò BrSE Mục tiêu của phần mô tả nghiệp vụ là gì? Giúp người không kỹ thuật hình dung được hệ thống làm gì Hiểu luồng thao tác từ góc nhìn người dùng Có thể xác nhận được logic xử lý ở mức khái quát Cách viết dễ hiểu hơn: 1. Bắt đầu từ hành vi người dùng, không phải xử lý kỹ thuật ❌ “Khi submit, hệ thống gọi API /v1/post-item và update bảng ITEM.” ✅ “Khi người dùng nhấn Lưu, dữ liệu được ghi nhận và hiển thị thông báo thành công.” ...