Trả lời ngắn: Chưa có dự án thì portfolio BA nên là một case simulation, chọn một quy trình bạn quan sát được, vẽ as-is, chỉ ra pain point, đề xuất to-be và viết user story kèm acceptance criteria. Người tuyển fresher muốn thấy cách bạn nghĩ, và một case làm sâu là đủ để họ thấy điều đó.
Lỗi phổ biến nhất của portfolio BA fresher là cố làm cho giống dự án thật, tên dự án thật kêu, logo công ty giả, sơ đồ copy trên mạng, mà không có chỗ nào cho thấy người làm đã tự nghĩ, người phỏng vấn hỏi một câu vì sao em chọn cách này là lộ ngay. Chưa có dự án không phải lý do để portfolio trống, nó chỉ có nghĩa là bạn phải tự tạo bài toán, rồi làm bài toán đó đến nơi đến chốn.
Trả lời ngắn: BA không bắt buộc phải biết SQL, nhưng nên biết ở mức SELECT, JOIN, GROUP BY, mức đó đủ để tự trả lời phần lớn câu hỏi dạng bao nhiêu, mấy cái, theo từng tháng, và đủ để kiểm tra requirement với dữ liệu thật, không cần học tới mức developer.
Thử hình dung cuộc họp với phòng kinh doanh, trưởng phòng hỏi tháng trước có bao nhiêu đơn bị khách trả lại, chủ yếu là sản phẩm nào, bạn hứa sẽ gửi số, về chỗ nhắn dev nhờ lấy, dev đang chạy deadline nên ba ngày sau mới có file, mà tới lúc đó câu hỏi đã đổi, cuộc họp tiếp theo cũng đã diễn ra rồi. Tình huống kiểu này là lý do nhiều BA bắt đầu học SQL, và câu hỏi là học tới đâu thì vừa, để khỏi mất cả năm cày khóa database.
Lần đầu đi phỏng vấn BA, mình bị hỏi một câu tưởng dễ, em kể một lần em làm việc với stakeholder khó tính đi, thế là ngồi im mấy giây rồi lắp bắp vài câu chung chung kiểu em luôn lắng nghe, em kiên nhẫn, về nhà mới tiếc, chuyện thật thì đầy mà không biết kể sao cho ra hồn.
Đi vài vòng mình mới ngộ ra, nhà tuyển dụng không hỏi định nghĩa để chấm điểm thuộc bài, họ hỏi tình huống để xem em xử lý thật thế nào, mà fresher thì chưa có nhiều dự án để khoe, nên cách kể mới là thứ quyết định.
Giả sử có bạn nhắn hỏi mình, anh ơi em làm BA được hơn một năm rồi, bao lâu thì lên senior được? Theo mình câu trả lời tốt nhất là hỏi ngược lại, em đã tự chịu trách nhiệm với một requirement nào chưa, hay mới làm theo bàn giao, vì lên senior nằm ở câu đó nhiều hơn là ở số năm. Nên bài này mình không viết kiểu cứ đủ 5 năm là tự động lên senior, số năm tự nó chẳng nói lên điều gì, dưới đây chỉ là cách mình nhìn cái lộ trình này.
Giả sử bạn mở một file spec ra, toàn những câu kiểu “Hệ thống cho phép người dùng thêm sản phẩm vào giỏ hàng”, đọc lướt thì tưởng đúng, nhưng hỏi lại một câu thêm vào giỏ để làm gì thì chưa chắc người viết trả lời được. Theo mình user story hay bị viết bừa ở đúng phần “để làm gì”, viết đủ là ai, muốn chức năng gì, còn mục đích thì chỉ là giả định với đoán mò.
