Mở đầu — vì sao bài này quan trọng
Bạn đã làm được điều khó nhất: chuyển đổi từ Designer sang BA và nhận được offer. Nhưng có một sự thật ít ai nói với bạn — 90 ngày đầu tiên tại vị trí mới quyết định phần lớn quỹ đạo sự nghiệp BA của bạn tại công ty đó. Đây là giai đoạn mọi người xung quanh âm thầm đánh giá: "Người này có đáng tin không? Có hiểu việc không? Có gánh được requirements không?"
Với người chuyển nghề từ Design, 90 ngày đầu vừa là cơ hội vàng vừa là bẫy nguy hiểm. Cơ hội vì bạn mang một góc nhìn khác biệt mà đội thuần kỹ thuật không có: sự đồng cảm với người dùng, khả năng trực quan hóa, tư duy hệ thống về trải nghiệm. Bẫy vì bạn dễ rơi vào hai thái cực — hoặc quá tự ti, im lặng vì sợ mình "không phải dân IT chính gốc"; hoặc quá nóng vội, xông vào đề xuất giải pháp trước khi hiểu bối cảnh, khiến team nghĩ bạn vẫn tư duy như một designer chỉ quan tâm đến UI.
Bài học này cho bạn một roadmap hòa nhập cụ thể, chia theo ba mốc 30-60-90 ngày. Không phải lý thuyết chung chung mà là những việc làm hằng ngày, những câu hỏi cần đặt, những tài liệu cần đọc, và những cạm bẫy đặc thù của người từ nền Design. Mục tiêu cuối bài: bạn có một kế hoạch có thể mở ra và tick từng dòng ngay ngày đầu đi làm.
Khái niệm cốt lõi
Triết lý 30-60-90: từ quan sát đến đóng góp
Roadmap 90 ngày kinh điển của Michael Watkins (tác giả The First 90 Days) chia thành ba giai đoạn với ba tâm thế khác nhau. Áp dụng cho vai trò BA, ta có:
- 30 ngày đầu — Observe & Learn (Quan sát & Học): Nhiệm vụ số một là hiểu, không phải chứng minh. Bạn thu thập bối cảnh: sản phẩm giải quyết vấn đề gì, ai là stakeholder, quy trình làm việc ra sao, domain nghiệp vụ vận hành thế nào. Đây là giai đoạn "nạp dữ liệu".
- 60 ngày giữa — Contribute & Validate (Đóng góp & Kiểm chứng): Bạn bắt đầu cầm những phần việc nhỏ, độc lập. Viết user story cho một feature phụ, chạy một buổi elicitation, cập nhật một phần của RTM (Requirement Traceability Matrix — ma trận truy vết yêu cầu). Mục tiêu là ghi những "early win" — thắng lợi sớm — để xây dựng lòng tin.
- 90 ngày cuối — Own & Lead (Làm chủ & Dẫn dắt): Bạn nhận trách nhiệm end-to-end cho ít nhất một luồng nghiệp vụ hoặc một feature từ elicitation đến UAT (User Acceptance Testing — kiểm thử chấp nhận). Bạn trở thành "người đi hỏi" chứ không còn là "người luôn đi hỏi".
Ba loại "vốn" cần tích lũy song song
Trong suốt 90 ngày, bạn xây dựng đồng thời ba loại vốn:
- Vốn kiến thức (Knowledge capital): Hiểu domain, hiểu sản phẩm, hiểu tài liệu. Đây là thứ dễ đo nhất.
- Vốn quan hệ (Relationship capital): Mạng lưới tin cậy với dev, QA, PO/PM, và business stakeholder. BA về bản chất là nghề cầu nối, không có quan hệ thì requirement dù đúng cũng không được thực thi.
- Vốn uy tín (Credibility capital): Danh tiếng "làm được việc, đáng tin". Được xây từ những cam kết nhỏ được giữ đúng hẹn, chứ không từ lời hứa lớn.
Học chủ động, không học thụ động
Sai lầm lớn nhất là ngồi đợi được "onboard". Onboarding tốt là do bạn tự thiết kế. BA giỏi biến mỗi cuộc gặp thành một buổi elicitation nhỏ — bạn không chỉ nghe, bạn đặt câu hỏi có cấu trúc, ghi chép, và kiểm chứng lại điều mình hiểu.
Tình huống thực tế
Tình huống 1 — Linh, cú vấp của người nóng vội tại một fintech ở TP.HCM
Linh, 27 tuổi, làm Product Designer 3 năm tại một startup, chuyển sang vị trí BA cho một công ty ví điện tử tại TP.HCM (khoảng 120 nhân sự). Tuần thứ hai, trong buổi refinement, Linh thấy luồng nạp tiền có UX "rất tệ" — 5 bước, nhiều màn hình. Bằng phản xạ designer, cô lập tức đề xuất redesign gộp còn 2 bước và vẽ luôn wireframe trình bày trước team.
Kết quả: một dev senior nhẹ nhàng giải thích rằng 5 bước đó tồn tại vì yêu cầu KYC (Know Your Customer — định danh khách hàng) của Ngân hàng Nhà nước, cộng với ràng buộc từ đối tác cổng thanh toán chỉ trả kết quả bất đồng bộ. "Đề xuất" của Linh vi phạm compliance. Cô mất mặt, và tệ hơn, team dán nhãn "designer chỉ quan tâm giao diện, không hiểu nghiệp vụ".
Bài học: Trong 30 ngày đầu, giải pháp bạn nhìn thấy gần như luôn thiếu bối cảnh. Trước khi đề xuất bất cứ thay đổi nào, hãy hỏi "Tại sao hiện tại nó lại như vậy?" ít nhất ba lần. Linh sửa sai bằng cách dành hai tuần đọc toàn bộ tài liệu compliance và ngồi cạnh bộ phận vận hành. Đến tháng thứ ba, chính cô là người đề xuất cải tiến luồng KYC trong khuôn khổ pháp lý — và lần này được cả team ủng hộ.
Tình huống 2 — Đức, người biến điểm mạnh Design thành early win tại Tiki
Đức chuyển từ UX Designer sang BA cho một team thuộc mảng logistics của một sàn thương mại điện tử lớn tại Việt Nam. Anh không cố giấu gốc gác Design mà tận dụng nó một cách khôn ngoan. Tuần đầu, khi đọc BRD (Business Requirements Document) của feature "theo dõi đơn hàng", anh thấy tài liệu mô tả các trạng thái đơn hàng bằng văn bản dài dòng, dev và QA hiểu mỗi người một kiểu.
Đức dành một buổi tối vẽ lại toàn bộ vòng đời đơn hàng thành một state diagram (sơ đồ trạng thái) trực quan — điểm mạnh sẵn có từ nghề cũ. Anh mang lên buổi standup, hỏi "Em vẽ thế này có đúng không, chỗ nào sai mọi người sửa giúp em." Sơ đồ trở thành tài liệu tham chiếu chung của team. QA lead công khai cảm ơn vì nó giúp viết test case rõ hơn.
Bài học: Early win không cần hoành tráng. Đức thắng nhờ giải quyết một nỗi đau nhỏ có thật (mơ hồ về trạng thái) bằng đúng thế mạnh của mình (trực quan hóa), và trình bày với thái độ cầu thị chứ không phán xét. Đến ngày thứ 60, anh đã được giao làm chủ toàn bộ luồng nghiệp vụ hoàn đơn.
Tình huống 3 — Mai và tấm bản đồ stakeholder cứu vãn dự án
Mai vào làm BA tại một công ty phần mềm gia công (outsourcing) ở Hà Nội, dự án cho khách hàng Singapore trong lĩnh vực bảo hiểm. Ngày đầu, thay vì lao vào code base, Mai vẽ một stakeholder map: ai quyết định (decision maker), ai bị ảnh hưởng, ai cung cấp thông tin, kênh liên lạc là gì, múi giờ ra sao. Cô phát hiện có một "hidden stakeholder" — trưởng phòng nghiệp vụ phía khách hàng, người không có trong các cuộc họp chính thức nhưng lại là người thực sự duyệt requirement cuối cùng.
Mai chủ động xin sếp một buổi 1-on-1 30 phút với người này qua video call. Nhờ đó, khi team submit bản đặc tả tính năng tính phí bảo hiểm, Mai đã biết trước ba ràng buộc nghiệp vụ mà không ai khác nắm được, tránh cho dự án một vòng rework tốn khoảng hai tuần công.
Bài học: Trong 30 ngày đầu, đầu tư vào con người quan trọng ngang đầu tư vào tài liệu. Một stakeholder map tốt và những buổi 1-on-1 sớm giúp bạn lộ diện những "mắt xích ẩn" mà tài liệu không bao giờ ghi.
Hướng dẫn từng bước
Giai đoạn 1 — 30 ngày đầu: Observe & Learn
Tuần 1 — Thiết lập nền tảng:
- Xin quyền truy cập tất cả công cụ: Jira, Confluence, Git/repo tài liệu, kênh Slack/Teams, hệ thống demo/staging.
- Đọc theo thứ tự ưu tiên: tài liệu tầm nhìn sản phẩm (product vision) → BRD → SRS/FRD (Software/Functional Requirements) → RTM → tài liệu compliance/nghiệp vụ đặc thù (nếu có domain như fintech, banking).
- Lập một file "câu hỏi ngu" (dumb questions log) — ghi mọi thuật ngữ, viết tắt, quy trình chưa hiểu. Đừng ngại; hỏi sớm luôn rẻ hơn hỏi muộn.
- Vẽ stakeholder map (như tình huống của Mai). Xác định decision maker, SME (Subject Matter Expert — chuyên gia nghiệp vụ), người dùng cuối.
- Lên lịch 1-on-1 với mỗi thành viên team (dev, QA, PO/PM, tester) và 3–5 stakeholder chính. Khung câu hỏi gợi ý: "Anh/chị mong đợi gì ở một BA tốt? Điều gì hiện đang gây khó chịu nhất trong quy trình? Nếu em cần hỏi việc, nên hỏi ai?"
- Tự dùng sản phẩm như một người dùng thật (dogfooding). Ghi lại mọi điểm khó hiểu — đây là lúc "con mắt tươi" (fresh eyes) của bạn có giá trị nhất.
- Tham gia (dự thính) mọi ceremony: standup, refinement, sprint planning, retro. Quan sát cách team viết story, định nghĩa "done", xử lý change.
- Ngồi cạnh (shadowing) một BA/PO có kinh nghiệm hoặc một nhân viên vận hành để hiểu nghiệp vụ thực tế.
- Viết một tài liệu tổng hợp "As-Is" ngắn về một luồng nghiệp vụ bạn đã hiểu, gửi cho mentor kiểm tra. Đây là bài kiểm tra mức độ nạp kiến thức của bạn.
Giai đoạn 2 — 60 ngày: Contribute & Validate
- Nhận một phần việc nhỏ, ranh giới rõ ràng: viết user story + acceptance criteria cho một feature phụ, hoặc cập nhật một mục trong RTM.
- Chủ trì (hoặc đồng chủ trì) một buổi elicitation nhỏ với sự giám sát của mentor.
- Chọn một "early win" tận dụng thế mạnh Design của bạn: vẽ lại một process flow rối rắm, chuẩn hóa một wireframe annotation, làm rõ một state diagram (như Đức).
- Sau mỗi việc, chủ động xin feedback: "Em làm phần này, có chỗ nào chưa chuẩn theo cách team quen làm không?"
Giai đoạn 3 — 90 ngày: Own & Lead
- Nhận làm chủ end-to-end ít nhất một feature/luồng nghiệp vụ, từ elicitation → đặc tả → làm việc với dev → hỗ trợ UAT.
- Đề xuất một cải tiến có căn cứ (như Linh làm ở tháng thứ ba) — lúc này bạn đã đủ bối cảnh để đề xuất được lắng nghe.
- Ngồi lại với line manager, tự đánh giá và thống nhất kỳ vọng cho quý tiếp theo.
Lỗi thường gặp & mẹo
Lỗi 1 — Đề xuất giải pháp quá sớm. Đây là bẫy đặc thù nhất của người từ Design. Bạn quen "nhìn vấn đề là muốn fix". Mẹo: đặt ra quy tắc cá nhân "no solution in first 30 days" — trong 30 ngày đầu chỉ hỏi và ghi, không đề xuất thay đổi. Thay câu "Cái này nên làm thế này" bằng câu "Tại sao hiện tại nó lại thế này?".
Lỗi 2 — Im lặng vì hội chứng kẻ mạo danh (impostor syndrome). Không phải dân IT chính gốc nên bạn sợ hỏi lộ dốt. Sự thật: BA giỏi là người biết đặt câu hỏi đúng, không phải người biết sẵn mọi thứ. Mẹo: mỗi ngày đặt ít nhất ba câu hỏi thật. Người mới hỏi nhiều là chuyện bình thường và được kỳ vọng.
Lỗi 3 — Nhầm bận rộn với tiến bộ. Đọc 200 trang tài liệu không tự động thành hiểu. Mẹo: sau mỗi tài liệu quan trọng, viết một đoạn tóm tắt 5 dòng bằng lời của mình và nhờ người khác xác nhận.
Lỗi 4 — Bỏ quên vốn quan hệ với dev và QA. Nhiều BA mới chỉ chăm chăm làm việc với business, quên rằng dev và QA mới là người biến requirement thành sản phẩm. Mẹo: uống cà phê với ít nhất một dev và một QA trong tháng đầu, hỏi họ "requirement thế nào thì anh làm việc dễ nhất?".
Lỗi 5 — Không quản lý kỳ vọng với sếp. Bạn tưởng mình đang làm tốt trong khi sếp mong bạn nhanh hơn, hoặc ngược lại. Mẹo: xin một buổi check-in ngắn cuối mỗi tuần trong tháng đầu để đồng bộ kỳ vọng.
Mẹo vàng — Biến điểm yếu "không phải dân code" thành điểm mạnh "fresh eyes". Con mắt mới của bạn nhìn thấy những điểm khó hiểu mà người ở lâu đã "mù" vì quen. Ghi lại chúng ngay tuần đầu; đây là nguồn giá trị mà không ai khác trong team có.
Bài tập thực hành
- Soạn kế hoạch 30-60-90 của riêng bạn: Dựa trên công ty/vị trí mục tiêu (thật hoặc giả định), viết ra 5 việc cụ thể cho mỗi mốc 30, 60, 90 ngày. Mỗi việc phải đo được (ví dụ "hoàn thành 1-on-1 với 8 người" thay vì "làm quen với team").
- Thiết kế bộ câu hỏi 1-on-1: Viết 7 câu hỏi bạn sẽ hỏi trong buổi 1-on-1 đầu tiên với một dev, và 7 câu khác cho một business stakeholder. Lưu ý sự khác biệt về ngôn ngữ và mối quan tâm của hai nhóm.
- Lập stakeholder map giả định: Cho tình huống bạn là BA mới của một dự án app đặt lịch khám bệnh. Vẽ stakeholder map gồm ít nhất 6 nhóm, phân loại theo mức độ ảnh hưởng và mức độ quan tâm, và chỉ ra ai có thể là "hidden stakeholder".
- Lên kịch bản một early win: Chọn một thế mạnh từ nền Design của bạn và mô tả một early win cụ thể bạn có thể tạo ra trong 60 ngày đầu, kèm cách bạn sẽ trình bày nó với thái độ cầu thị.
Tóm tắt
90 ngày đầu làm BA không phải cuộc thi chứng minh bạn giỏi, mà là hành trình xây dựng ba loại vốn: kiến thức, quan hệ và uy tín. Chia theo ba mốc: 30 ngày đầu quan sát và học (đọc tài liệu, 1-on-1, hiểu domain, tuyệt đối không vội đề xuất giải pháp); 60 ngày đóng góp và kiểm chứng (nhận việc nhỏ, ghi early win, xin feedback liên tục); 90 ngày làm chủ và dẫn dắt (sở hữu một luồng nghiệp vụ end-to-end và bắt đầu đề xuất cải tiến có căn cứ).
Ba tình huống của Linh, Đức và Mai cho thấy ba bài học then chốt: đừng đề xuất giải pháp khi chưa hiểu bối cảnh, hãy biến thế mạnh Design thành early win khiêm tốn, và đầu tư vào con người — đặc biệt những stakeholder ẩn — ngang với đầu tư vào tài liệu. Cạm bẫy lớn nhất của người chuyển nghề là nóng vội hoặc tự ti; giải pháp là kỷ luật "no solution in first 30 days" cộng thói quen hỏi ba câu hỏi thật mỗi ngày. Hãy mở kế hoạch 30-60-90 của bạn ra ngay ngày đầu đi làm, và tick từng dòng.