Mở đầu — vì sao bài này quan trọng
Ở Bài 39, bạn đã đi qua 30 ngày đầu tiên với tâm thế của một người mới: quan sát, học hỏi, xây dựng quan hệ và làm quen với hệ thống. Đó là giai đoạn bạn được phép "chưa biết". Nhưng bước sang tháng thứ hai và thứ ba — cửa sổ 60-90 ngày — kỳ vọng thay đổi hoàn toàn. Bạn không còn là "BA mới đang onboard" nữa. Bạn phải trở thành một BA độc lập: người có thể tự nhận một module, tự phân tích, tự viết requirement, tự chạy meeting với stakeholder, và tự chịu trách nhiệm cho đầu ra của mình mà không cần ai kèm cặp từng bước.
Đây chính là giai đoạn quyết định probation (thử việc). Rất nhiều bạn ex-CS làm rất tốt tháng đầu — chăm chỉ, dễ mến, hỏi han nhiệt tình — nhưng lại "khựng lại" ở tháng thứ hai vì không chuyển được từ trạng thái được giao việc sang trạng thái tự làm chủ việc. Manager nhìn vào và tự hỏi: "Bạn này dễ thương, nhưng liệu có tự đứng được không, hay mình vẫn phải cầm tay?"
Bài học này sẽ cho bạn một lộ trình rõ ràng để đi qua 60-90 ngày đó: mục tiêu cụ thể phải đạt, cách "own" một module đầu tiên, cách đo lường được sự tin tưởng của stakeholder, và cách bước vào buổi đánh giá probation với bằng chứng thay vì lời hứa. Với nền tảng CS của bạn, tin tốt là: bạn có sẵn nhiều lợi thế mà một BA fresh không có. Vấn đề chỉ là biết cách trưng chúng ra đúng lúc.
Khái niệm cốt lõi
"BA độc lập" nghĩa là gì?
Độc lập không có nghĩa là làm một mình hay không hỏi ai. Nó có nghĩa là bạn sở hữu vòng lặp hoàn chỉnh của một hạng mục công việc mà không cần người khác đẩy bạn qua từng bước:
- Bạn nhận một yêu cầu mơ hồ từ Product Owner (PO) và tự biết phải hỏi ai, hỏi gì để làm rõ.
- Bạn tự elicit (khai thác) requirement, tự viết user story và acceptance criteria (tiêu chí nghiệm thu) đủ chất lượng để dev không phải quay lại hỏi "ý bạn là sao?".
- Bạn tự chủ trì buổi refinement/grooming với team, tự bảo vệ được phân tích của mình khi bị chất vấn.
- Khi có vướng mắc, bạn không đợi ai gỡ hộ — bạn chủ động đề xuất 2-3 phương án và xin quyết định.
Ba trụ cột của mục tiêu 90 ngày
Từ ghi chú gốc, mục tiêu 90 ngày của bạn xoay quanh ba trụ cột. Hãy hiểu sâu từng cái:
Trụ cột 1 — Own được 1 module (5-10 story/sprint). Bạn cần được giao và tự xử lý trọn vẹn một mảng nghiệp vụ (module) trong sản phẩm. Ví dụ: module "quản lý hoàn tiền", module "thông báo cho khách hàng", hay module "self-service tra cứu đơn hàng". "Own" nghĩa là mọi story liên quan module đó đều đi qua tay bạn: bạn hiểu nghiệp vụ rõ nhất team, viết được 5-10 story chất lượng mỗi sprint, và là người dev/QA tìm đến khi có câu hỏi về module đó.
Trụ cột 2 — Chiếm được lòng tin của stakeholder chủ chốt. Cụ thể là ba nhóm: PO (người quyết định làm gì), Tech Lead (người quyết định làm thế nào), và ít nhất 2 người dùng thực tế/đại diện nghiệp vụ. Lòng tin không tự đến — nó được xây bằng chuỗi cam kết nhỏ được giữ đúng: bạn nói sẽ gửi spec thứ Tư thì thứ Tư có spec; bạn nói đã kiểm tra edge case thì đúng là đã kiểm tra.
Trụ cột 3 — Pass probation với điểm 95/100 (hoặc "đạt vượt kỳ vọng"). Đây là kết quả tất yếu nếu hai trụ cột trên vững. Nhưng bạn cần chủ động biến nỗ lực của mình thành bằng chứng có thể trình bày — một điều mà dân CS vốn quen làm việc "vô hình" thường quên.
Lợi thế ngầm của người ex-CS ở giai đoạn này
Ở tháng thứ 2-3, đây là lúc nền CS của bạn tỏa sáng nếu bạn biết khai thác:
- Bạn hiểu nỗi đau của người dùng cuối rõ hơn cả team. Khi dev tranh luận về một luồng nghiệp vụ, bạn là người duy nhất trong phòng từng nghe khách hàng gào thét về nó qua điện thoại. Đó là thẩm quyền (authority) không mua được.
- Bạn giỏi xử lý xung đột và giữ bình tĩnh. Meeting BA đôi khi căng thẳng khi stakeholder bất đồng. Kỹ năng de-escalate (làm dịu tình huống) từ CS giúp bạn điều tiết phòng họp mà một BA thuần kỹ thuật khó làm được.
- Bạn có bản năng đặt câu hỏi làm rõ. Cả đời CS bạn đã đào bới "khách hàng thực sự muốn gì đằng sau câu than phiền". Đó chính là kỹ năng elicitation cốt lõi của BA.
Tình huống thực tế
Tình huống 1 — Linh và module hoàn tiền tại một ví điện tử ở TP.HCM
Linh từng làm CS Team Lead 4 năm tại một công ty fintech, chuyển sang vị trí BA cùng công ty. Sang tuần thứ 6, PO giao cho cô "coi thử mảng refund (hoàn tiền), team đang có nhiều complaint". Đây là cơ hội own module đầu tiên của Linh.
Thay vì đợi PO viết story, Linh chủ động kéo dữ liệu từ hệ thống ticket cũ — nơi cô từng làm — và phát hiện 38% ticket refund đến từ việc khách không biết tiền hoàn về đâu và mất bao lâu. Cô viết một tài liệu ngắn 2 trang: bức tranh vấn đề, số liệu, và đề xuất chia thành 7 user story cho 2 sprint. Trong buổi refinement, khi Tech Lead hỏi "tại sao ưu tiên story hiển thị timeline hoàn tiền trước?", Linh trả lời bằng con số 38% và một câu chat khách hàng thật cô chụp lại. Không ai phản bác được.
Kết quả: đến ngày 75, Linh là người cả team hỏi mỗi khi đụng đến refund. PO ngừng review từng story của cô mà chỉ đọc lướt. Bài học: ex-CS có một mỏ vàng dữ liệu và insight mà người khác không có. Own module bằng cách biến insight đó thành bằng chứng định lượng, và bạn giành được authority rất nhanh.
Tình huống 2 — Tuấn và cú vấp "chưa cắt được dây rốn"
Tuấn chuyển từ CS sang BA tại một công ty logistics ở Hà Nội. Tháng đầu anh được khen hết lời. Nhưng đến tuần 8, manager bắt đầu lo. Vấn đề: mỗi khi viết xong một story, Tuấn đều nhắn manager "anh xem giúp em ổn chưa rồi em mới gửi dev". Mỗi quyết định nhỏ — nên gộp hay tách story, AC viết mấy dòng — anh đều hỏi. Manager cảm thấy như vẫn đang cầm tay một người thử việc, dù Tuấn thực ra viết khá tốt.
Trong buổi 1-1 giữa kỳ probation, manager nói thẳng: "Em viết ổn, nhưng anh cần một BA tự quyết được, không phải một người luôn xin xác nhận." Tuấn giật mình nhận ra thói quen "xin phép trước khi hành động" từ thời CS — nơi mọi ngoại lệ đều phải escalate lên cấp trên — đang kéo anh xuống. Anh đổi cách: tự quyết, rồi thông báo quyết định kèm lý do thay vì câu hỏi xin phép. Ví dụ, thay vì "em nên tách story này không anh?", anh viết "em tách story này thành 2 vì AC quá dài, dev estimate sẽ chính xác hơn — nếu anh thấy không hợp thì báo em." Đến ngày 90, đánh giá của anh nhảy từ "cần cải thiện" lên "đạt kỳ vọng".
Bài học: Phản xạ escalate mọi thứ là di sản nguy hiểm nhất của dân CS khi lên BA. Độc lập nghĩa là chuyển từ xin phép sang thông báo quyết định. Bạn vẫn để cửa cho manager can thiệp, nhưng mặc định bạn là người quyết.
Tình huống 3 — Mai xây lòng tin với Tech Lead khó tính
Mai (ex-CS, chuyển BA tại một startup SaaS ở Đà Nẵng) gặp một Tech Lead nổi tiếng khó, hay bác requirement với câu "cái này không khả thi về kỹ thuật". Ba tuần đầu Mai bị "dội" liên tục và bắt đầu mất tự tin. Thay vì né tránh, cô làm điều một CS giỏi hay làm: chủ động tìm hiểu góc nhìn của "khách hàng khó tính". Cô xin Tech Lead 20 phút cà phê, hỏi thẳng "anh cần requirement ở dạng nào để dễ đánh giá khả thi nhất?".
Hóa ra Tech Lead chỉ ghét những story không có phần "trường hợp lỗi" (error case) rõ ràng. Từ đó, mỗi story Mai viết đều có sẵn mục xử lý lỗi và các giả định kỹ thuật. Tech Lead từ chỗ hay bác chuyển sang chủ động comment góp ý — dấu hiệu của sự tin tưởng. Đến buổi review probation, chính Tech Lead là người vote cho Mai mạnh nhất.
Bài học: Lòng tin của stakeholder khó tính được xây bằng cách coi họ như một "khách hàng" cần thấu hiểu, không phải một rào cản cần vượt qua. Kỹ năng lắng nghe của CS chính là vũ khí ở đây.
Hướng dẫn từng bước
Đây là lộ trình cụ thể cho cửa sổ ngày 30 đến ngày 90:
Bước 1 (ngày 30-40) — Chủ động xin một module để own. Đừng đợi được giao. Nói với manager: "Em muốn nhận trọn một mảng để chịu trách nhiệm end-to-end. Anh/chị nghĩ mảng nào phù hợp?" Ưu tiên module gần với nền CS của bạn (hoàn tiền, thông báo, self-service, khiếu nại) vì bạn có lợi thế nghiệp vụ sẵn.
Bước 2 (ngày 40-50) — Xây "bản đồ nghiệp vụ" của module. Dành 1 tuần trở thành người hiểu module đó rõ nhất công ty: đọc dữ liệu ticket cũ, phỏng vấn 2 người dùng, vẽ luồng hiện tại, liệt kê pain point kèm số liệu. Đầu ra là một tài liệu ngắn bạn có thể trình bày trong 10 phút. Đây là nền tảng để bạn nói chuyện đầy tự tin.
Bước 3 (ngày 45-70) — Chạy vòng lặp story độc lập. Mỗi sprint tự viết 5-10 story cho module, tự chủ trì refinement, tự làm rõ với dev/QA. Mục tiêu định lượng: tỷ lệ story bị "trả lại" vì thiếu thông tin giảm dần qua từng sprint. Ghi lại con số này — nó là bằng chứng probation.
Bước 4 (xuyên suốt) — Chuyển từ "xin phép" sang "thông báo quyết định". Mỗi khi định hỏi manager một câu bắt đầu bằng "em nên... không anh?", dừng lại. Tự đưa ra quyết định kèm lý do, rồi thông báo và để ngỏ cửa phản hồi. Đây là chuyển dịch tư duy quan trọng nhất của giai đoạn này.
Bước 5 (ngày 60-75) — Chủ động lấy feedback giữa kỳ. Đừng đợi đến buổi probation mới biết mình đứng đâu. Xin manager một buổi 1-1 hỏi thẳng: "Nếu đánh giá em hôm nay là mấy điểm, và cần gì để lên mức tối đa?" Có 2-3 tuần để sửa còn hơn biết vào phút chót.
Bước 6 (ngày 80-90) — Chuẩn bị hồ sơ bằng chứng cho probation. Tổng hợp một trang: module bạn own, số story đã giao, giảm bao nhiêu % complaint/rework, quote khen từ dev/PO/user. Dân CS quen làm việc vô hình — đừng để nỗ lực của bạn bị lãng quên. Vào buổi đánh giá với bằng chứng, không phải cảm tính.
Lỗi thường gặp & mẹo
Lỗi 1 — Vẫn hành xử như CS: chờ được giao việc thay vì tự nhận. CS quen phản ứng theo ticket đến. BA phải chủ động đi tìm việc để own. Mẹo: mỗi đầu sprint, tự hỏi "mảng nào tôi có thể nhận thêm trách nhiệm?".
Lỗi 2 — Escalate mọi quyết định nhỏ. Như trường hợp Tuấn. Mẹo: áp dụng quy tắc "quyết trước, báo sau" cho mọi quyết định có thể đảo ngược. Chỉ hỏi trước với quyết định lớn, khó sửa.
Lỗi 3 — Ôm quá nhiều để "chứng tỏ". Nhiều ex-CS sợ bị đánh giá nên nhận thêm việc vô tội vạ, rồi làm mọi thứ hời hợt. Độc lập là own sâu một module, không phải chạm nông mười thứ. Mẹo: thà làm chủ hoàn hảo một module còn hơn dính líu nửa vời năm module.
Lỗi 4 — Bỏ quên việc xây lòng tin có chủ đích với đúng người. Lòng tin của PO, Tech Lead và người dùng cần được xây có chiến lược. Mẹo: lập một "danh sách 3 stakeholder chủ chốt" và mỗi tuần tự hỏi mình đã làm gì để tăng lòng tin của từng người.
Lỗi 5 — Giữ nguyên giọng điệu "khách hàng luôn đúng" khi làm việc nội bộ. Ở CS bạn luôn nhún nhường khách. Nhưng BA đôi khi phải nói "không" với stakeholder, phản biện PO, thách thức yêu cầu phi lý. Mẹo: tập nói "em không đồng ý, và đây là lý do" một cách chuyên nghiệp — đây là kỹ năng probation ngầm.
Mẹo vàng: Giữ một "nhật ký thắng lợi" (win log) từ ngày 30. Mỗi lần bạn gỡ được một vướng mắc, được ai đó khen, hay ra một quyết định đúng — ghi lại một dòng. Đến ngày 90, bạn có sẵn kho bằng chứng thay vì ngồi cố nhớ.
Bài tập thực hành
Bài tập 1 — Chọn module để own. Liệt kê 3 mảng nghiệp vụ trong sản phẩm bạn đang làm mà nền CS cho bạn lợi thế. Chọn 1 mảng, viết 3 câu vì sao bạn là người phù hợp nhất để own nó, rồi soạn tin nhắn chủ động đề nghị manager giao mảng đó.
Bài tập 2 — Chuyển câu hỏi thành quyết định. Viết ra 3 câu "xin phép" bạn thường hỏi manager (dạng "em nên... không anh?"). Viết lại mỗi câu thành một "thông báo quyết định kèm lý do và cửa phản hồi". So sánh cảm giác của hai phiên bản.
Bài tập 3 — Bản đồ 3 stakeholder. Kẻ bảng 3 cột: PO, Tech Lead, 1 người dùng đại diện. Với mỗi người, ghi: (a) họ quan tâm điều gì nhất, (b) mức độ tin bạn hiện tại (1-5), (c) một hành động cụ thể tuần này để tăng lòng tin.
Bài tập 4 — Dựng hồ sơ probation nháp. Dù mới đang ở tháng đầu, hãy tạo trước khung một trang gồm: module own, số story, chỉ số cải thiện, quote khen. Điền dần theo thời gian. Việc có sẵn khung buộc bạn thu thập bằng chứng ngay từ đầu thay vì nước đến chân mới nhảy.
Tóm tắt
Cửa sổ 60-90 ngày là ranh giới giữa "BA mới cần kèm" và "BA độc lập tự đứng". Mục tiêu rõ ràng: own trọn một module với 5-10 story mỗi sprint, giành lòng tin của PO, Tech Lead và ít nhất 2 người dùng, và pass probation bằng bằng chứng chứ không phải lời hứa.
Chuyển dịch tư duy quan trọng nhất là từ xin phép sang thông báo quyết định — cắt cho được cái "dây rốn escalate" của thời CS. Song song đó, hãy khai thác triệt để lợi thế ngầm của bạn: sự thấu hiểu nỗi đau người dùng, kỹ năng làm dịu xung đột, và bản năng đặt câu hỏi làm rõ — những thứ một BA thuần kỹ thuật phải mất nhiều năm mới có.
Từ câu chuyện của Linh, Tuấn và Mai, bài học chung là: độc lập không phải làm một mình, mà là làm chủ trọn vòng lặp công việc và biến nỗ lực thành bằng chứng nhìn thấy được. Hãy đi qua sáu bước, tránh năm lỗi phổ biến, giữ nhật ký thắng lợi — và bạn sẽ bước vào buổi đánh giá probation không phải với hy vọng, mà với một hồ sơ khiến manager không có lý do gì để nói "chưa".