Mở đầu — vì sao bài này quan trọng
Ở bài trước, bạn đã sống sót qua 30 ngày đầu — biết ai là ai, hiểu quy trình, không còn ngồi họp mà thấy như đang nghe ngoại ngữ. Nhưng "sống sót" và "được tin tưởng" là hai trạng thái hoàn toàn khác nhau. Nhiều BA fresher mắc kẹt ở ranh giới này rất lâu: họ đã hết bỡ ngỡ, nhưng vẫn phải chờ senior review từng câu chữ, vẫn không dám tự trả lời câu hỏi của Dev, vẫn được giao những task nhỏ lẻ thay vì một mảng công việc trọn vẹn. Họ trở thành "người phụ việc BA" chứ chưa phải "một BA".
Giai đoạn 30 → 90 ngày chính là cây cầu bắc qua ranh giới đó. Đây là lúc bạn chuyển từ thực thi có giám sát sang sở hữu có trách nhiệm. Cuối 90 ngày, mục tiêu không phải là "biết nhiều hơn" mà là một điều rất cụ thể và có thể đo được: bạn tự đứng ra chịu trách nhiệm cho một module — viết được 5-10 user story mỗi sprint mà PO không cần sửa lại toàn bộ, để cho Dev Lead và người dùng trực tiếp coi bạn là đầu mối đáng tin, và vượt qua kỳ đánh giá thử việc (probation) với một profile rõ ràng.
Bài này sẽ chỉ cho bạn con đường đi từ điểm A (một fresher đã hết bỡ ngỡ) đến điểm B (một BA độc lập trong phạm vi module của mình). Đây không phải chuyện học thêm framework — bạn đã có đủ kiến thức nền ở các bài trước. Đây là chuyện cách bạn định vị bản thân, chọn việc để nhận, và xây dựng lòng tin một cách có chủ đích.
Khái niệm cốt lõi
"Độc lập" nghĩa là gì với một BA junior
Độc lập ở đây không có nghĩa là làm một mình không cần ai. Ngược lại, BA giỏi luôn cực kỳ kết nối. "Độc lập" mang một nghĩa rất cụ thể trong ngữ cảnh nghề nghiệp:
- Độc lập trong phạm vi (scoped ownership): bạn được giao trọn một module — ví dụ module "Quản lý voucher" hay "Đăng ký tài khoản" — và bạn là người hiểu nó rõ nhất trong team.
- Độc lập trong luồng công việc: bạn tự đi từ câu hỏi mơ hồ của stakeholder → làm rõ → viết requirement → làm việc với Dev/QC → nghiệm thu, mà không cần senior cầm tay ở mỗi bước.
- Độc lập trong việc ra quyết định nhỏ: khi Dev hỏi "chỗ này xử lý sao?", bạn tự trả lời được những quyết định trong tầm, và biết khi nào phải leo thang (escalate) lên PO.
Mô hình "vòng tròn tin tưởng" (trust radius)
Hãy hình dung sự tin tưởng như một vòng tròn quanh bạn, mở rộng dần theo thời gian:
- Tuần 1-4: vòng tròn rất nhỏ. Senior BA hoặc PO tin bạn làm được những task rời rạc — cập nhật một mô tả, ghi biên bản họp, rà soát một checklist.
- Tuần 5-8: vòng tròn lớn lên. Bạn được giao một feature nhỏ đầu-cuối. Dev bắt đầu hỏi thẳng bạn thay vì hỏi senior.
- Tuần 9-12: vòng tròn đủ lớn để bao trọn một module. PO giao mục tiêu chứ không giao từng bước; bạn tự chia thành story và chạy.
Ba trụ cột của sự tin tưởng
Để mở rộng trust radius, bạn cần đầu tư vào ba thứ mà stakeholder ngầm đánh giá bạn:
- Reliability (đáng tin về mặt cam kết): nói làm gì thì làm nấy, đúng hạn, hoặc báo trước nếu trễ. Đây là trụ cột quan trọng nhất với fresher — nó bù đắp cho việc bạn còn thiếu kinh nghiệm.
- Domain fluency (thông thạo nghiệp vụ module của mình): bạn trả lời được câu hỏi nghiệp vụ về module mà không cần đi hỏi lại người khác.
- Judgment (phán đoán): biết cái gì tự quyết, cái gì phải hỏi, cái gì phải escalate. Fresher hay sai ở đây — hoặc tự quyết những thứ không nên, hoặc hỏi những thứ lẽ ra tự trả lời được.
Tình huống thực tế
Ví dụ 1 — Linh tại một công ty fintech ở TP.HCM: chọn đúng "module để sở hữu"
Linh, 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 ví điện tử với khoảng 40 kỹ sư. Hết 30 ngày, Linh vẫn được giao những task lặt vặt trải khắp nhiều feature: hôm nay sửa một acceptance criteria cho tính năng nạp tiền, mai ghi biên bản cho tính năng lịch sử giao dịch. Cô thấy mình bận rộn nhưng không "sở hữu" gì cả, và trong buổi 1-1 tuần thứ 6, PO nói thẳng: "Anh chưa biết giao hẳn cho em cái gì."
Bước ngoặt đến khi Linh chủ động đề xuất: "Em xin nhận trọn module Quản lý hạn mức giao dịch. Em sẽ là người nắm mọi business rule về hạn mức." Đây là một module vừa đủ nhỏ để một fresher ôm nổi (khoảng 8 rule chính, không đụng tới phần thanh toán phức tạp nhất), nhưng vừa đủ quan trọng để có ý nghĩa. Trong bốn tuần sau đó, Linh làm một việc mà senior không có thời gian làm: cô ngồi gom toàn bộ business rule về hạn mức đang nằm rải rác trong 5 tài liệu cũ và trong đầu 2 người, dựng thành một business rule catalog gọn gàng với 8 story cho sprint kế tiếp.
Bài học: độc lập bắt đầu từ việc chọn đúng một mảnh để sở hữu — đủ nhỏ để ôm nổi, đủ rõ ràng để thành "của bạn", và tốt nhất là mảnh mà hiện chưa ai nắm gọn. Đừng chờ được giao; hãy đề xuất. Việc dựng catalog vừa tạo giá trị thật, vừa là cách Linh nạp "domain fluency" nhanh nhất.
Ví dụ 2 — Đức tại một công ty phần mềm outsourcing ở Đà Nẵng: giành lòng tin của Dev Lead
Đức làm BA cho một dự án gia công cho khách hàng Nhật, đội có một Dev Lead khá khó tính tên Tuấn. Trong 30 ngày đầu, mỗi user story Đức viết đều bị Tuấn "bắn" ngược lại kèm bình luận: "Case tài khoản bị khóa xử lý sao?", "Nếu số tiền âm thì sao?". Đức thấy nản, cảm giác như Dev đang bắt bẻ mình.
Thay vì phòng thủ, Đức đổi cách tiếp cận: cậu lập một danh sách "các câu hỏi Tuấn hay hỏi" và biến chúng thành checklist tự rà trước khi giao story — luôn nghĩ trước về luồng lỗi (error flow), giá trị biên (edge case), và trạng thái ngoại lệ. Đến sprint thứ ba, tỷ lệ story bị trả về của Đức giảm hẳn. Trong một buổi refinement, Tuấn hỏi cả team một tình huống nghiệp vụ, rồi tự quay sang nói: "Hỏi Đức đi, phần này Đức nắm." Đó là khoảnh khắc trust radius của Đức mở rộng — Dev Lead đã công khai xác nhận cậu là đầu mối.
Bài học: phản hồi gắt của Dev không phải là công kích, mà là bản đồ chỉ cho bạn những lỗ hổng trong tư duy requirement. Biến phản hồi lặp lại thành checklist cá nhân là cách nhanh nhất để nâng chất lượng đầu ra và giành lòng tin của đội kỹ thuật. Lòng tin của Dev Lead có sức nặng đặc biệt, vì họ là người "tiêu thụ" trực tiếp sản phẩm của bạn.
Ví dụ 3 — Mai và cái bẫy "im lặng khi trễ hạn"
Mai, BA fresher tại một startup logistics ở Hà Nội, nhận làm rõ requirement cho một tính năng tính phí ship. Cô hẹn PO là thứ Sáu sẽ có tài liệu. Đến thứ Năm, cô nhận ra business rule phức tạp hơn dự tính vì có nhiều vùng giá khác nhau, và cô sẽ không kịp. Vì sợ bị đánh giá, Mai im lặng, cố cày và nộp một tài liệu vội vàng vào tối thứ Sáu — thiếu sót, khiến sprint planning thứ Hai bị rối.
Nếu quay lại, điều đúng đắn đơn giản hơn nhiều: chiều thứ Năm nhắn PO một tin — "Em phát hiện phần vùng giá phức tạp hơn dự tính, em cần thêm nửa ngày để làm cho chuẩn, thứ Hai đầu giờ em gửi được không ạ?". Chín trên mười trường hợp, PO sẽ đồng ý và tăng lòng tin, vì bạn thể hiện sự chủ động và trung thực về tiến độ.
Bài học: với fresher, cách bạn xử lý một lời hứa có nguy cơ trễ ảnh hưởng đến lòng tin nhiều hơn cả bản thân việc trễ. Báo sớm, đề xuất phương án, giữ cam kết mới. Reliability được xây bằng chính những khoảnh khắc khó này.
Hướng dẫn từng bước
Đây là lộ trình cụ thể để đi từ ngày 30 đến ngày 90.
Ngày 30-45 — Chọn và cắm cờ trên một module.
- Trong buổi 1-1 với sếp/PO, đề xuất nhận trọn một module cụ thể. Chọn cái đủ nhỏ (5-10 story/sprint là vừa) và tốt nhất là cái đang thiếu người nắm.
- Làm một "deep dive": đọc mọi tài liệu cũ liên quan, phỏng vấn 1-2 người đang giữ kiến thức trong đầu, và tổng hợp lại thành một artefact có giá trị (business rule catalog, process flow, hoặc bảng thuật ngữ của module).
- Kết quả cần đạt: bạn trả lời được 80% câu hỏi nghiệp vụ về module này mà không phải đi hỏi.
- Nhận một feature nhỏ trong module và tự đi trọn quy trình: elicit → viết story + acceptance criteria → mang ra refinement → hỗ trợ Dev/QC → nghiệm thu.
- Trước khi giao story, chạy qua checklist tự rà: happy path, error flow, edge case, business rule, và trạng thái ngoại lệ.
- Xin senior review sau khi bạn đã tự hoàn thiện, không phải để họ viết hộ. Ghi lại mọi phản hồi lặp lại thành checklist cá nhân.
- Chủ động trở thành đầu mối: khi có câu hỏi về module của mình, hãy là người trả lời trong nhóm chat/họp thay vì đùn cho senior.
- Xây quan hệ trực tiếp với các stakeholder chính của module: PO, Dev Lead, và 1-2 người dùng (user) thực tế. Đặt lịch cà phê 15 phút với người dùng để hiểu họ dùng tính năng ra sao.
- Bắt đầu tự quyết những quyết định nhỏ trong tầm, và ghi log lại (mình đã quyết gì, dựa trên đâu) để có thể giải trình.
- Chủ động xin một buổi review giữa kỳ với sếp: "Em muốn biết em đang ở đâu so với kỳ vọng, và cần cải thiện gì trước khi hết thử việc."
- Chuẩn bị một "proof pack" ngắn: danh sách story bạn đã sở hữu, module bạn đang giữ, phản hồi tích cực từ Dev/PO/user, và những vấn đề bạn đã tự xử lý.
- Đặt mục tiêu rõ cho quý tiếp theo để thể hiện bạn có tư duy đường dài, không chỉ hoàn thành task.
Lỗi thường gặp & mẹo
Lỗi 1 — Ôm quá nhiều mảnh, không sở hữu mảnh nào. Fresher hay nhận việc rải rác vì sợ từ chối. Kết quả là bận rộn nhưng không ai coi bạn là "người của" bất kỳ module nào. Mẹo: xin một mảnh làm "của mình" và làm nó thật sâu; sự sâu tạo ra lòng tin, sự dàn trải thì không.
Lỗi 2 — Nhầm "độc lập" với "không hỏi ai". Có bạn cố tỏ ra giỏi bằng cách không bao giờ hỏi, dẫn đến tự quyết sai những thứ đáng lẽ phải escalate. Mẹo: độc lập là biết phân loại quyết định — tự quyết cái trong tầm, hỏi cái mơ hồ, escalate cái có rủi ro tiền bạc/pháp lý/kiến trúc.
Lỗi 3 — Xin senior review quá sớm. Nếu bạn đưa bản nháp thô để senior sửa, bạn đang huấn luyện họ tiếp tục làm hộ mình. Mẹo: luôn tự hoàn thiện đến mức tốt nhất có thể trước khi xin review; hãy để review là để "bắt lỗi tinh", không phải để "viết lại".
Lỗi 4 — Im lặng khi gặp khó hoặc trễ hạn. Như tình huống của Mai, im lặng phá hủy reliability. Mẹo: báo sớm luôn tốt hơn báo muộn; kèm theo phương án đề xuất, đừng chỉ báo vấn đề.
Lỗi 5 — Bỏ quên người dùng thật. Fresher hay chỉ nói chuyện với PO và Dev, quên mất user cuối. Mẹo: xây quan hệ trực tiếp với ít nhất 2 user của module — họ cho bạn hiểu biết nghiệp vụ mà không tài liệu nào có, và lòng tin của họ rất giá trị khi nghiệm thu.
Mẹo tăng tốc: giữ một "nhật ký quyết định" (decision log) đơn giản trong Notion hoặc Confluence — ghi lại mỗi quyết định nghiệp vụ bạn đưa ra và lý do. Nó vừa giúp bạn giải trình, vừa là bằng chứng cụ thể cho thấy bạn đang tư duy như một BA thật khi đến kỳ đánh giá probation.
Bài tập thực hành
- Chọn module. Liệt kê tất cả feature/module trong dự án hiện tại (hoặc mock project của bạn). Chọn một module đủ nhỏ (5-10 story) mà bạn muốn và có thể sở hữu. Viết một câu đề xuất bạn sẽ nói với PO để xin nhận nó.
- Dựng artefact giá trị. Với module đã chọn, tạo một trong ba thứ sau: business rule catalog, process flow, hoặc bảng thuật ngữ. Mục tiêu là sau khi làm xong, bạn trả lời được phần lớn câu hỏi nghiệp vụ về module đó.
- Checklist tự rà. Viết checklist cá nhân gồm ít nhất 6 mục bạn sẽ kiểm tra trước khi giao mỗi user story (gợi ý: happy path, error flow, edge case, business rule, quyền hạn, trạng thái ngoại lệ).
- Ma trận quyết định. Kẻ một bảng ba cột: "Tự quyết", "Hỏi PO", "Escalate". Điền vào mỗi cột ít nhất 3 loại tình huống thực tế trong module của bạn. Đây là công cụ rèn judgment.
- Proof pack. Giả định hôm nay là ngày 85. Viết một trang tổng kết bạn sẽ trình bày ở buổi review probation: module bạn sở hữu, số story đã làm, phản hồi nhận được, và một vấn đề bạn đã tự xử lý.
Tóm tắt
Giai đoạn 30 → 90 ngày là lúc bạn chuyển từ "người phụ việc BA" thành "một BA thực thụ trong phạm vi của mình". Đích đến cuối 90 ngày rất cụ thể và đo được: sở hữu trọn một module với 5-10 story mỗi sprint, được PO, Dev Lead và người dùng trực tiếp tin tưởng như một đầu mối đáng tin, và vượt qua probation với hồ sơ rõ ràng.
Con đường đi qua ba việc cốt lõi. Thứ nhất, chọn đúng một mảnh để sở hữu — đủ nhỏ để ôm nổi, và làm nó thật sâu để có domain fluency. Thứ hai, tự chạy trọn luồng đầu-cuối và biến mọi phản hồi lặp lại thành checklist để chất lượng đầu ra tăng dần. Thứ ba, chủ động mở rộng vòng tròn tin tưởng qua ba trụ cột reliability, domain fluency và judgment — luôn giữ cam kết, báo sớm khi có nguy cơ trễ, và biết phân loại quyết định nào tự làm, hỏi, hay escalate.
Như Linh, Đức và Mai đã cho thấy: độc lập không phải là thứ được ban cho, mà là thứ bạn giành lấy bằng cách chủ động nhận trách nhiệm và không bao giờ để một quả bóng rơi. Làm được những điều này trong 60 ngày, bạn sẽ không chỉ qua thử việc — bạn sẽ bước vào giai đoạn tiếp theo với vị thế của một BA đã được tin tưởng.