Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 22 — 30 ngày đầu làm BA: checklist sống còn

Sinh Viên Mới Ra Trường: Bắt Đầu Nghề BA Bài 22/60

Mở đầu — vì sao bài này quan trọng

Bạn vừa nhận offer BA đầu tiên. Chúc mừng! Nhưng ngay sau cảm giác vui sướng đó là một nỗi lo âm thầm mà gần như fresher nào cũng gặp: "30 ngày tới mình phải làm gì? Sếp kỳ vọng gì? Nếu mình ngồi im vì chưa biết requirement thì có bị đánh giá là lười không?"

Sự thật phũ phàng là: 30 ngày đầu tiên định hình gần như toàn bộ ấn tượng của team về bạn trong cả năm đầu. Không phải vì bạn cần chứng minh mình giỏi phân tích — mà vì team đang âm thầm trả lời một câu hỏi khác: "Người này có đáng tin không? Giao việc có yên tâm không?" Trong giai đoạn này, không ai kỳ vọng bạn viết được một bản BRD hoàn hảo hay đàm phán scope với stakeholder khó tính. Cái người ta nhìn là: bạn học context nhanh không, bạn chủ động hỏi hay ngồi im, bạn có làm được những việc nhỏ một cách chỉn chu và đúng hạn không.

Nhiều fresher mắc sai lầm ngược nhau. Một nhóm thì quá thụ động — chờ được giao việc, chờ được "training bài bản", ba tuần trôi qua vẫn chưa hiểu sản phẩm công ty làm gì. Nhóm còn lại thì quá hăng — nhảy vào đòi thay đổi quy trình, chê tài liệu cũ, phát biểu ý kiến trong họ khi chưa hiểu bối cảnh. Cả hai đều khiến bạn mất điểm.

Bài này cho bạn một checklist sống còn — một tấm bản đồ cụ thể theo từng tuần để bạn biết chính xác nên làm gì, nên tránh gì, và làm sao để đến ngày thứ 30 bạn không còn là "bạn fresher mới vào" mà đã là "một thành viên bắt đầu tạo ra giá trị". Đây không phải lý thuyết — đây là những việc bạn mở laptop ra là làm được ngay.

Khái niệm cốt lõi

Nguyên tắc "Học trước, làm sau, đề xuất sau cùng"

30 ngày đầu chia thành ba giai đoạn tâm lý rõ rệt, tương ứng với ba tuần:

  • Tuần 1 — Quan sát & hấp thụ context. Nhiệm vụ duy nhất: hiểu bối cảnh. Sản phẩm là gì, ai dùng, team vận hành ra sao, tài liệu nằm ở đâu.
  • Tuần 2 — Bắt đầu đóng góp việc nhỏ. Nhận task nhỏ, có kiểm soát: cập nhật tài liệu, tham gia viết một phần user story, ghi biên bản họp.
  • Tuần 3–4 — Chạy độc lập một mảng nhỏ. Sở hữu (own) một feature nhỏ hoặc một tài liệu từ đầu đến cuối, dưới sự giám sát của mentor.
Nguyên tắc vàng: đừng đề xuất thay đổi lớn trong 30 ngày đầu. Bạn chưa đủ context để biết vì sao mọi thứ đang như vậy. Cái bạn thấy "vô lý" có thể là kết quả của một cuộc đánh đổi bạn chưa biết.

Ba trục bạn phải "map" trong đầu

Một BA giỏi 30 ngày đầu không cố nhớ mọi thứ, mà xây được ba tấm bản đồ tinh thần:

  • Bản đồ sản phẩm (Product map): Sản phẩm giải quyết vấn đề gì? Có bao nhiêu module chính? Luồng nghiệp vụ cốt lõi (core flow) là gì? Ví dụ với app ví điện tử: nạp tiền → thanh toán → rút tiền → đối soát.
  • Bản đồ con người (People map): Ai là PO/PM, ai là dev lead, ai là QA lead, ai là stakeholder nghiệp vụ, ai là mentor của bạn. Ai quyết định cái gì.
  • Bản đồ hệ thống công cụ (Tooling map): Requirement nằm ở Jira hay Confluence? Tài liệu cũ ở đâu? Quy ước đặt tên ticket ra sao? Team dùng Slack channel nào cho việc gì.

