Mở đầu — vì sao bài này quan trọng
Bạn vừa nhận offer, ký hợp đồng, và trong đó có một dòng nhỏ mà nhiều bạn fresher đọc lướt qua: "thời gian thử việc 2 tháng" hoặc "60 ngày", có nơi ghi thẳng "probation 3 tháng". Đây không phải thủ tục hành chính vô hại. Đây là khoảng thời gian công ty quyết định họ có giữ bạn hay không, và luật lao động Việt Nam cho phép chấm dứt thử việc mà gần như không cần lý do phức tạp. Với vị trí đòi hỏi chuyên môn như BA, thời gian thử việc theo luật tối đa là 60 ngày; nhiều công ty gộp thêm giai đoạn đánh giá thành mốc 90 ngày quen thuộc trong ngành.
Điều đáng buồn là phần lớn fresher BA bị đánh giá "chưa đạt" không phải vì họ kém thông minh, mà vì họ trôi qua 90 ngày một cách bị động: chờ được giao việc, chờ được chỉ dẫn, chờ ai đó nói cho biết mình nên làm gì. Trong khi đó, người quản lý lại kỳ vọng bạn tự tạo ra tiến trình. Khoảng cách kỳ vọng này chính là nơi nhiều sự nghiệp BA chết yểu ngay tháng đầu tiên.
Bài này cho bạn một thứ cụ thể: một template onboarding 90 ngày mà bạn có thể tự cầm lấy và chạy, ngay cả khi công ty không có quy trình onboarding tử tế. Nó biến 90 ngày mơ hồ thành ba giai đoạn có mục tiêu rõ ràng — Learn, Contribute, Own — với việc cần làm, bằng chứng cần thu thập, và cột mốc để tự kiểm tra. Đây là công cụ để bạn chủ động chứng minh giá trị, thay vì cầu nguyện được đánh giá tốt.
Khái niệm cốt lõi
90 ngày và ba giai đoạn
Con số 90 ngày không phải ngẫu nhiên. Nó đủ dài để bạn hiểu domain và hệ thống, nhưng đủ ngắn để tạo áp lực chứng minh. Michael Watkins trong cuốn The First 90 Days gọi đây là giai đoạn "đạt điểm hòa vốn" — thời điểm giá trị bạn tạo ra bắt đầu vượt qua chi phí công ty bỏ ra để onboard bạn. Với một BA fresher, điểm hòa vốn thường rơi vào khoảng ngày thứ 60 đến 75.
Ta chia 90 ngày thành ba giai đoạn 30 ngày, mỗi giai đoạn có một động từ chủ đạo:
- Day 1–30 — Learn (Học và quan sát): Mục tiêu không phải là làm được nhiều, mà là hiểu đúng. Bạn hấp thụ domain nghiệp vụ, làm quen hệ thống, nắm được ai là ai, và học cách team vận hành. Sai lầm ở giai đoạn này là cố tỏ ra giỏi quá sớm.
- Day 31–60 — Contribute (Đóng góp có giám sát): Bạn bắt đầu tạo ra deliverable thật — user story, biên bản họp, phân tích nhỏ — nhưng vẫn có người review trước khi ra ngoài. Mục tiêu là chứng minh bạn tạo được giá trị mà không gây rủi ro.
- Day 61–90 — Own (Sở hữu và tự chủ): Bạn nhận trọn một phần việc — một feature nhỏ, một module — từ elicitation đến bàn giao cho dev, với sự tin tưởng rằng bạn tự xoay xở được. Đây là bằng chứng cuối cùng để công ty ký hợp đồng chính thức.
Nguyên tắc xuyên suốt: thu thập bằng chứng
Điểm mà fresher hay bỏ lỡ: đến ngày review, người quản lý phải trả lời câu hỏi "bạn này đã đóng góp gì?". Nếu bạn không chuẩn bị, họ sẽ trả lời bằng cảm tính. Vì vậy, xuyên suốt 90 ngày, bạn duy trì một cuốn "brag document" (tài liệu ghi thành tích) — một file đơn giản ghi lại: ngày, việc đã làm, kết quả cụ thể, ai xác nhận. Đến buổi đánh giá cuối, bạn không nói "em thấy em làm cũng ổn", mà mở file ra và cho họ thấy 15 mục có số liệu.
Tình huống thực tế
Tình huống 1: Bạn Minh — người "chờ được giao việc"
Minh, tốt nghiệp ngành Hệ thống thông tin, vào làm BA fresher tại một công ty fintech quy mô 120 người ở TP.HCM, làm về ví điện tử. Tuần đầu tiên anh manager bận sprint release nên chỉ nói "em cứ đọc tài liệu, có gì hỏi". Minh đọc, rồi hết tài liệu thì... ngồi chờ. Ba tuần trôi qua, Minh chưa mở miệng hỏi ai câu nào vì sợ làm phiền, chưa tạo ra bất kỳ output nào.
Đến buổi review ngày 30, manager hỏi "em nắm được flow nạp tiền qua ngân hàng liên kết chưa?". Minh ú ớ vì chỉ đọc lý thuyết, chưa từng đi qua flow thật hay hỏi ai. Đánh giá tháng đầu của Minh là "thụ động, chưa chủ động học".
Bài học: Learn không có nghĩa là ngồi đọc thụ động. Learn nghĩa là chủ động đặt lịch 1-1 với dev, tester, BA senior để đi qua từng flow; nghĩa là ghi lại câu hỏi và mang đi hỏi có hệ thống. Nếu Minh dùng template, ngày thứ 5 anh đã có danh sách "10 người cần gặp" và một checklist "5 flow cốt lõi phải hiểu", thay vì trôi ba tuần trong im lặng.
Tình huống 2: Bạn Hân — chứng minh giá trị bằng deliverable nhỏ
Hân vào làm BA tại một công ty gia công phần mềm (outsourcing) ở Đà Nẵng, dự án cho khách Nhật về quản lý kho. Từ tuần 5, thay vì chờ manager giao user story lớn, Hân xin nhận viết acceptance criteria cho 3 story nhỏ mà BA senior đang quá tải. Cô viết, nhờ senior review, sửa theo góp ý, rồi lần sau viết tốt hơn. Đến tuần 8, senior bắt đầu tin tưởng giao thẳng story cho Hân mà chỉ review nhẹ.
Quan trọng hơn, Hân ghi lại tất cả vào brag document: "Tuần 6: viết AC cho story US-214, US-215, US-216; senior chỉ sửa 2 điểm về edge case; sprint đó không có defect nào liên quan đến requirement mập mờ." Đến review ngày 60, cô có bằng chứng định lượng.
Bài học: Giai đoạn Contribute không cần bạn làm việc lớn. Nó cần bạn tạo ra những mảnh việc nhỏ, có review, và tích lũy uy tín từng chút. Uy tín trong 90 ngày được xây bằng chuỗi việc nhỏ hoàn thành tốt, không phải bằng một việc lớn hoành tráng.
Tình huống 3: Bạn Tú — "own" một feature và cú vấp cần thiết
Tú làm BA fresher tại một startup logistics ở Hà Nội. Đến ngày thứ 65, manager giao Tú "sở hữu" feature tính phí ship theo vùng — từ họp với bộ phận vận hành để lấy business rule, viết tài liệu, đến làm việc với dev. Tú tự tin nhận. Nhưng đến khi dev bắt đầu code, họ phát hiện Tú bỏ sót quy tắc phụ phí cho khu vực nội thành giờ cao điểm, vì Tú chỉ họp với một người bên vận hành thay vì cả nhóm.
Tú thừa nhận thiếu sót ngay, tổ chức lại buổi họp bổ sung, cập nhật business rule catalog, và ghi lại bài học vào brag document phần "lesson learned". Điều thú vị: manager đánh giá cao chính cách Tú xử lý sự cố hơn là trách anh vì sai. Kết quả review 90 ngày của Tú là "đạt, có tiềm năng lên mid trong 12 tháng".
Bài học: Giai đoạn Own không đòi hỏi bạn hoàn hảo. Nó đòi hỏi bạn dám nhận trách nhiệm trọn vẹn và xử lý sự cố một cách chuyên nghiệp. Một fresher biết nhận lỗi, sửa nhanh, và rút ra bài học được đánh giá cao hơn một fresher không dám nhận việc lớn vì sợ sai.
Hướng dẫn từng bước
Dưới đây là template bạn có thể sao chép vào Notion hoặc Google Docs và điền dần.
Trước ngày đầu tiên (Day 0)
- Chuẩn bị 3 câu hỏi cho buổi gặp manager đầu tiên: "Sau 90 ngày, một BA thành công trong mắt anh/chị trông như thế nào?", "3 tài liệu/hệ thống em nên đọc trước là gì?", "Em nên gặp những ai trong 2 tuần đầu?".
- Tạo sẵn file brag document với 4 cột: Ngày | Việc làm | Kết quả | Người xác nhận.
Day 1–30 — Learn
- Tuần 1: Lập "stakeholder map cá nhân" — liệt kê 8–12 người bạn cần biết (manager, BA senior, dev lead, QA lead, PO, một vài người phía nghiệp vụ). Đặt lịch 1-1 mỗi người 20–30 phút.
- Tuần 1–2: Viết ra "5 flow cốt lõi" của sản phẩm và tự giải thích được từng flow. Với ví điện tử, đó có thể là: đăng ký/KYC, nạp tiền, rút tiền, chuyển tiền, thanh toán hóa đơn.
- Tuần 2–3: Đọc và tóm tắt 3 tài liệu quan trọng nhất (BRD/SRS của module bạn sẽ làm, business rule catalog, glossary thuật ngữ domain). Tự tạo một trang glossary riêng cho mình.
- Tuần 3–4: Ngồi cạnh (shadow) một BA senior qua ít nhất 2 buổi họp elicitation và 1 buổi refinement. Ghi lại cách họ đặt câu hỏi.
- Cột mốc ngày 30: Bạn giải thích được 5 flow cốt lõi, biết ai phụ trách việc gì, và có danh sách 20+ thuật ngữ domain. Đặt buổi check-in với manager để hỏi "em đang đi đúng hướng chưa?".
Day 31–60 — Contribute
- Tuần 5–6: Nhận 2–3 deliverable nhỏ có người review: viết acceptance criteria cho story có sẵn, làm biên bản họp, cập nhật một phần tài liệu.
- Tuần 6–7: Chủ động tham gia refinement — đặt ít nhất một câu hỏi làm rõ requirement mỗi buổi. Đây là cách rẻ nhất để chứng minh bạn tư duy phản biện.
- Tuần 7–8: Nhận viết trọn một user story từ đầu (mô tả, AC, business rule liên quan), nhờ review, sửa, và đưa vào sprint.
- Suốt giai đoạn: Mỗi việc hoàn thành ghi ngay vào brag document với số liệu ("giảm số câu hỏi qua lại với dev", "story không có defect về requirement").
- Cột mốc ngày 60: Bạn đã tạo ra ít nhất 5 deliverable được chấp nhận, và có ít nhất một việc mà senior "giao rồi yên tâm không cần review kỹ".
Day 61–90 — Own
- Tuần 9–10: Xin nhận "sở hữu" một feature/module nhỏ. Tự lên kế hoạch: cần họp ai, cần tài liệu gì, timeline ra sao.
- Tuần 10–11: Chạy elicitation với đúng nhóm stakeholder (không sót người), viết tài liệu, làm việc trực tiếp với dev và QA.
- Tuần 11–12: Hỗ trợ đến khâu test/UAT của phần mình sở hữu. Nếu có sự cố, xử lý và ghi lại lesson learned.
- Tuần 12: Chuẩn bị buổi review 90 ngày. Mở brag document, tổng hợp thành 1 trang: bạn đã học gì, đóng góp gì (có số liệu), sở hữu gì, và định hướng 90 ngày tiếp theo bạn muốn gì.
- Cột mốc ngày 90: Bạn đã bàn giao trọn vẹn ít nhất một phần việc và trình bày được giá trị bằng bằng chứng cụ thể.
Lỗi thường gặp & mẹo
- Cố tỏ ra giỏi trong tháng đầu. Nhiều fresher lao vào phản biện, đề xuất thay đổi quy trình khi chưa hiểu context. Điều này gây khó chịu. Tháng đầu là để học và hỏi, không phải để chứng tỏ. Mẹo: giữ một file riêng ghi "những thứ tôi thấy lạ" — đừng nói ra ngay, để đến khi đủ hiểu context mới nêu.
- Sợ hỏi vì sợ làm phiền. Đây là lỗi giết chết giai đoạn Learn. Mẹo: gom câu hỏi thành từng cụm 3–5 câu, hỏi một lần trong buổi 1-1 đã hẹn trước, thay vì hỏi lẻ tẻ cả ngày. Người ta khó chịu với sự ngắt quãng, không phải với câu hỏi.
- Không thu thập bằng chứng. Đến review mới cố nhớ lại mình đã làm gì thì đã muộn. Mẹo: dành 5 phút cuối mỗi ngày thứ Sáu cập nhật brag document.
- Không hỏi kỳ vọng ngay từ đầu. Nếu bạn không biết "thành công sau 90 ngày trông như thế nào", bạn đang bắn tên trong bóng tối. Mẹo: hỏi thẳng manager trong tuần đầu và ghi lại câu trả lời làm kim chỉ nam.
- Nhận việc "own" quá sớm hoặc quá muộn. Nhận quá sớm (tuần 3) khi chưa đủ context dễ vỡ; đợi đến tuần cuối mới nhận thì không kịp chứng minh. Mẹo: nhắm mốc ngày 60–65 để bắt đầu xin sở hữu.
- Bỏ qua các mối quan hệ ngoài team dev. BA sống bằng quan hệ với phía nghiệp vụ. Mẹo: trong stakeholder map cá nhân, luôn có ít nhất 2–3 người phía business, không chỉ toàn IT.
Bài tập thực hành
- Dựng template của riêng bạn. Tạo một trang Notion/Google Docs với ba mục Learn/Contribute/Own, mỗi mục điền sẵn 5 việc cụ thể ứng với công ty/dự án bạn đang (hoặc sắp) làm. Nếu chưa đi làm, hãy giả định một công ty domain cụ thể (fintech, e-commerce, logistics) và điền theo domain đó.
- Soạn 3 câu hỏi cho manager. Viết ra 3 câu hỏi bạn sẽ hỏi trong buổi gặp đầu tiên, trong đó bắt buộc có câu về định nghĩa "thành công sau 90 ngày".
- Lập stakeholder map cá nhân mẫu. Với domain bạn chọn ở bài 1, liệt kê 10 vai trò bạn cần gặp và ghi rõ mỗi người bạn muốn học được gì từ họ.
- Viết trước một mục brag document giả định. Tưởng tượng bạn vừa hoàn thành một user story trong tuần 6. Viết một dòng brag document đầy đủ 4 cột (Ngày | Việc làm | Kết quả | Người xác nhận) với số liệu cụ thể. Mục tiêu là tập thói quen mô tả kết quả bằng bằng chứng, không bằng cảm tính.
Tóm tắt
90 ngày thử việc là kỳ thi quan trọng nhất trong năm đầu làm BA, và bạn hoàn toàn có thể chủ động điều khiển nó thay vì phó mặc. Template chia thành ba giai đoạn với động từ rõ ràng: Learn (day 1–30) để hiểu domain, hệ thống và con người thông qua việc chủ động gặp gỡ và đặt câu hỏi có hệ thống; Contribute (day 31–60) để tạo ra chuỗi deliverable nhỏ có review, xây uy tín từng bước; và Own (day 61–90) để nhận trọn một phần việc và chứng minh bạn tự chủ được.
Ba câu chuyện của Minh, Hân và Tú cho thấy một điều: fresher thất bại không phải vì kém, mà vì thụ động và không thu thập bằng chứng. Ngược lại, người thành công chủ động hỏi kỳ vọng ngay từ đầu, tạo giá trị bằng những việc nhỏ đều đặn, dám nhận trách nhiệm, và luôn có một brag document để đến buổi review nói chuyện bằng số liệu. Hãy cầm lấy template này, điền vào cho tình huống của riêng bạn, và biến 90 ngày mơ hồ thành 90 ngày có kế hoạch.