Giả sử bạn gửi khách một wireframe xám để chốt luồng màn hình đề nghị mua hàng, và phản hồi đầu tiên là giao diện thế này người dùng không chịu đâu, đổi sang màu logo công ty nhé, thế là cả buổi họp sau đó bàn màu, còn câu bạn cần chốt là duyệt xong thì đề nghị đi đâu thì chẳng ai trả lời. Chuyện này dễ xảy ra khi hai bên chưa thống nhất đang xem loại bản vẽ nào, vì wireframe, mockup và prototype trả lời ba câu hỏi khác nhau, mà BA thường chỉ cần sở hữu một.
Phỏng vấn hỏi use case và user story khác nhau thế nào thì bạn trả lời bằng định nghĩa hay bằng một ví dụ, nhiều ứng viên chọn định nghĩa, và câu trả lời của ai nghe cũng giống hệt nhau. Cách thuyết phục hơn là viết cùng một chức năng theo cả hai kiểu, rồi chỉ ra lúc nào kiểu nào giúp dự án đỡ cãi nhau.
hai định nghĩa trong hai câu # User story là một câu mô tả ngắn nhu cầu của một vai trò, theo mẫu quen thuộc As a [vai trò], I want [điều gì], so that [lợi ích], nó thiên về câu hỏi tại sao. Use case là một đặc tả chi tiết cách một actor tương tác với hệ thống để đạt một mục tiêu, nó thiên về câu hỏi chạy thế nào.
Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng.
Mình không tin mấy con số lương trung bình BA trôi nổi trên mạng, vì chẳng ai ghi rõ nó lấy từ đâu, nên bài này làm cách khác, đọc thẳng tin tuyển dụng, chỉ lấy con số có ghi trong tin, kèm link để bạn tự kiểm. Giới hạn nói rõ từ đầu là mẫu nhỏ, chủ yếu ở Hà Nội, đọc vào tháng 10/2026, đây là một bức ảnh chụp chứ không phải khảo sát thị trường.
Lỗi hay gặp của BA mới với ERD là lướt qua luôn, coi đó là việc của dev, mà hậu quả thì tới muộn, viết yêu cầu xem lịch sử mua hàng của khách mà không biết dữ liệu nằm ở bảng nào, nên chẳng hỏi được mấy câu quan trọng kiểu một khách có thể có mấy địa chỉ giao hàng. Đọc ERD ở mức BA không cần biết code, chỉ cần bốn bước và một ví dụ.
Phần kinh nghiệm trong CV đang trống thì bạn lấp nó bằng gì, nhiều người lấp bằng một đoạn mục tiêu nghề nghiệp dài với danh sách mười kỹ năng, và theo mình đó là cách nhanh nhất để CV bị lướt qua. Tin vui là ở vị trí fresher, nhà tuyển dụng không chờ bạn có chức danh BA, họ chờ bằng chứng bạn làm được việc của BA.
Bạn đang cầm vài triệu, phân vân có nên đăng ký một khóa BA, quảng cáo thì hứa đủ thứ từ ba tháng đi làm ngay tới đảm bảo việc làm, người quen thì bảo tự học được, khỏi tốn tiền. Bài này không bán khóa học cho ai, nên mình nói thẳng.
phụ thuộc bạn đang thiếu gì # Theo mình câu cái nào tốt hơn không có đáp án chung, câu có đáp án là bạn đang thiếu cái gì. Thiếu kiến thức thì cách nào cũng bù được, nhưng thiếu kỷ luật thì tự học dễ chết yểu, còn thiếu feedback thì tự học mãi chẳng biết mình sai ở đâu. Nên trước khi hỏi học khóa hay tự học, hãy hỏi mình đang thiếu kiến thức, kỷ luật, hay feedback.
Lỗi hay gặp của fresher với BRD, SRS, FS là thuộc lòng ba định nghĩa mà vẫn viết sai tài liệu. Giả sử ngày đầu đi làm bạn được giao viết SRS cho module này, trong khi tuần trước có người vừa gửi BRD, cả team thì cứ nói FS, ba cái tên mà câu hỏi thật chỉ có một, tài liệu này ai đọc và để quyết định việc gì.
Giả sử bạn vừa bước ra khỏi buổi workshop hai tiếng với phòng mua hàng, cầm về tờ giấy chi chít chữ, ai gửi yêu cầu, ai duyệt, mức nào phải lên giám đốc, lúc nào thì chạy Excel ngoài, giờ phải vẽ lại thành một sơ đồ cho cả team nhìn chung một bức tranh, mở công cụ lên rồi đứng hình. Bài này đi từ đúng tờ giấy đó ra một sơ đồ BPMN dùng được, kèm mấy lỗi hay biến sơ đồ thành tranh treo tường.
Trả lời ngắn: Theo mình, người mới tự học BA mất khoảng 6–9 tháng nếu học đều và đúng thứ tự, bắt đầu từ nền tảng (BA làm gì, requirement là gì), rồi tới user story và tài liệu, sau đó là dữ liệu và giao tiếp, cuối cùng là portfolio và phỏng vấn thử.
Lời hứa ba tháng thành BA nghe rất ngọt, mà cũng rất dễ làm người mới nản, vì ba tháng đủ để bạn biết BA là gì, thuộc vài thuật ngữ, vẽ được một cái sơ đồ, còn để ngồi phỏng vấn mà trả lời được câu vì sao em viết requirement như vậy thì cần lâu hơn thế. Bài này là cái lịch mình thấy sát thực tế cho người tự học, chia theo giai đoạn, giai đoạn nào cũng có việc cụ thể để làm.