Deliverable của 30 ngày đầu là gì?

Nhiều fresher tưởng phải tạo ra tài liệu "khủng". Không. Deliverable thực sự của tháng đầu là:

  • Một learning note / onboarding doc ghi lại toàn bộ những gì bạn học được (rất giá trị, vì người vào sau sẽ dùng lại).
  • Vài task nhỏ hoàn thành đúng hạn, không lỗi vặt.
  • Sự tin tưởng của team.
Đó mới là thứ được đánh giá, chứ không phải một bản SRS dài 40 trang bạn viết vội mà không ai đọc.

Tình huống thực tế

Tình huống 1 — Minh, fresher BA tại một fintech ở TP.HCM (đội ~120 người)

Minh vào làm BA cho mảng "ví điện tử" của một công ty fintech. Tuần đầu, thay vì chờ được giao việc, Minh chủ động xin mentor cho quyền đọc 5 tài liệu SRS và 10 user story cũ đã release. Cậu vừa đọc vừa ghi lại vào một file Confluence tên "Minh's Onboarding Notes" tất cả thuật ngữ chưa hiểu: "settlement", "reconciliation", "hạn mức KYC", "T+1".

Ngày thứ 4, thay vì hỏi lẻ tẻ 20 câu làm phiền cả team, Minh gom thành một buổi hỏi 30 phút với mentor, mang theo danh sách 15 câu đã tự tìm hiểu trước. Mentor rất ấn tượng vì thấy Minh "đã tự tìm được 60% câu trả lời, chỉ hỏi phần thực sự cần người trong cuộc".

Bài học: Chủ động học context + gom câu hỏi thành cụm có chuẩn bị = thể hiện năng lực tự học, thứ nhà tuyển dụng đánh giá cao nhất ở fresher. File onboarding note của Minh sau này được team dùng làm tài liệu chào đón người mới.

Tình huống 2 — Hương, fresher BA tại một công ty e-commerce (đội outsourcing ~40 người)

Hương thông minh nhưng nóng vội. Ngay tuần 2, trong buổi refinement, cô phát biểu: "Em thấy flow checkout của mình rắc rối quá, sao không gộp bước xác nhận địa chỉ và thanh toán lại?" Cả phòng im lặng vài giây. Dev lead giải thích: flow đó tách ra vì yêu cầu tuân thủ của đối tác cổng thanh toán, đã tranh luận ba tháng trước.

Hương đỏ mặt. Không phải ý tưởng của cô sai hoàn toàn, mà là cô phát biểu khi chưa có đủ context lịch sử. Từ đó, team mặc định "góp ý của Hương chưa chắc chắn", và cô mất khá nhiều thời gian mới lấy lại niềm tin.

Bài học: Trong 30 ngày đầu, hãy đặt câu hỏi "Tại sao mình lại làm thế này ạ?" thay vì tuyên bố "Nên làm khác đi." Sự tò mò được hoan nghênh; phán xét sớm thì không. Ghi lại các ý tưởng cải tiến vào note riêng, đợi qua tháng đầu, khi đã đủ context, hãy đề xuất một cách có căn cứ.

Tình huống 3 — Tuấn, fresher BA gặp sự cố "môi trường" ngày đầu tiên

Tuấn đi làm ngày đầu và... không làm được gì. Chưa có account Jira, VPN chưa cấp, Confluence bị giới hạn quyền, laptop chưa cài được tool. Cậu ngồi im cả ngày vì ngại làm phiền IT, tự nhủ "chắc mai họ setup". Đến ngày thứ 3 vẫn chưa xong, và lúc này sếp mới phát hiện Tuấn "mất tích" hai ngày.

Bài học: Setup môi trường là việc của bạn, không phải việc chờ người khác lo hộ. Ngay ngày đầu, hãy lập một checklist tài khoản (Jira, Confluence, Slack/Teams, GitHub/GitLab, VPN, email, các hệ thống nghiệp vụ) và chủ động đi từng đầu mối để được cấp quyền. "Chủ động gỡ blocker cho chính mình" là kỹ năng BA cốt lõi — nếu ngay việc của bản thân bạn còn không unblock được thì sao unblock được cho dự án?

Hướng dẫn từng bước

Tuần 1 — Quan sát & học context

