Mở đầu — vì sao bài này quan trọng
Bạn đã làm được điều khó nhất: vượt qua vòng phỏng vấn và nhận offer BA đầu tiên sau nhiều năm gắn bó với Finance/Kế toán. Nhưng đây không phải vạch đích — đây mới là vạch xuất phát. 90 ngày đầu tiên quyết định gần như toàn bộ cách đồng nghiệp, stakeholder và sếp định hình ấn tượng về bạn. Trong thế giới doanh nghiệp, có một sự thật phũ phàng: người ta đánh giá năng lực của một nhân sự mới chủ yếu dựa trên 3 tháng đầu, và ấn tượng đó cực kỳ khó thay đổi về sau.
Với người chuyển từ Finance sang BA, giai đoạn này còn nhạy cảm gấp đôi. Một mặt, bạn mang theo "vốn liếng" cực giá trị: tư duy con số, hiểu quy trình tài chính, kỷ luật kiểm soát, khả năng đọc báo cáo. Mặt khác, bạn đang ở "sân khách" — chưa quen với ngôn ngữ của dev, chưa thạo Jira, chưa hiểu vì sao một user story lại được viết như thế. Nếu vội vàng chứng tỏ bản thân bằng cách "dạy" người khác, bạn sẽ bị gắn mác kiêu ngạo. Nếu rụt rè quá mức, bạn bị xem là thiếu năng lực. Bài này dạy bạn đi qua lằn ranh đó một cách khôn ngoan, theo công thức kinh điển 30-60-90 ngày: 30 ngày đầu quan sát và học, 30 ngày tiếp theo bắt đầu đóng góp, 30 ngày cuối tạo ra tác động đo lường được.
Khái niệm cốt lõi
Khung 90 ngày bắt nguồn từ cuốn The First 90 Days của Michael Watkins (Harvard Business School), nhưng tôi sẽ điều chỉnh cho riêng vai trò BA và riêng người nền Finance. Cốt lõi là: mỗi 30 ngày có một mục tiêu chủ đạo khác nhau, và bạn không được nhảy cóc.
Ngày 1-30: Observe & Learn — Quan sát và Học
Đây là giai đoạn "thấm". Mục tiêu duy nhất là hiểu bối cảnh, KHÔNG phải tạo ấn tượng. Bạn cần hấp thụ ba lớp thông tin:
- Tài liệu (documents): Đọc tất cả BRD (Business Requirements Document), SRS (Software Requirements Specification), RTM (Requirement Traceability Matrix), product roadmap, các bản backlog cũ, biên bản họp. Hãy đọc như đọc một bộ báo cáo tài chính lần đầu — tìm "câu chuyện" đằng sau, không chỉ đọc từng dòng.
- Con người (people): Lên lịch 1-on-1 (cuộc nói chuyện riêng 30 phút) với từng thành viên trong team — PO/PM, dev lead, QA lead, designer — và với 3-5 stakeholder chính ở phía business. Đây là việc quan trọng bậc nhất nhưng người mới thường bỏ qua vì ngại.
- Quy trình (process): Tham gia MỌI ceremony — daily standup, sprint planning, review, retrospective — nhưng ở giai đoạn này hãy ít nói, ghi nhiều. Bạn đang lập "bản đồ" cách team vận hành.
Ngày 31-60: Contribute — Bắt đầu đóng góp
Khi đã hiểu sân chơi, bạn bắt đầu cầm bóng. Nhận một requirement nhỏ, độ rủi ro thấp để làm trọn vẹn từ đầu đến cuối: elicit (khai thác yêu cầu), viết user story kèm acceptance criteria, đưa qua dev, theo đến khi xong. Mục tiêu là chứng minh bạn làm được việc thật, không phải làm việc lớn. Đồng thời, đây là lúc bạn khéo léo gắn thế mạnh Finance vào — ví dụ phát hiện một lỗ hổng logic trong yêu cầu liên quan đến tính toán, đối soát số liệu.
Ngày 61-90: Make an Impact — Tạo tác động
Giai đoạn cuối, bạn cần một "early win" — một thành quả nhỏ nhưng nhìn thấy được, đo đếm được, và được người khác công nhận. Đồng thời chủ động đề xuất một cải tiến quy trình dựa trên góc nhìn riêng của bạn. Kết thúc 90 ngày, bạn ngồi lại với sếp để xin feedback chính thức và cùng đặt mục tiêu cho quý tiếp theo.
Ba "tài sản" Finance giúp bạn đi nhanh hơn
Đừng quên rằng bạn không phải tay mơ. Người nền Finance có ba lợi thế tự nhiên trong 90 ngày này: (1) kỷ luật tài liệu — quen ghi chép đầy đủ, có dấu vết; (2) tư duy đối soát — phản xạ kiểm tra số liệu khớp nhau, rất hợp với việc verify requirement; (3) hiểu ngôn ngữ business — bạn nói chuyện được với phòng kế toán, phòng tài chính, mảng mà nhiều BA "dân IT thuần" rất ngại.
Tình huống thực tế
Tình huống 1: Chị Hương tại một fintech cho vay tiêu dùng (TP.HCM)
Chị Hương, 32 tuổi, từng là kế toán tổng hợp 6 năm tại một công ty sản xuất, chuyển sang làm BA tại một fintech lending có khoảng 150 nhân sự. Tuần đầu tiên, sếp giao cho chị một backlog 40 user story đang dang dở và nói "em xem rồi tham gia sprint planning thứ Năm nhé". Chị Hương hoảng. Theo phản xạ kế toán cũ, chị lao vào đọc từng story, cố hiểu hết mọi thứ trong 3 ngày, và đến buổi planning thì... ngồi im vì không hiểu các thuật ngữ "story point", "spike", "tech debt".
Sai lầm ở đây không phải ở chị Hương, mà ở cách chị tiếp cận: chị nhảy thẳng vào "làm" mà bỏ qua bước "hiểu người". Sau buổi planning thất bại, một mentor khuyên chị làm lại đúng bài: dành tuần 2 và 3 để gặp riêng 4 thành viên team và 4 stakeholder (trưởng phòng tín dụng, trưởng phòng vận hành, một dev senior, một QA). Trong các cuộc 1-on-1, chị hỏi đúng ba câu: "Anh/chị thấy sản phẩm này đang giải quyết vấn đề gì lớn nhất?", "Điều gì hay làm anh/chị khó chịu trong quy trình hiện tại?", "Nếu em là người mới, anh/chị muốn em chú ý điều gì?".
Bài học rút ra: Đến tuần 4, chị Hương không còn là "người mới ngồi im" mà là "người mới hiểu chuyện". Khi phát hiện một story về tính lãi suất phạt trả chậm có công thức sai (đây chính là lúc nền kế toán phát huy), chị nêu ra đúng lúc, đúng cách, và lập tức ghi điểm. Quan sát trước, đóng góp sau — đừng đảo ngược thứ tự.
Tình huống 2: Anh Tuấn và cái bẫy "muốn chứng tỏ ngay" tại một công ty ERP
Anh Tuấn từng là chuyên viên phân tích tài chính (FP&A) tại một tập đoàn bán lẻ, chuyển sang làm BA cho một nhà cung cấp giải pháp ERP. Tự tin với Excel và khả năng phân tích, ngay tuần thứ hai anh gửi cho cả team một email dài đề xuất "tái cấu trúc toàn bộ quy trình quản lý backlog vì cách hiện tại không tối ưu". Email đó được soạn rất chỉn chu, đầy số liệu — nhưng nó là một thảm họa quan hệ. Dev lead khó chịu vì cảm thấy bị một người mới chưa hiểu hệ thống "lên lớp". PO thấy bị qua mặt.
Vấn đề: anh Tuấn mang nguyên tư duy "tôi nhìn ra vấn đề tài chính thì tôi nói thẳng" sang một môi trường mà vốn quan hệ (relationship capital) quan trọng hơn việc đúng. Trong Finance, một con số sai là sai, không cãi được. Trong BA, "đúng" về mặt logic nhưng sai về timing và cách trình bày thì vẫn là thất bại.
Anh được sếp kéo lại và hướng dẫn: rút email, xin lỗi nhẹ nhàng, và giữ những quan sát đó cho riêng mình đến ngày 60. Đến giai đoạn 61-90, khi đã có uy tín nhờ làm tốt vài requirement nhỏ, anh trình bày lại đúng đề xuất đó — nhưng lần này dưới dạng một câu hỏi khiêm tốn trong buổi retrospective: "Em quan sát thấy backlog hay bị trùng, không biết mình thử gắn nhãn theo module xem sao?". Lần này, cả team gật đầu.
Bài học rút ra: Cùng một ý tưởng, nói ở ngày 14 thì bị ghét, nói ở ngày 70 thì được khen. Thời điểm và uy tín tích lũy quan trọng ngang nội dung.
Tình huống 3: Early win của chị Mai tại một ngân hàng số
Chị Mai chuyển từ kiểm toán nội bộ sang BA mảng core banking. Đến cuối tháng thứ hai, chị nhận một requirement nhỏ: cải tiến màn hình đối soát giao dịch cuối ngày cho bộ phận vận hành. Nhờ nền kiểm toán, chị nhận ra báo cáo đối soát hiện tại thiếu một cột "chênh lệch lũy kế" khiến nhân viên vận hành phải tự tính tay mỗi ngày, mất khoảng 45 phút. Chị viết requirement bổ sung cột này, phối hợp dev làm trong một sprint.
Kết quả: thời gian đối soát cuối ngày giảm từ ~45 phút xuống ~10 phút cho mỗi nhân viên vận hành. Một con số nhỏ, nhưng chị Mai trình bày nó rõ ràng trong sprint review với số liệu cụ thể. Đó chính là "early win" hoàn hảo cho ngày thứ 75.
Bài học rút ra: Early win không cần hoành tráng. Một cải tiến tiết kiệm 35 phút/ngày cho một nhóm người, có số đo rõ ràng, đáng giá hơn một dự án lớn còn dang dở. Và hãy dùng đúng thế mạnh nghề cũ của bạn để tìm ra nó.
Hướng dẫn từng bước
Tuần 1 (Ngày 1-7): Thiết lập nền tảng.
- Xin quyền truy cập đầy đủ: Jira, Confluence, repo tài liệu, kênh Slack/Teams, hệ thống test.
- Yêu cầu sếp một danh sách "must-read documents" và "must-meet people".
- Tạo một file ghi chú cá nhân (onboarding journal) — ghi mọi thuật ngữ lạ, mọi câu hỏi nảy ra. Tận dụng kỷ luật ghi chép của dân kế toán.
- Đọc toàn bộ BRD, SRS, RTM. Đọc backlog hiện tại, không cần hiểu hết, chỉ cần nắm bức tranh lớn.
- Đặt lịch 1-on-1 với từng thành viên team và 3-5 stakeholder. Chuẩn bị 3-4 câu hỏi mở cho mỗi buổi.
- Dự mọi ceremony với tâm thế quan sát: cách họ ước lượng, cách họ tranh luận, ai là người ra quyết định thật sự.
- Vẽ một sơ đồ stakeholder map: ai ảnh hưởng ai, ai cần được giữ hài lòng.
- Viết một bản tóm tắt "Hiểu biết của tôi sau 30 ngày" gửi sếp — vừa để xác nhận mình hiểu đúng, vừa thể hiện sự chủ động.
- Nhận một requirement rủi ro thấp. Tự elicit, viết user story + acceptance criteria, đưa qua dev, theo đến UAT.
- Bắt đầu phát biểu trong ceremony, nhưng vẫn ưu tiên đặt câu hỏi thông minh hơn là khẳng định.
- Bí mật ghi lại 2-3 cơ hội cải tiến bạn quan sát được, chưa nói vội.
- Hoàn thành một "early win" có số đo. Trình bày trong sprint review.
- Đề xuất MỘT cải tiến quy trình, đóng gói dưới dạng câu hỏi khiêm tốn trong retro.
- Xin một buổi feedback chính thức với sếp. Hỏi thẳng: "Em đang làm tốt ở đâu, cần cải thiện ở đâu?". Cùng đặt mục tiêu quý sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Vội chứng tỏ trong tháng đầu. Như anh Tuấn, mang tư duy "nói thẳng vì tôi đúng" của Finance sang. Mẹo: dán một câu lên màn hình — "Tháng 1: học, không dạy".
Lỗi 2 — Bỏ qua 1-on-1 vì ngại làm phiền. Đây là sai lầm phổ biến nhất của người hướng nội. Mẹo: đóng khung lời mời thành "em mới vào, muốn học từ anh/chị 30 phút" — gần như không ai từ chối một lời mời khiêm tốn như vậy.
Lỗi 3 — Đọc tài liệu thụ động, không ghi câu hỏi. Đọc xong quên hết. Mẹo: với mỗi tài liệu, ghi lại 3 câu hỏi để mang đi hỏi người liên quan.
Lỗi 4 — Im lặng quá lâu, sang tháng 2-3 vẫn không phát biểu. Quan sát là để chuẩn bị đóng góp, không phải để trốn. Mẹo: đặt cột mốc cứng — ngày 31 phải bắt đầu cầm việc.
Lỗi 5 — Chọn early win quá lớn, đến ngày 90 vẫn dang dở. Mẹo: ưu tiên việc nhỏ, đo được, hoàn thành trong một sprint. "Hoàn thành nhỏ" thắng "dang dở lớn".
Mẹo vàng cho người Finance: Hãy chủ động xung phong làm cầu nối cho các requirement có yếu tố tài chính, kế toán, đối soát, compliance. Đó là vùng đất nhiều BA né tránh và là nơi bạn tỏa sáng nhanh nhất.
Bài tập thực hành
- Lập kế hoạch 30-60-90 cá nhân: Viết ra một trang giấy, mỗi giai đoạn 30 ngày ghi rõ: mục tiêu chủ đạo, 3 việc cụ thể phải làm, và 1 chỉ số để biết mình đã thành công.
- Soạn bộ câu hỏi 1-on-1: Viết sẵn 5 câu hỏi mở bạn sẽ dùng khi gặp riêng stakeholder. Phân loại: 2 câu về vấn đề/nỗi đau, 2 câu về kỳ vọng với bạn, 1 câu về quy trình.
- Xác định early win tiềm năng: Dựa trên nền Finance của bạn, liệt kê 3 loại vấn đề (đối soát, tính toán, báo cáo, compliance) mà bạn tin mình có thể tìm ra cải tiến nhanh hơn một BA không có nền tài chính. Với mỗi loại, ghi rõ chỉ số bạn sẽ dùng để chứng minh tác động.
- Tự kiểm tra mindset: Viết lại tình huống của anh Tuấn theo cách bạn sẽ xử lý khác đi. Bạn sẽ giữ lại quan sát đó đến ngày nào, và trình bày bằng câu nói cụ thể như thế nào?
Tóm tắt
90 ngày đầu làm BA không phải cuộc đua tốc độ, mà là cuộc đua thứ tự đúng. Tháng 1: quan sát và học — đọc hết tài liệu (BRD, SRS, RTM), gặp riêng từng thành viên và 3-5 stakeholder, dự mọi ceremony với tâm thế ít nói, ghi nhiều. Tháng 2: bắt đầu đóng góp — cầm một requirement nhỏ làm trọn vẹn để chứng minh năng lực thật. Tháng 3: tạo tác động — một early win đo được, một đề xuất cải tiến khiêm tốn, và một buổi feedback chính thức.
Là người chuyển từ Finance, bạn có ba tài sản quý: kỷ luật tài liệu, tư duy đối soát, và khả năng nói chuyện với business. Nhưng cũng nhớ ba cái bẫy: vội chứng tỏ, nói đúng nhưng sai timing, và bỏ qua vốn quan hệ. Hãy nhớ bài học của anh Tuấn — cùng một ý tưởng, ngày 14 bị ghét, ngày 70 được khen. Đi đúng nhịp, dùng đúng thế mạnh, và đến ngày thứ 90 bạn sẽ không còn là "người mới chuyển ngành" mà là "BA mà cả team tin tưởng".