JD tuyển BA ngày càng rộng: fit bao nhiêu phần trăm thì nên nộp, và mang theo cái gì?
JD rộng ra không phải vì công ty đòi hỏi vô lý, mà vì AI đang làm ranh giới giữa các vai trò bớt cứng. Cách tách JD làm ba nhóm, ngưỡng fit thực tế để bấm nộp, và mang theo cái gì cho khỏi đi tay không.

Hi lại là Hoàng đây! Mấy hôm trước có một bạn nhắn mình, gửi kèm cái JD tuyển BA của một công ty product tầm trung, rồi hỏi đúng một câu: "Em đọc xong thấy mình không đủ, có nên nộp không anh?".
Cái JD đó dài gần hai trang. Ngoài mấy dòng quen thuộc kiểu viết tài liệu đặc tả, vẽ business process, làm việc với dev và QC, thì nó còn đòi: biết SQL để tự truy vấn dữ liệu, đọc được response API và test bằng Postman, có product thinking (tạm dịch là tư duy sản phẩm) và theo được metric sau khi release, biết dựng prototype, và một dòng nằm ở cuối phần yêu cầu là "tối thiểu 3 năm kinh nghiệm làm việc với AI Agent".
Mình đọc tới dòng cuối thì phì cười. Trong group cũng có anh em thả đúng một câu: "Agent ms 2024 đây mà đã 3 năm kn rồi". Chuẩn luôn, khái niệm AI Agent mới phổ biến từ 2024, mà JD năm 2026 đã đòi ba năm kinh nghiệm => nghĩa là người viết dòng đó không hề tính theo thời gian, họ chỉ đang mô tả "chúng tôi muốn một người rành cái này thôi".
Bạn kia tự chấm mình fit khoảng 60% và định không nộp. Mình bảo nộp đi. Bài này mình viết lại cho đủ đầu đuôi, vì thật ra nó là hai câu hỏi dính vô nhau: có nên nộp không, và nếu nộp thì lấy gì chứng minh cái phần mình còn thiếu.
Vì sao JD tuyển BA ngày càng rộng ra
Mình nghĩ có một cách giải thích thực tế hơn chuyện "AI sắp thay BA": công ty vẫn cần bạn, họ chỉ không còn muốn trả tiền cho một người chỉ làm đúng phần việc mang nhãn BA nữa.
Thử nhìn vô một ngày làm việc bình thường. Viết mô tả chức năng, vẽ lại luồng, soạn bộ test case đầu tiên, gom biên bản họp thành tài liệu — mấy việc này trước đây ăn của mình cả buổi, giờ có AI hỗ trợ thì bản nháp ra trong ba mươi phút. Vấn đề là phần thời gian tiết kiệm được đó rất hiếm khi biến thành lịch làm việc nhẹ hơn. Ở nhiều chỗ nó biến thành kỳ vọng: em đã xong sớm rồi thì em đi xa hơn được trong vòng đời sản phẩm.
Đi xa hơn về phía nào thì tuỳ team, nhưng mình thấy có ba hướng cứ lặp lại trong các JD gần đây:
- Về phía PO: tự quản backlog, tự đề xuất thứ tự ưu tiên, chứ không chờ ai xếp sẵn rồi ngồi mô tả lại.
- Về phía QC: thiết kế test scenario, tự bắn thử API, ngồi cùng user trong UAT thay vì gửi tài liệu rồi đợi kết quả.
- Về phía Product Manager: đào vấn đề trước khi có giải pháp, theo số sau release, và dám nói ra cái tính năng vừa làm xong không ai dùng.
Cộng thêm chuyện bây giờ với mấy tool AI, BA tự viết được câu SQL để kiểm tra một giả thuyết, tự dựng cái prototype bấm qua bấm lại có logic đàng hoàng, tự làm một script nhỏ đọc file để đối chiếu dữ liệu — mấy việc mà hai năm trước phải xếp hàng chờ dev rảnh.
Cái này không có nghĩa BA phải hoá thành PO, QC, PM và dev cùng một lúc. Nó có nghĩa là ranh giới giữa các vai trò đang bớt cứng. Một team nhỏ thì muốn có một người theo cái vấn đề từ lúc stakeholder mở miệng nói nhu cầu, qua lúc team làm giải pháp, tới lúc nhìn kết quả ngoài production. Ít người thì ít cuộc bàn giao, ít chỗ rơi thông tin, và dĩ nhiên là ít tiền hơn. Nói thẳng ra là nhiều vai được gộp lại giao cho một người, công ty tối ưu chi phí và cắt bớt phần trao đổi qua lại. Nên ai cũng phải ráng ôm nhiều vai hơn, và tuyển dụng thì yêu cầu cao hơn.
Phải nói cả hai mặt cho công bằng. Mặt được là mình tạo ra nhiều giá trị hơn, đụng tới nhiều phần của sản phẩm hơn, và tự nhiên có cái để kể khi đi phỏng vấn. Mặt trái là JD rộng ra nhưng quyền quyết định, thời gian và đãi ngộ thì thường vẫn y như cũ. Biết thêm SQL, testing, product thinking hay prototype rõ ràng là lợi thế. Nhưng ôm hết mọi thứ mà không chốt được priority và ownership thì AI chỉ là công cụ giúp một người quá tải nhanh hơn thôi.
Đọc JD như đọc một bản requirement, đừng đọc như đề thi
Đây là chỗ mình thấy nhiều bạn tự hại mình nhất. Đọc JD như đọc đề thi thì mỗi dòng là một câu hỏi có đúng có sai, đếm được mấy câu sai là tự loại. Mà JD đâu phải đề thi, nó là một bản requirement do người khác viết — và bạn thì đang làm nghề bóc tách requirement mỗi ngày.
Requirement nào cũng có cái bắt buộc, có cái nice to have, có cái người ta viết vô cho đủ bộ. JD y chang vậy. Việc đầu tiên nên làm là tách ba nhóm ra rồi mới chấm điểm.
| Nhóm dòng trong JD | Dấu hiệu nhận ra | Gặp thì làm gì |
|---|---|---|
| Bắt buộc thật | Nhắc lại ở cả phần mô tả công việc lẫn phần yêu cầu; gắn với domain hoặc sản phẩm cụ thể ("từng làm hệ thống thanh toán", "hiểu nghiệp vụ kho") | Thiếu thì cân nhắc thật, hoặc phải có đồ chứng minh thay thế |
| Nice to have | Xuất hiện đúng một lần, đứng chung câu với "ưu tiên ứng viên…", "là một lợi thế" | Thiếu cũng cứ nộp, chỉ cần chuẩn bị một câu trả lời thành thật |
| HR nhét vô cho oai | Đứng thành cụm dài, chữ nghĩa chung chung, con số kinh nghiệm vô lý | Bỏ luôn khi tự chấm điểm, đừng để nó kéo tỉ lệ fit của mình xuống |
Chấm điểm thì chỉ chấm trên nhóm đầu tiên. Bạn kia tự cho mình 60% là vì bạn ấy chia cho tổng số dòng trong JD, trong đó có cả dòng ba năm kinh nghiệm AI Agent.
Làm sao nhận ra dòng nào là HR nhét vô
Mình từng ngồi cùng HR để viết JD cho vị trí BA, nên nói thật là quy trình nó không thiêng liêng như mình tưởng hồi mới đi làm. Team đưa vài gạch đầu dòng, HR lấy JD cũ ra ghép, thêm mấy dòng cho nó "đầy đặn", rồi đăng. Có anh trong group tóm gọn câu này mình thấy đúng: "Tất nhiên HR họ cố nhét vào càng nhiều càng tốt. Chưa chắc bộ phận người ta đã hiểu."
Dấu hiệu dễ thấy nhất là con số kinh nghiệm không khớp với tuổi đời của chính công nghệ đó — kiểu ba năm AI Agent ở trên. Kế đó là một dòng gom quá nhiều thứ chẳng liên quan gì nhau, dạng "thành thạo SQL, Python, Power BI, Figma và Jira", vì trong thực tế không có cái task nào cần cả năm thứ đó cùng lúc. Rồi tới cụm kỹ năng mềm liệt kê thành hàng dài: giao tiếp tốt, tư duy phản biện, chịu áp lực cao, làm việc nhóm. Nặng hơn nữa là JD copy nhầm từ vị trí khác, title ghi Business Analyst mà bên dưới lại có dòng "phát triển tệp khách hàng" — cái này mình gặp thật rồi, không đùa.
Nhận ra mấy dòng đó không phải để chê công ty. Nhận ra để biết mình đang tự trừ điểm của mình vì những thứ chính người tuyển cũng không hỏi tới.
Fit bao nhiêu phần trăm thì nên nộp
Ngưỡng mà mình thấy đúng với thực tế đi tuyển là trên 50% phần bắt buộc thật. Trong group cũng có anh nói y vậy: "UV fit được >50% là gọi rồi", và một anh khác vừa đi phỏng vấn về xác nhận thêm: "anh phỏng vấn về rồi hỏi 6-70% JD á".
Cái vế thứ hai mới là chỗ đáng nhớ. Người phỏng vấn cũng chỉ hỏi chừng 60–70% JD thôi, vì một buổi có 45 phút tới một tiếng, hỏi hết thì không kịp, mà quan trọng hơn là chính họ biết dòng nào trong JD là dòng thật. Nên bạn tự loại mình ở nhà là loại trước một vòng mà đối phương còn chưa mở.
Ngược lại, nếu đọc JD thấy mình fit đủ 100% thì cũng nên khựng lại một nhịp. Vô đó một năm nữa bạn vẫn làm đúng mấy việc đang làm hôm nay, chỉ khác cái tên công ty. Mình thấy vị trí đáng nộp nhất thường rơi vô khoảng fit 60–80%: đủ để mình có cái mà nói, còn thiếu đủ để có cái mà học.
Phần mình thiếu thì gói thành câu chuyện, đừng giấu
Giấu là phản xạ tự nhiên nhưng nó hỏng việc, vì người phỏng vấn sẽ hỏi trúng ngay cái mình né. Cách mình khuyên là trả lời theo ba tầng: cái gần nhất mình từng làm, cách mình đã tự học, và giới hạn mình tự biết.
Lấy luôn cái dòng AI Agent làm ví dụ. Câu trả lời yếu là "em có tìm hiểu về AI Agent ạ" — nghe xong không đọng lại gì. Câu trả lời đứng được thì kiểu: "Em chưa build agent chạy production. Nhưng em có dựng một con trợ lý đọc tài liệu đặc tả rồi tự sinh checklist test, em sài nó cho dự án gần nhất, mỗi sprint tiết kiệm được chừng nửa ngày soạn tay. Chỗ nó còn yếu là khi rule nằm rải rác ở nhiều tài liệu thì nó bịa ra rule không có, nên em vẫn phải rà lại phần business rule bằng tay."
Ba tầng, một phút, và người nghe biết chính xác bạn đang đứng ở đâu. Cái cần tránh là hứa suông kiểu "em học nhanh lắm" — ai đi phỏng vấn cũng nói câu đó nên nó không còn giá trị thông tin nữa.
Khi nào JD rộng là cơ hội, khi nào là bẫy
Phần này mình nghĩ quan trọng ngang chuyện có nộp hay không. JD rộng có thể là công ty muốn giao cho bạn một mảng lớn, mà cũng có thể là họ vừa cắt hai người và gom việc lại. Nhìn từ ngoài thì hai cái viết ra chữ y hệt nhau, nên phải hỏi trong buổi phỏng vấn. Ba câu này mình hay hỏi ngược lại nhà tuyển dụng:
- Quyền quyết định có đi kèm không? "Nếu em thấy một yêu cầu không nên làm thì em nói với ai, và ai là người chốt cuối?" Nếu câu trả lời là mọi thứ đều do sếp lớn chốt thì phạm vi rộng kia chỉ là phạm vi làm, không phải phạm vi quyết.
- Thời gian có đi kèm không? "Hiện tại một sprint team commit bao nhiêu story, và BA đang ôm mấy luồng?" Con số này nói thật hơn mọi lời mô tả về văn hoá công ty.
- Đãi ngộ có đi kèm không? Cái này thì cứ hỏi thẳng khoảng lương, và nhớ giùm mình một câu trong group: "Số nó ảo vì nó dựa trên JD up to chứ không dựa trên offer letter".
Được hai trong ba thì mình thấy vẫn đáng đi. Không được cái nào mà JD vẫn dài hai trang thì bạn đang nhận ba đầu việc với một suất lương, và AI trong trường hợp đó chỉ giúp bạn kiệt sức sớm hơn thôi.
Nộp rồi thì mang theo cái gì
Câu hỏi này trong group cũng có người hỏi nguyên văn: "BA nên làm portfolio như nào v ạ". Và một anh khác trả lời rất đời: "Nên phải tính có cái gì đem vào. Đi tay không kỳ lắm. Phỏng vấn lỡ chém gió quá đà", rồi chốt thêm "vác tay không đi phỏng vấn là khó lắm".
Khi JD còn hẹp thì đi tay không vẫn ổn, vì hỏi vài câu nghiệp vụ là ra trình độ. Nhưng khi JD rộng ra như bây giờ, dòng "có tư duy sản phẩm" hay "biết dựng prototype" trong CV không cãi được với ai hết — nó là lời khai, không phải bằng chứng. Portfolio chính là chỗ bạn đổi lời khai thành bằng chứng.
Vướng mắc lớn nhất là NDA, cái này thật chứ không phải cớ. Cách xử lý mình hay làm là dựng lại: đổi tên hệ thống, thay số liệu bằng dữ liệu giả, bỏ hết tên công ty và tên người, nhưng giữ nguyên logic nghiệp vụ và mấy ca ngoại lệ. Cái người ta muốn xem là cách bạn nghĩ, chứ không phải dữ liệu khách hàng của công ty cũ.
Hai kiểu portfolio, chọn kiểu nào
Mình thấy portfolio của BA gom về hai kiểu, và chọn kiểu nào thì tuỳ bạn đang thiếu cái gì trong mắt nhà tuyển dụng.
| Case study đầu–đuôi | Sản phẩm chạy được | |
|---|---|---|
| Hình thức | Một tài liệu kể lại trọn một bài toán: bối cảnh → vấn đề → giải pháp → kết quả | Prototype bấm được, một dashboard, một con bot nhỏ, một bộ tài liệu đầy đủ cho một luồng thật |
| Mạnh ở chỗ | Cho thấy cách nghĩ, cách đặt câu hỏi, cách chọn giữa hai phương án | Cho thấy bạn ra được sản phẩm, không chỉ nói hay |
| Yếu ở chỗ | Dễ dài, dễ bị đọc lướt | Người xem có thể chỉ chấm phần đẹp xấu mà quên phần nghiệp vụ |
| Tốn bao lâu | Vài buổi tối nếu lấy lại dự án cũ | Vài ngày tới vài tuần |
| Hợp với ai | Bạn đã có dự án thật nhưng chưa biết kể | Bạn đang chuyển ngành, hoặc nhắm vị trí đòi phần "làm" nhiều hơn phần "viết" |
Về kiểu thứ hai, có một anh trong group làm tới mức mình phải nể: dựng nguyên 200 màn hình prototype cho một luồng thanh toán, chỉ để có đồ mang đi. Kết quả anh kể lại là "làm xong 200 cái màn hình mà user gật cái rụp". Không phải ai cũng cần tới 200 màn, nhưng ý ở đây rõ: một thứ bấm vô chạy được thì nói thay được cả buổi trình bày.
Còn nỗi lo của kiểu thứ nhất thì cũng có người nói ra rồi: "thấy hơi dài, sợ người đọc không đủ kiên nhẫn đọc hết". Cách gỡ là để một trang tóm tắt lên đầu — bài toán là gì, bạn làm gì, kết quả ra sao — rồi mới tới phần chi tiết. Người bận thì đọc một trang là đủ, người quan tâm sẽ tự lật tiếp.
Portfolio nên chứa gì cho cụ thể
Đừng làm nó thành một bộ sưu tập tài liệu đẹp. Cái mình muốn thấy khi ngồi ghế người tuyển là một mạch suy nghĩ có đầu có đuôi: bối cảnh gọn trong ba bốn câu, vấn đề nói bằng thứ đo được (đơn bị huỷ nhiều, thao tác thủ công mất mấy phút mỗi lần, tháng nào cũng lệch số ở khâu đối soát), rồi mới tới phần bạn đã làm.
Phần hiện vật thì chọn lọc thôi, chừng ba tới bốn thứ là đủ: một sơ đồ luồng nghiệp vụ, một bảng business rule (tạm dịch là quy tắc nghiệp vụ) có cả ca ngoại lệ, một prototype hoặc bộ wireframe cho màn hình chính, và một bộ test scenario cho luồng đó. Bốn thứ này đi cùng nhau sẽ chứng minh được đúng cái phạm vi rộng mà JD đang đòi.
Thứ mà mình thấy tạo khác biệt nhiều nhất lại là hai phần cuối, mà nhiều bạn hay bỏ. Một là đánh đổi: chỗ này có hai phương án, mình chọn phương án B vì nó đi được với dữ liệu đang có, đổi lại là user phải thao tác thêm một bước. Hai là cái mình làm sai: rule nào bỏ sót, giả định nào sai, phát hiện ở giai đoạn nào và sửa ra sao. Người phỏng vấn tin bạn ở chỗ đó, chứ không tin ở phần mọi thứ đều hoàn hảo.
CV đi kèm: junior khác senior chỗ nào
Portfolio hay tới mấy mà CV không qua nổi vòng lọc thì cũng không ai xem. Có anh trong group tóm tắt phần này gọn và đúng: "Junior trở xuống thì cứ dồn nhiều từ khóa lên. Trở lên thì nhiều dự án liên quan tới cái công ty tuyển… làm cái timeline trong CV để HR scan nhanh hơn… người ta ko care mấy cột skill mềm kiểu commun hay elicitation."
Dịch ra cho dễ dùng: junior thì CV là để lọt qua bộ lọc từ khoá, nên tên công cụ, tên tài liệu, tên phương pháp cứ ghi đủ, miễn là bạn nói được về nó. Từ middle trở lên thì ngược lại, người ta đọc CV để tìm dự án giống cái họ đang làm, nên nhóm dự án theo domain và để cái gần với công ty đó lên đầu. Còn mấy cột "kỹ năng giao tiếp: 5 sao" thì thật lòng là không ai chấm cả — bỏ đi lấy chỗ ghi thêm một dự án.
Vậy cuối cùng nộp hay không nộp
Nếu bạn đang cầm một cái JD dài hai trang và thấy hụt hơi, thì thứ tự việc cần làm là: tách ba nhóm dòng ra, chấm điểm mình trên nhóm bắt buộc thật, quá 50% thì nộp; chuẩn bị sẵn một câu chuyện ba tầng cho phần mình thiếu; mang theo một thứ cho xem được thay vì đi tay không; và trong buổi phỏng vấn nhớ hỏi ngược ba câu về quyền quyết định, thời gian và đãi ngộ. JD rộng ra là chuyện đang xảy ra thật và mình nghĩ nó còn rộng nữa, nên cái mình kiểm soát được không phải là làm cho nó hẹp lại, mà là biết phần nào trong đó đáng nhận.
À, còn chuyện vô phòng phỏng vấn mà gặp câu mình không biết thì trả lời sao, mình có viết riêng một bài rồi, bạn tìm đọc thêm nhé.
Hi vọng bài viết giúp bạn bớt tự loại mình trước khi người ta kịp đọc CV. Cảm ơn bạn đã đọc tới đây, có gì chưa đúng hoặc bạn có trải nghiệm khác thì để lại comment cho mình với nha :D
Bình luận (0)
Bạn cần đăng nhập để bình luận