Checklist:

  • [ ] Setup môi trường đầy đủ: laptop, account Jira, Confluence, Slack/Teams, GitHub/GitLab, VPN, email công ty, và quyền truy cập các hệ thống nghiệp vụ. Chủ động đi hỏi IT/mentor, đừng chờ.
  • [ ] Đọc 5 SRS/BRD và 10 user story cũ đã release để hiểu văn phong tài liệu và mức độ chi tiết mà team kỳ vọng.
  • [ ] Vẽ Product map: liệt kê các module chính và core flow của sản phẩm vào một sơ đồ đơn giản.
  • [ ] Lập People map: ghi rõ vai trò từng người bạn sẽ làm việc cùng (PO, PM, dev lead, QA lead, mentor).
  • [ ] Tạo file "Onboarding Notes" trên Confluence/Notion, ghi lại mọi thuật ngữ, viết tắt, quy trình bạn học được.
  • [ ] Xin lịch 1:1 với mentor để chốt kỳ vọng: 30/60/90 ngày mình cần đạt gì?
  • [ ] Tham dự các buổi họp với vai trò quan sát: daily standup, refinement, sprint review — nghe nhiều, nói ít.

Tuần 2 — Bắt đầu đóng góp việc nhỏ

  • [ ] Nhận 1–2 task nhỏ có kiểm soát: cập nhật một tài liệu cũ, chuẩn hóa vài acceptance criteria, ghi biên bản họp (meeting minutes).
  • [ ] Ghi meeting minutes cho một buổi refinement — đây là cách tuyệt vời để vừa học vừa tạo giá trị ngay.
  • [ ] Gom câu hỏi thành cụm, hỏi mentor trong buổi 1:1 thay vì hỏi lắt nhắt cả ngày.
  • [ ] Bắt đầu tìm hiểu domain sâu hơn: nếu là banking thì học nghiệp vụ ngân hàng, e-commerce thì học flow đơn hàng.
  • [ ] Chủ động cập nhật trạng thái công việc cho mentor cuối mỗi ngày/mỗi hai ngày, kể cả khi đang bị blocker.

Tuần 3–4 — Chạy độc lập một mảng nhỏ

  • [ ] Own một feature nhỏ từ đầu đến cuối: từ làm rõ requirement → viết user story + acceptance criteria → làm việc với dev/QA.
  • [ ] Tự làm rõ (clarify) requirement với stakeholder cho phần bạn phụ trách, có mentor "đứng sau" hỗ trợ.
  • [ ] Tham gia UAT/kiểm thử cho feature bạn phụ trách để hiểu vòng đời từ requirement đến sản phẩm.
  • [ ] Hoàn thiện Onboarding Notes thành tài liệu có thể chia sẻ cho người vào sau.
  • [ ] Xin feedback giữa kỳ (day 30): hỏi thẳng mentor "Em đang làm tốt ở đâu, cần cải thiện gì?" và ghi lại để hành động.

Quy tắc giao tiếp xuyên suốt 30 ngày

  • Cập nhật chủ động (proactive update): đừng để sếp phải đi hỏi bạn đang làm gì.
  • Báo blocker sớm: kẹt gì báo ngay, đừng ngồi im tự vật lộn quá nửa ngày.
  • Xác nhận lại yêu cầu: khi được giao việc, nhắc lại bằng lời của bạn để chắc chắn hiểu đúng ("Vậy em hiểu là mình cần…, đúng không ạ?").

Lỗi thường gặp & mẹo

Lỗi 1 — Ngồi im chờ được giao việc. Fresher hay nghĩ "mình mới vào, chờ người ta training". Sai. Sự chủ động là thứ được đánh giá đầu tiên. Nếu chưa có task, hãy tự đọc tài liệu, tự vẽ product map, tự hỏi mentor có gì em phụ đỡ được không.

Lỗi 2 — Hỏi lắt nhắt cả ngày làm phiền team. Mỗi lần bạn ngắt lời một dev đang tập trung, họ mất trung bình 15–20 phút để quay lại nhịp làm việc. Mẹo: gom câu hỏi vào một file, tự Google/tự tìm trong tài liệu trước, rồi hỏi thành cụm trong buổi 1:1.

Lỗi 3 — Chê bai quy trình/tài liệu cũ khi chưa đủ context (như tình huống của Hương). Mẹo: dùng công thức "hỏi tại sao trước, đề xuất sau". Ghi ý tưởng cải tiến vào note, để dành sau ngày 30.

