↓ Chuyển đến nội dung chính
BA fresher dựng portfolio bằng case simulation trên bàn làm việc
  1. Bài viết/

Chưa có dự án thì portfolio BA viết gì? Làm case simulation

·
Đặng Đức Quân
Tác giả
Đặng Đức Quân
Chuyện nghề BA trong lĩnh vực sản xuất. Viết cho mình, và cho cả những ai đang muốn dấn thân vào con đường này.

Cập nhật lần cuối:

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.

người tuyển fresher nhìn gì trong portfolio
#

Một CV fresher ghi giao tiếp tốt, tư duy logic, chịu được áp lực thì chẳng giúp ai phân biệt bạn với người khác, thứ giúp được là bằng chứng bạn nhìn vào một quy trình mà chỉ ra đúng chỗ đang tắc, chỗ đang thừa, rồi đề xuất cách sửa có lý do. Case simulation làm đúng việc đó, bạn không cần khách hàng, chỉ cần một quy trình có thật, có người làm, và có chỗ đang khó chịu.

chọn quy trình nào để làm case
#

Chọn thứ bạn từng ở bên trong hoặc quan sát được, như quy trình gọi món ở quán cà phê bạn làm thêm, đăng ký môn học ở trường, nhận trả sách ở thư viện, đặt lịch khám ở một phòng khám nhỏ, còn mấy thứ quá to như ERP cho tập đoàn thì né ra, vì bạn sẽ chỉ vẽ được cái vỏ. Tiêu chí của mình là quy trình có khoảng 4–7 bước, có ít nhất hai vai trò, và có ít nhất một chỗ dữ liệu bị chép tay hoặc gõ lại từ nơi này sang nơi khác, vì những chỗ chuyển giao như vậy thường là nơi lỗi và chậm trễ chui ra, rất đáng để phân tích.

một case đủ dùng gồm năm phần
#

Phần một là bối cảnh, chừng năm dòng, ai làm, làm ở đâu, quy trình nhắm tới cái gì, chưa phân tích gì ở đây cả.

Phần hai là sơ đồ as-is, vẽ quy trình hiện tại bằng swimlane, mỗi vai trò một làn, chưa quen ký hiệu thì bài BPMN cho người mới: vẽ as-is và to-be đủ để bạn bắt đầu.

Phần ba là pain point, phần ăn điểm nhất. Đừng viết quy trình còn thủ công, hãy viết cụ thể và có ước lượng, ví dụ mỗi phiếu đăng ký phải gõ lại vào bảng tính, giả sử mất khoảng 3 phút một phiếu thì cả mùa đăng ký mất bao nhiêu giờ. Con số ước lượng thì được, miễn ghi rõ đó là ước lượng và bạn tính thế nào.

Phần bốn là to-be, chỉ cần ba bốn thay đổi chính, mỗi thay đổi gắn với một pain point ở phần ba, đừng vẽ lại cả thế giới.

Phần năm là requirement, ba đến năm user story, mỗi story có acceptance criteria theo Given-When-Then, cách viết từng câu có trong bài User story và acceptance criteria.

Mẹo
Giữ cả case trong khoảng 8–10 trang. Ngắn và sắc thì người đọc đọc hết, dài và lan man thì họ lướt qua.

một case sâu hơn năm case nông
#

Nhiều bạn làm năm case, mỗi case một trang, mỗi case một lĩnh vực, nhìn thì đa dạng nhưng chẳng case nào đủ sâu để người đọc thấy bạn hiểu vấn đề tới đâu. Một case có as-is, có ước lượng, có to-be, lại thêm một đoạn tự phản biện kiểu áp dụng thay đổi này thì rủi ro là gì, ai sẽ phản đối, thường đáng giá hơn nhiều. Lúc phỏng vấn câu dễ gặp là vì sao em chọn giải pháp này, trả lời được câu đó là case đã làm xong nhiệm vụ, còn cách trả lời có cấu trúc thì xem bài Phỏng vấn BA fresher: câu hỏi thật.

đừng biến case giả thành kinh nghiệm thật
#

Ghi case simulation thành “dự án tối ưu quy trình kho cho doanh nghiệp X” là tự đặt bẫy cho mình, người phỏng vấn chỉ cần hỏi vài câu về stakeholder, về ai ký duyệt, về lúc triển khai trục trặc gì, là câu chuyện bắt đầu hở. Ghi đúng thì đơn giản lắm, “case tự phân tích dựa trên quy trình mình quan sát, không phải dự án khách hàng”, câu này không làm bạn mất điểm mà còn cho thấy bạn trung thực, một phẩm chất BA rất cần khi đứng giữa các bên.

Ghi thêm công cụ bạn đã dùng, draw.io để vẽ, Google Docs hay Notion để viết, Jira bản miễn phí để quản lý backlog, người tuyển thấy bạn quen tool rồi thì bớt lo phần onboarding.

Case simulation không biến bạn thành BA có kinh nghiệm, nó chỉ cho thấy bạn đã tập nghĩ như BA trước khi được trả lương để làm việc đó, mà với vị trí fresher thì thế đã là một lợi thế rõ. Nếu phải chọn một quy trình quanh mình để làm case đầu tiên, bạn chọn cái nào, và chỗ nào trong đó đang làm người làm khó chịu nhất? Kể mình nghe qua Facebook hoặc LinkedIn.

Bài viết liên quan

Phỏng vấn BA fresher: câu hỏi thật, trả lời theo STAR

·
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.

BA có cần biết SQL không? SELECT, JOIN, GROUP BY là đủ sống

·
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.

Một ngày của BA dưới xưởng: xỏ giày bảo hộ rồi hẵng nói

·
Lần đầu xuống xưởng, mình mang theo trong đầu nguyên cái quy trình đã đọc trên giấy, công đoạn nào xong thì cập nhật ngay, rõ ràng, đẹp đẽ, rồi đứng nhìn một lúc mới thấy dưới này người ta làm khác hẳn. Công nhân xử lý một mạch từ đầu tới cuối, cuối ngày mới ngồi viết vào biên bản. Khác xa luôn. Mà nghĩ kỹ thì cũng chẳng ai sai. Quy trình trên giấy được viết cho người ngồi văn phòng đọc, còn công nhân thì làm theo cách nào kịp hàng nhất. Từ hôm đó mình tin là muốn lấy requirement thật cho ERP hay MES thì phải xuống xưởng, chứ ngồi phòng họp nghe người ta kể lại thì chỉ được một nửa câu chuyện.