Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là một nhà tuyển dụng đang sàng lọc 80 hồ sơ ứng viên BA cho một vị trí. Trong 80 CV đó, có 30 người ghi "có kinh nghiệm viết requirements", 25 người ghi "thành thạo user story", 20 người ghi "hiểu Agile". Tất cả đều nói được. Nhưng chỉ có 3 người cho bạn xem được: đây là tài liệu tôi từng viết, đây là process AS-IS/TO-BE tôi từng phân tích, đây là kết quả dự án tôi từng tham gia. Bạn sẽ gọi phỏng vấn ai trước?
Đây chính là lý do bài học này tồn tại. Với người chuyển từ Developer sang BA, portfolio không phải là "điểm cộng" — nó là thứ thay thế cho kinh nghiệm BA mà bạn chưa có. Bạn không có title "Business Analyst" trên LinkedIn suốt 3 năm qua. Bạn có title "Software Engineer". Portfolio chính là cây cầu chứng minh rằng những gì bạn đã làm với tư cách dev thực chất đã bao hàm rất nhiều công việc của BA — chỉ là chưa ai gọi tên nó ra.
Điều tuyệt vời là: bạn có một lợi thế mà hầu hết BA fresher không có. Bạn đã từng ở trong hệ thống thật, đọc database thật, sửa bug từ requirement mơ hồ thật. Bạn có "nguyên liệu" để dựng case study chất lượng cao mà một sinh viên mới ra trường phải mất cả năm mới tích lũy được. Bài học này sẽ dạy bạn cách biến những gì bạn đã có sẵn thành một portfolio thuyết phục, cụ thể, có thể mang đi phỏng vấn ngay.
Lưu ý: bài này tập trung riêng vào cách xây dựng portfolio — bộ case study, cách trình bày, cách đóng gói. Việc viết CV chi tiết và luyện phỏng vấn là chủ đề của các bài khác (Bài 42, 43). Ở đây, portfolio là "bộ chứng cứ", còn CV là "bản tóm tắt trỏ tới bộ chứng cứ đó".
Khái niệm cốt lõi
Portfolio BA là gì và khác gì portfolio Developer
Portfolio của developer thường là GitHub: code, repo, số commit, project chạy được. Nhà tuyển dụng dev nhìn vào để đánh giá bạn viết code sạch không, hiểu kiến trúc không.
Portfolio của BA thì hoàn toàn khác. Nó không chứng minh "bạn làm được hệ thống" mà chứng minh "bạn hiểu được vấn đề nghiệp vụ, phân tích nó, và diễn đạt lại thành yêu cầu rõ ràng để người khác xây dựng giải pháp". Vật chứng của BA là tài liệu và tư duy phân tích: sơ đồ quy trình, requirement document, user story, wireframe, ma trận phân tích, bản trình bày giải pháp.
Với người từ dev chuyển sang, portfolio BA lý tưởng cần chứng minh được ba điều: (1) bạn tư duy từ góc độ business chứ không chỉ technical; (2) bạn biết dùng các artifact chuẩn của nghề BA (BRD, user story, BPMN, ERD business-level...); (3) bạn vẫn giữ được technical fluency như một điểm khác biệt — bạn là BA "nói được ngôn ngữ của dev team".
Ba loại case study chuẩn cho dev-turned-BA
Một portfolio mạnh không cần 10 case study. Nó cần 3 case study được chọn có chủ đích, mỗi cái phục vụ một mục tiêu chứng minh khác nhau:
Case Study 1 — Process + Tech Optimization (tận dụng nền dev cũ): Chọn một module bạn từng code. Re-frame nó từ góc nhìn business: quy trình AS-IS đang có vấn đề gì, TO-BE nên như thế nào. Đây là case dễ nhất để bắt đầu vì bạn đã biết hệ thống từ bên trong. Nó chứng minh bạn chuyển được từ tư duy "sửa code" sang tư duy "cải thiện quy trình nghiệp vụ".
Case Study 2 — Greenfield / New Feature Analysis (chứng minh năng lực elicitation): Phân tích yêu cầu cho một tính năng hoàn toàn mới — có thể là ý tưởng của riêng bạn hoặc một sản phẩm bạn giả định. Ở đây bạn dựng bộ requirement từ con số 0: xác định stakeholder, đặt câu hỏi, viết user story, dựng flow. Case này chứng minh bạn không chỉ biết mô tả cái đã có, mà biết khai thác yêu cầu cho cái chưa tồn tại.
Case Study 3 — Integration / Data-heavy (tận dụng thế mạnh kỹ thuật): Một bài toán tích hợp hệ thống, đồng bộ dữ liệu, hoặc migration. Đây là "sân nhà" của dev. Bạn thể hiện được data mapping, API contract từ góc BA, edge case, non-functional requirement. Case này biến thế mạnh kỹ thuật thành khác biệt cạnh tranh rõ rệt.
Cấu trúc STAR-R cho mỗi case study
Mỗi case study nên có xương sống thống nhất, để người đọc lướt 30 giây vẫn nắm được. Tôi khuyến nghị khung STAR-R:
- Situation (Bối cảnh): Doanh nghiệp/sản phẩm nào, vấn đề gì, quy mô ra sao.
- Task (Nhiệm vụ): Với vai trò BA, bạn cần giải quyết gì.
- Action (Hành động): Các artifact bạn tạo ra — đây là phần "vật chứng", quan trọng nhất.
- Result (Kết quả): Con số, tác động. Nếu là case giả định, nêu tác động kỳ vọng có căn cứ.
- Reflection (Bài học): Bạn học được gì, sẽ làm khác đi ra sao. Phần này cho thấy độ chín.
Tình huống thực tế
Ví dụ 1 — Minh, backend dev tại một công ty logistics ở TP.HCM
Minh có 4 năm làm backend PHP cho một công ty giao vận nội thành. Anh từng code module "gán đơn cho tài xế". Khi làm portfolio, thay vì viết "tôi phát triển hệ thống dispatch", Minh re-frame thành Case Study 1.
Anh dựng sơ đồ AS-IS: điều phối viên nhìn danh sách đơn trên màn hình, gọi điện hỏi tài xế đang ở đâu, gán tay. Anh chỉ ra pain point bằng con số thu thập từ chính data anh từng truy vấn: trung bình mỗi đơn mất 6 phút để gán, 18% đơn bị gán cho tài xế ở quá xa. TO-BE: quy tắc tự động gán theo khoảng cách và tải hiện tại, điều phối viên chỉ can thiệp ngoại lệ. Anh viết 5 business rule rõ ràng, 8 user story chuẩn INVEST, một BPMN cho luồng mới, và một bảng non-functional requirement (thời gian gán < 2 giây).
Bài học rút ra: Điều làm hồ sơ của Minh nổi bật không phải là anh từng code cái này, mà là anh tách được phần business rule ra khỏi code và trình bày nó bằng ngôn ngữ điều phối viên hiểu được. Khi phỏng vấn, câu hỏi "vì sao bạn chọn ngưỡng khoảng cách 3km" khiến anh tỏa sáng — vì anh có dữ liệu thật để bảo vệ. Nhà tuyển dụng nhận xét: "Đây là BA hiểu vận hành, không phải BA vẽ sơ đồ suông."
Ví dụ 2 — Lan, frontend dev chuyển hướng, không có "hệ thống cũ" đủ hấp dẫn
Lan làm frontend cho các trang landing page, hệ thống cũ không có gì phức tạp để dựng case study về quy trình. Đây là tình huống rất phổ biến và làm nhiều người bế tắc. Lan giải quyết bằng cách xây Case Study 2 dạng greenfield giả định: phân tích yêu cầu cho một app đặt lịch phòng khám nha khoa nhỏ.
Cô không có khách hàng thật, nên cô làm điều thông minh: phỏng vấn thật 3 phòng khám quen biết trong khu phố, ghi lại đúng nỗi đau của họ (bệnh nhân gọi điện đặt lịch trùng giờ, quên lịch hẹn, không có nhắc nhở). Từ đó cô dựng stakeholder map, một bộ 12 user story, wireframe low-fidelity trên Figma, và một bảng ưu tiên MoSCoW. Cô nói rõ trong portfolio: "Đây là dự án cá nhân, dữ liệu nỗi đau thu thập từ phỏng vấn thực tế 3 phòng khám."
Bài học rút ra: Không có dự án thật không phải là cái cớ. Bạn có thể tạo ra "bằng chứng thật" bằng cách đi thu thập yêu cầu thật, dù sản phẩm là giả định. Sự trung thực ("đây là dự án tự làm") kết hợp với chất liệu thật (phỏng vấn thật) tạo ra độ tin cậy cao hơn nhiều so với một case study bịa đặt hoàn toàn. Lan được nhận vào một startup edtech chính nhờ case study này chứng minh cô biết cách hỏi — kỹ năng elicitation.
Ví dụ 3 — Tuấn và case study tích hợp tại một fintech
Tuấn từng làm integration engineer, chuyên nối API giữa các hệ thống. Anh dựng Case Study 3 quanh một bài toán tích hợp cổng thanh toán vào một ví điện tử giả định (dựa trên kinh nghiệm thật nhưng đã ẩn danh dữ liệu công ty cũ vì lý do bảo mật).
Anh trình bày: sequence diagram luồng thanh toán, bảng data mapping giữa hai hệ thống (field nào map field nào, kiểu dữ liệu, quy tắc chuyển đổi), danh sách 15 edge case (timeout, double charge, refund một phần), và non-functional requirement về bảo mật (tuân thủ tokenization thẻ). Anh đóng khung tất cả bằng ngôn ngữ business: "Nếu double charge xảy ra, khách mất tiền, mất niềm tin, công ty gánh chi phí đối soát."
Bài học rút ra: Với dev chuyển sang BA, case study tích hợp là "vũ khí bí mật". Rất ít BA thuần business làm được data mapping và edge case ở độ sâu này. Nhưng Tuấn suýt phạm sai lầm: bản nháp đầu tiên của anh toàn thuật ngữ kỹ thuật, đọc như tài liệu dev. Sau khi nhờ mentor review, anh thêm cột "tác động nghiệp vụ" cho mỗi edge case. Chính sự chuyển ngữ từ tech sang business là điều biến một dev thành một BA trong mắt nhà tuyển dụng.
Hướng dẫn từng bước
Bước 1 — Kiểm kê "kho nguyên liệu" của bạn. Liệt kê mọi module, dự án, tính năng bạn từng đụng tay khi còn là dev. Với mỗi cái, tự hỏi: nó giải quyết vấn đề business gì? Ai là người dùng cuối? Nếu bạn không nhớ nổi vấn đề business, đó thường là dấu hiệu case đó không phù hợp để dựng portfolio.
Bước 2 — Chọn 3 case theo đúng ba loại chuẩn. Đừng chọn 3 case cùng loại. Bạn cần bộ ba phủ được: cải thiện quy trình (CS1), khai thác yêu cầu mới (CS2), và tích hợp/dữ liệu (CS3). Bộ ba này chứng minh bạn toàn diện.
Bước 3 — Với mỗi case, dựng đủ bộ artifact tối thiểu. Một case study hoàn chỉnh nên có ít nhất: một sơ đồ quy trình (BPMN hoặc flowchart), một bộ user story hoặc requirement, một hình ảnh trực quan (wireframe hoặc mockup), và một bảng phân tích (business rule, MoSCoW, data mapping — tùy loại case). Đừng để case study chỉ toàn chữ.
Bước 4 — Viết theo khung STAR-R. Mỗi case dài 1–2 trang là đủ. Mở đầu bằng bối cảnh, kết bằng bài học. Chèn artifact vào giữa. Nhớ luôn dịch phần technical sang tác động business.
Bước 5 — Ghi rõ tính chất của dữ liệu. Nếu là dự án thật đã ẩn danh, ghi "đã ẩn danh vì lý do bảo mật". Nếu là dự án tự làm, ghi "personal project". Sự minh bạch bảo vệ bạn và tăng độ tin cậy. Đừng bao giờ giả vờ dự án cá nhân là dự án công ty.
Bước 6 — Đóng gói và công bố. Chọn một nơi để host: một trang Notion public sạch sẽ là lựa chọn phổ biến và miễn phí; một Google Drive có cấu trúc thư mục; hoặc một PDF portfolio gọn gàng để đính kèm email. Đặt link portfolio ngay trên đầu CV. Đảm bảo link mở được không cần đăng nhập.
Bước 7 — Chuẩn bị "phiên bản 90 giây" cho mỗi case. Trong phỏng vấn, bạn sẽ được hỏi "kể về một dự án". Luyện kể mỗi case trong 90 giây theo STAR-R. Portfolio là bằng chứng viết; phần kể là bằng chứng nói. Hai thứ phải khớp nhau.
Lỗi thường gặp & mẹo
Lỗi 1 — Portfolio đọc như tài liệu kỹ thuật. Đây là cái bẫy số một của dev-turned-BA. Bạn viết "endpoint trả về 500 khi payload sai schema" thay vì "khi thông tin nhập sai định dạng, hệ thống báo lỗi khiến khách bỏ cuộc giữa chừng". Mẹo: sau khi viết xong, đọc lại và với mỗi câu kỹ thuật, thêm câu trả lời cho "vậy thì sao, ảnh hưởng gì tới business?".
Lỗi 2 — Nhồi 10 case study. Nhiều không bằng chất. Ba case sâu, có artifact thật, thắng mười case hời hợt. Nhà tuyển dụng không có thời gian đọc mười câu chuyện.
Lỗi 3 — Chỉ có chữ, không có hình. BA là nghề trực quan hóa. Một portfolio không có một sơ đồ nào tự mâu thuẫn với chính công việc BA. Luôn có ít nhất một artifact hình ảnh mỗi case.
Lỗi 4 — Bịa số liệu kết quả. "Giảm 40% thời gian xử lý" mà không giải thích được cách tính sẽ sụp đổ ngay trong phỏng vấn. Nếu là case giả định, hãy ghi "tác động kỳ vọng" và giải thích logic ước lượng, thay vì phán một con số như thật.
Lỗi 5 — Quên yếu tố con người. Dev quen với hệ thống, dễ bỏ quên stakeholder. Portfolio BA phải cho thấy bạn nghĩ tới người dùng, người vận hành, người ra quyết định — không chỉ tới luồng dữ liệu.
Mẹo vàng: Xin một mentor hoặc một BA đang đi làm review portfolio của bạn trước khi công bố. Một cặp mắt BA thật sự sẽ chỉ ra ngay chỗ nào bạn còn "nói giọng dev". Đây là khoản đầu tư rẻ nhất cho tác động lớn nhất.
Bài tập thực hành
- Kiểm kê kho nguyên liệu: Liệt kê tối thiểu 5 module/dự án bạn từng làm khi là dev. Với mỗi cái, viết một câu về vấn đề business nó giải quyết. Khoanh tròn 3 cái có "chất business" rõ nhất.
- Dựng Case Study 1 hoàn chỉnh: Chọn một module bạn từng code. Vẽ sơ đồ AS-IS và TO-BE, viết 5 business rule và ít nhất 6 user story chuẩn INVEST. Xác định 2 pain point kèm con số (thật hoặc ước lượng có căn cứ). Trình bày theo khung STAR-R trong 1–2 trang.
- Bài tập chuyển ngữ: Lấy 5 câu mô tả kỹ thuật từ một dự án cũ. Viết lại mỗi câu thành phiên bản "business impact" mà một người không biết code vẫn hiểu.
- Đóng gói: Tạo một trang Notion (hoặc PDF) chứa Case Study 1 với đầy đủ artifact. Đặt link lên đầu CV nháp của bạn. Nhờ một người không làm kỹ thuật đọc thử và hỏi họ: "Bạn hiểu tôi đã làm gì không?"
- Luyện kể 90 giây: Ghi âm bản thân kể Case Study 1 trong đúng 90 giây theo STAR-R. Nghe lại và loại bỏ mọi thuật ngữ kỹ thuật không cần thiết.
Tóm tắt
Portfolio là cây cầu đưa bạn từ "developer từng làm những việc giống BA" sang "BA có bằng chứng cụ thể". Với người chuyển nghề, nó quan trọng hơn cả CV vì nó thay thế cho kinh nghiệm BA mà bạn chưa chính thức có. Hãy xây đúng ba case study chuẩn: một về cải thiện quy trình (tận dụng module cũ), một greenfield (chứng minh elicitation), một tích hợp/dữ liệu (biến thế mạnh kỹ thuật thành khác biệt). Mỗi case dựng theo khung STAR-R và bắt buộc đính kèm artifact thật — sơ đồ, user story, wireframe, bảng phân tích.
Ba nguyên tắc cần khắc cốt: (1) luôn dịch technical sang business impact; (2) chất hơn lượng, ba case sâu là đủ; (3) minh bạch về tính chất dữ liệu. Lợi thế lớn nhất của bạn — technical fluency — sẽ tỏa sáng nếu bạn đóng khung nó bằng ngôn ngữ nghiệp vụ. Làm được điều đó, bạn không còn là dev đang cố làm BA. Bạn là một BA hiếm có: người nói được cả hai ngôn ngữ.