Lỗi 4 — Không ghi lại những gì học được. Đến tuần 3 bạn sẽ quên 70% thuật ngữ đã nghe ở tuần 1 nếu không ghi. Mẹo: tạo onboarding note ngay ngày đầu và cập nhật liên tục — nó vừa giúp bạn, vừa là "món quà" cho người vào sau và ghi điểm với sếp.

Lỗi 5 — Im lặng khi bị blocker. Ngồi im 3 ngày vì chưa có account (như Tuấn) là ác mộng. Mẹo: quy tắc "kẹt quá 2–4 tiếng thì báo". Báo blocker sớm là dấu hiệu của người chuyên nghiệp, không phải người yếu kém.

Mẹo vàng — Học tên và vai trò mọi người thật nhanh. Trong tuần đầu, việc nhớ đúng tên và biết ai làm gì tạo thiện cảm cực lớn. Hãy ghi lại một sơ đồ tổ chức nhỏ của riêng bạn.

Bài tập thực hành

  • Lập checklist môi trường của riêng bạn. Dựa trên công cụ mà công ty (tương lai) của bạn dùng, viết ra danh sách 8–10 tài khoản/quyền truy cập bạn cần được cấp trong ngày đầu, kèm tên người/bộ phận phụ trách cấp mỗi loại.
  • Thực hành vẽ Product map. Chọn một sản phẩm số bạn dùng hằng ngày (ví dụ MoMo, Shopee, Grab). Liệt kê 4–6 module chính và vẽ core flow chính bằng 5–7 bước. Đây chính là kỹ năng bạn sẽ dùng trong tuần 1 khi vào công ty thật.
  • Soạn danh sách 15 câu hỏi cho buổi 1:1 đầu tiên với mentor. Chia thành 3 nhóm: câu hỏi về sản phẩm, về quy trình team, và về kỳ vọng dành cho bạn ở mốc 30/60/90 ngày.
  • Viết một trang "Onboarding Note mẫu". Giả định bạn đã đi làm được 3 ngày, hãy tạo cấu trúc file gồm các mục: Thuật ngữ & viết tắt, Sơ đồ tổ chức, Các link quan trọng, Câu hỏi còn tồn đọng. Điền thử vài dòng ví dụ vào mỗi mục.
  • Tình huống xử lý blocker. Viết ra kịch bản: bạn được giao viết acceptance criteria cho một feature nhưng chưa được cấp quyền xem tài liệu gốc. Bạn sẽ nhắn tin cho mentor như thế nào để báo blocker một cách chuyên nghiệp (ngắn gọn, nêu rõ bạn đang kẹt gì, đã thử gì, cần gì)?

Tóm tắt

  • 30 ngày đầu không phải để chứng minh bạn giỏi phân tích, mà để xây niềm tin. Team đang trả lời câu hỏi: "Người này có đáng tin, có chủ động, có học nhanh không?"
  • Chia 30 ngày thành 3 giai đoạn: Tuần 1 quan sát và học context; Tuần 2 đóng góp việc nhỏ có kiểm soát; Tuần 3–4 own một mảng nhỏ độc lập dưới sự giám sát của mentor.
  • Xây ba tấm bản đồ tinh thần: Product map (sản phẩm & core flow), People map (ai làm gì, ai quyết cái gì), Tooling map (tài liệu và công cụ nằm ở đâu).
  • Deliverable thật của tháng đầu là một onboarding note giá trị, vài task nhỏ hoàn thành chỉn chu, và sự tin tưởng của team — không phải một tài liệu đồ sộ.
  • Tránh 5 lỗi kinh điển: ngồi im chờ việc, hỏi lắt nhắt, chê bai khi chưa đủ context, không ghi chép, và im lặng khi bị blocker.
  • Ba quy tắc giao tiếp sống còn: cập nhật chủ động, báo blocker sớm, luôn xác nhận lại yêu cầu bằng lời của mình.
Làm đúng những điều trên, đến ngày thứ 30 bạn sẽ không còn là "bạn fresher mới vào" mà đã là một mắt xích team tin tưởng — nền tảng vững chắc để bước vào giai đoạn 30→90 ngày trở thành BA độc lập.