Mở đầu — vì sao bài này quan trọng
Có một nghịch lý mà gần như mọi sinh viên muốn vào nghề BA đều đâm đầu vào: nhà tuyển dụng đòi kinh nghiệm, nhưng không ai chịu cho bạn kinh nghiệm để có kinh nghiệm. Bạn nộp hồ sơ, ô "kinh nghiệm liên quan" trống trơn, và bạn tự nhủ "chắc phải xin được việc mới có cái để viết vào đây". Vòng luẩn quẩn này khiến rất nhiều bạn giỏi bỏ cuộc trước cả khi được gọi phỏng vấn.
Mock project — tạm dịch là "dự án mô phỏng" hay "dự án tự dựng" — chính là cách bạn tự phá vỡ vòng luẩn quẩn đó. Thay vì chờ ai đó trao cho bạn cơ hội, bạn tự tạo ra một bài toán nghiệp vụ giống thật, rồi tự đóng vai BA giải quyết nó từ đầu đến cuối: từ phỏng vấn "stakeholder" (dù stakeholder có thể là bạn bè hoặc chính bạn tưởng tượng ra), phân tích quy trình, cho tới viết tài liệu và vẽ mô hình. Sản phẩm cuối cùng là những deliverable (tài liệu bàn giao) mà bạn có thể đưa thẳng vào portfolio và mang đi phỏng vấn.
Điểm mấu chốt bạn cần khắc cốt ghi tâm ngay từ đầu: nhà tuyển dụng BA fresher không kỳ vọng bạn từng làm dự án tiền tỷ. Họ muốn thấy bạn tư duy như một BA — biết đặt câu hỏi đúng, biết bóc tách vấn đề, biết diễn đạt yêu cầu rõ ràng. Một mock project tốt chứng minh điều đó thuyết phục hơn mười dòng "kỹ năng mềm" liệt kê suông trong CV. Bài này sẽ dạy bạn cách xây mock project từ con số không — kể cả khi bạn chưa từng làm gì trong ngành.
Khái niệm cốt lõi
Mock project khác gì bài tập trên lớp?
Bài tập trên lớp thường cho sẵn đề, cho sẵn dữ liệu, và có đáp án đúng. Mock project thì ngược lại: bạn tự chọn một vấn đề nghiệp vụ có thật ngoài đời, tự đi tìm thông tin, và không có "đáp án" — chỉ có giải pháp hợp lý hoặc không hợp lý. Chính sự mơ hồ đó mới giống công việc BA thật, và chính vì bạn xử lý được sự mơ hồ đó, nhà tuyển dụng mới tin bạn.
Ba nguồn nguyên liệu để dựng mock project
Nhiều bạn nghĩ "mình chưa đi làm thì lấy đâu ra chất liệu". Thực tế bạn đang ngồi trên cả mỏ vàng:
Một là, trải nghiệm sinh viên của chính bạn. Bạn đã từng đăng ký học phần qua một cổng thông tin chậm rề rề, xếp hàng đóng học phí, đặt đồ ăn qua app, mượn sách thư viện, tham gia câu lạc bộ có quỹ cần quản lý. Mỗi trải nghiệm khó chịu là một "pain point" — và mỗi pain point là hạt giống của một mock project. Bạn hiểu ngữ cảnh này hơn bất kỳ ai vì bạn chính là người dùng.
Hai là, doanh nghiệp nhỏ quanh bạn. Quán cà phê của người quen, tiệm nail của chị họ, cửa hàng bán quần áo online của bạn cùng phòng. Những nơi này thường quản lý bằng sổ tay hoặc Excel lộn xộn, và họ rất sẵn lòng ngồi kể cho bạn nghe họ vận hành thế nào — đó chính là "elicitation" (khai thác yêu cầu) thật 100%.
Ba là, các sản phẩm số đã có sẵn. Bạn có thể lấy một app đang chạy như Shopee, Momo, Grab và làm "reverse engineering" — phân tích ngược một tính năng để tự viết lại tài liệu yêu cầu như thể bạn là BA của tính năng đó.
Deliverable — thứ thực sự đi vào portfolio
Mock project chỉ có giá trị khi nó tạo ra sản phẩm cầm nắm được. Ở cấp fresher, bộ deliverable tối thiểu nên có: một Problem Statement (mô tả vấn đề nghiệp vụ), một sơ đồ quy trình hiện tại (as-is) và mong muốn (to-be), một danh sách requirements kèm vài user stories, và ít nhất một mô hình trực quan như wireframe đơn giản hoặc use case diagram. Lưu ý: các kỹ thuật chi tiết như cách viết user story chuẩn, cách vẽ BPMN hay ERD sẽ được dạy riêng ở những bài sau; ở bài này chúng ta tập trung vào cách tổ chức một mock project và biến nó thành portfolio, chứ không đi sâu từng kỹ thuật.
Tình huống thực tế
Tình huống 1: Minh và app đặt cơm căn-tin ký túc xá
Minh là sinh viên năm cuối ngành Hệ thống thông tin ở TP.HCM, chưa có kinh nghiệm BA nào. Cậu chọn một vấn đề cực kỳ gần gũi: giờ trưa căn-tin ký túc xá luôn kẹt cứng, sinh viên xếp hàng 20 phút mới tới lượt gọi món, nhiều bạn bỏ ăn vì không kịp giờ học chiều.
Minh không code một dòng nào. Cậu làm đúng việc của BA. Đầu tiên cậu phỏng vấn 12 sinh viên và 2 cô bán cơm, ghi lại rằng cao điểm 11h30–12h15 có khoảng 300 lượt mua dồn vào 45 phút, mỗi giao dịch trung bình 90 giây vì phải chọn món và thối tiền. Cậu vẽ quy trình as-is bằng bảy bước và chỉ ra ba điểm nghẽn: chọn món tại quầy, tính tiền thủ công, và thối tiền mặt. Sau đó cậu đề xuất quy trình to-be với ý tưởng đặt trước qua app và thanh toán online, rồi viết 8 requirements cùng 5 user story kiểu "Là sinh viên, tôi muốn đặt món trước 30 phút để không phải xếp hàng". Cuối cùng cậu vẽ 4 màn hình wireframe bằng Figma bản miễn phí.
Bài học: Minh không cần dữ liệu tỷ đồng. Cậu dùng con số quan sát được (300 lượt/45 phút, 90 giây/giao dịch) để định lượng vấn đề — và chính những con số đó khiến hội đồng phỏng vấn gật gù. Khi được hỏi "em từng làm dự án nào chưa", Minh có một câu chuyện đầu-cuối để kể, thay vì ậm ừ.
Tình huống 2: Lan và tiệm bánh nhà cô ruột
Lan học ngành Ngôn ngữ Anh, hoàn toàn trái ngành, muốn chuyển sang BA. Cô không có nền IT nên chọn hướng an toàn: lấy tiệm bánh của cô ruột ở Đà Nẵng làm case. Tiệm nhận đặt bánh sinh nhật qua Facebook, ghi đơn vào một cuốn sổ, và tháng nào cũng có 2–3 đơn bị quên hoặc giao nhầm ngày.
Lan ngồi với cô ruột đúng hai buổi tối, đóng vai BA phỏng vấn stakeholder thật. Cô phát hiện ra vấn đề gốc không phải "thiếu app" mà là "không có nơi tập trung theo dõi trạng thái đơn". Đây là một insight rất BA: đào tới nguyên nhân gốc thay vì vội nhảy vào giải pháp. Lan lập một business rule catalog đơn giản (ví dụ: đơn phải đặt cọc 50%, đơn nhận trước tối thiểu 24 giờ), vẽ quy trình xử lý đơn, và thiết kế một bảng theo dõi trạng thái đơn hàng ngay trên Google Sheets — giải pháp rẻ, khả thi, hợp túi tiền một tiệm nhỏ.
Bài học: Portfolio của Lan mạnh không phải vì công nghệ hoành tráng, mà vì nó cho thấy cô hiểu giải pháp phải vừa vặn với bối cảnh và ngân sách của stakeholder. Trong buổi phỏng vấn tại một công ty outsourcing, cô kể rằng mình đã đề xuất Google Sheets thay vì app đắt tiền — và người phỏng vấn đánh giá đây là tư duy "business-oriented" đúng chất BA. Trái ngành hoàn toàn vẫn có thể tạo portfolio thuyết phục.
Tình huống 3: Nhóm ba bạn và mock project "reverse engineering" Momo
Ba bạn cùng lớp — Huy, Trang, Đức — không có doanh nghiệp thật nào để tiếp cận, nên chọn cách phân tích ngược. Họ lấy tính năng "chia tiền nhóm" (split bill) của một ví điện tử như Momo làm đối tượng, và giả định mình là BA được giao viết lại tài liệu cho tính năng đó.
Họ chia vai: Huy đóng vai BA phỏng vấn "Product Owner" (do Trang đóng), Đức đóng vai dev đặt câu hỏi làm rõ để test độ chặt chẽ của tài liệu. Họ dùng thử tính năng thật, ghi lại từng bước luồng người dùng, rồi viết use case, liệt kê các trường hợp ngoại lệ (người được chia tiền chưa có ví thì sao, chia lẻ tiền không chia hết thì làm tròn thế nào), và viết acceptance criteria cho vài user story. Toàn bộ đưa lên một trang Notion công khai.
Bài học: Không cần stakeholder thật, nhóm này vẫn luyện được kỹ năng bóc tách luồng nghiệp vụ và — quan trọng nhất — tư duy về edge case (trường hợp biên), thứ phân biệt BA non và BA chắc tay. Việc đóng vai lẫn nhau (BA – PO – Dev) mô phỏng đúng động lực trong một team thật. Khi đi phỏng vấn, mỗi bạn kể cùng một dự án nhưng ở góc nhìn khác nhau, nghe rất tự nhiên và đáng tin.
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để bạn dựng một mock project từ zero. Đừng làm 5 dự án hời hợt — hãy làm 1–2 dự án tới nơi tới chốn.
Bước 1 — Chọn một vấn đề bạn thực sự hiểu. Ưu tiên pain point từ chính đời sống sinh viên hoặc một doanh nghiệp nhỏ bạn tiếp cận được. Tiêu chí: vấn đề đủ nhỏ để làm trong 2–3 tuần, đủ thật để có người kể cho bạn nghe, và bạn có thể diễn đạt nó thành một câu.
Bước 2 — Viết Problem Statement. Một đoạn ngắn trả lời: Ai đang gặp khó khăn gì? Vì sao đó là vấn đề? Nếu không giải quyết thì hậu quả ra sao? Cố gắng nhét ít nhất một con số định lượng vào (thời gian chờ, số đơn lỗi, số tiền thất thoát) — con số làm câu chuyện của bạn có sức nặng.
Bước 3 — Xác định stakeholder và đi khai thác thông tin. Liệt kê những ai liên quan (người dùng, người vận hành, người trả tiền). Nếu có người thật, hãy phỏng vấn họ 30–60 phút và ghi chép. Nếu không, dùng cách reverse engineering một sản phẩm có sẵn. Đừng bịa số liệu — hãy quan sát hoặc hỏi để có số thật.
Bước 4 — Vẽ quy trình as-is. Mô tả cách mọi thứ đang diễn ra hiện tại, từng bước một, và đánh dấu những điểm nghẽn. Đây là nơi bạn thể hiện khả năng nhìn ra vấn đề nằm ở đâu.
Bước 5 — Đề xuất quy trình to-be và requirements. Mô tả cách bạn muốn mọi thứ vận hành sau khi cải tiến, kèm một danh sách requirements và vài user story minh họa. Nhớ nguyên tắc: giải pháp phải vừa với ngân sách và năng lực của stakeholder.
Bước 6 — Tạo một mô hình trực quan. Có thể là wireframe vài màn hình, một use case diagram, hay một bảng dữ liệu mẫu. Một hình ảnh trực quan khiến portfolio của bạn "nhìn là hiểu", đỡ phải đọc mấy trang chữ.
Bước 7 — Đóng gói thành deliverable và câu chuyện. Gom tất cả vào một file (PDF hoặc Notion), viết một đoạn tóm tắt 5 câu về bối cảnh – vấn đề – việc bạn làm – kết quả – bài học. Đoạn tóm tắt này chính là thứ bạn sẽ nói trong phỏng vấn.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp. Rất nhiều bạn mới học vừa nghe vấn đề đã lao vào "làm một cái app". BA giỏi dành thời gian ở phần "vì sao" trước khi tới phần "làm gì". Mẹo: bắt mình viết xong Problem Statement và quy trình as-is rồi mới được nghĩ tới giải pháp.
Lỗi 2 — Ôm dự án quá to. "Xây lại toàn bộ Shopee" là cái bẫy chết người — bạn sẽ bỏ dở giữa chừng. Mẹo: thu hẹp về đúng MỘT tính năng hoặc MỘT quy trình. Một mock project nhỏ mà hoàn chỉnh giá trị gấp mười lần một dự án khổng lồ dở dang.
Lỗi 3 — Bịa số liệu cho đẹp. Người phỏng vấn có kinh nghiệm sẽ hỏi "con số này em lấy từ đâu?", và nếu bạn bịa, bạn sập ngay. Mẹo: mọi con số phải đến từ quan sát, phỏng vấn, hoặc trải nghiệm thật của bạn — thà số nhỏ mà thật.
Lỗi 4 — Chỉ có tài liệu, không có câu chuyện. Portfolio đẹp mà bạn không kể được mạch lạc thì cũng vô dụng khi phỏng vấn. Mẹo: luyện kể mỗi mock project trong 90 giây theo cấu trúc bối cảnh – vấn đề – hành động – kết quả.
Lỗi 5 — Làm một mình mãi. Nhờ một người quen đóng vai stakeholder hoặc dev để họ "vặn" bạn. Bị hỏi khó lúc luyện tập còn hơn bị hỏi khó lúc phỏng vấn thật. Mẹo: rủ 1–2 bạn cùng học làm chung, chia vai như tình huống 3.
Bài tập thực hành
- Liệt kê pain point (30 phút). Viết ra 5 khó chịu bạn từng gặp trong vai trò sinh viên (đăng ký học phần, gửi xe, đặt cơm, mượn sách, quản lý quỹ CLB...). Với mỗi cái, viết một câu Problem Statement thô.
- Chọn và cam kết (10 phút). Chọn đúng MỘT pain point khả thi nhất để làm trong 2–3 tuần. Viết ra lý do bạn chọn nó và ai là stakeholder bạn có thể tiếp cận.
- Khai thác thông tin thật (1 buổi). Phỏng vấn ít nhất 3 người liên quan hoặc, nếu không có, chọn một tính năng của app quen thuộc để phân tích ngược. Ghi lại tối thiểu 2 con số định lượng thật.
- Dựng bộ deliverable tối thiểu (1 tuần). Hoàn thành: Problem Statement, quy trình as-is, quy trình to-be, danh sách requirements, và 1 mô hình trực quan. Gom vào một trang Notion.
- Luyện pitch 90 giây (15 phút). Viết và tập nói phần tóm tắt dự án theo cấu trúc bối cảnh – vấn đề – hành động – kết quả – bài học. Quay video tự xem lại.
Tóm tắt
Mock project là lối thoát khỏi vòng luẩn quẩn "cần kinh nghiệm để có kinh nghiệm". Bạn không cần công ty thật hay dự án triệu đô — bạn cần một vấn đề nghiệp vụ đủ nhỏ và đủ thật, cùng khả năng tư duy như một BA để bóc tách nó. Nguyên liệu ở khắp nơi: trải nghiệm sinh viên của bạn, doanh nghiệp nhỏ quanh bạn, và cả những app bạn dùng hằng ngày để phân tích ngược.
Ba tình huống của Minh, Lan và nhóm ba bạn cho thấy dù bạn đúng ngành, trái ngành, hay chẳng có stakeholder nào, vẫn luôn có một con đường dựng portfolio thuyết phục. Điều quyết định không phải độ hoành tráng của công nghệ, mà là việc bạn định lượng được vấn đề, đào tới nguyên nhân gốc, đề xuất giải pháp vừa vặn bối cảnh, và kể lại được thành một câu chuyện mạch lạc.
Hãy làm 1–2 mock project tới nơi tới chốn thay vì năm dự án hời hợt. Mỗi dự án hoàn chỉnh không chỉ là một dòng trong CV — nó là bằng chứng sống động rằng bạn đã sẵn sàng làm BA, ngay cả khi chưa ai từng trả lương cho bạn để làm điều đó.