Mở đầu — vì sao bài này quan trọng
Bạn vừa nhận được offer BA đầu tiên sau bao tháng chuyển đổi từ Sales/BD. Cảm giác vỡ òa. Nhưng tôi muốn nói thẳng một sự thật mà ít ai dám nói: offer chỉ là vạch xuất phát, không phải vạch đích. 90 ngày đầu tiên mới là giai đoạn quyết định bạn có thực sự "trụ lại" được trong nghề BA hay không.
Với người chuyển ngành từ Sales, 90 ngày đầu vừa là lợi thế vừa là cạm bẫy. Lợi thế: bạn có bản năng kết nối con người, đọc vị stakeholder, và sự tự tin giao tiếp mà nhiều BA "thuần kỹ thuật" phải mất nhiều năm mới có. Cạm bẫy: chính sự tự tin đó có thể khiến bạn nói quá nhiều, "chốt" quá sớm, và bỏ qua giai đoạn lắng nghe — đúng những thói quen đã giúp bạn thành công ở Sales nhưng lại gây hại trong vai trò BA.
Trong ngành phần mềm, người ta hay nhắc đến cuốn The First 90 Days của Michael Watkins (Harvard Business Review). Triết lý cốt lõi: mỗi giai đoạn chuyển đổi vai trò đều cần một kế hoạch nhập cuộc có chủ đích (onboarding roadmap), thay vì để mọi thứ "tự nhiên trôi". Bài học hôm nay sẽ cho bạn một roadmap 30-60-90 cụ thể, áp dụng riêng cho người từ nền Sales/BD bước vào ghế BA. Đây không phải lý thuyết suông — đây là tấm bản đồ để bạn không bị lạc trong 3 tháng quan trọng nhất sự nghiệp BA của mình.
Khái niệm cốt lõi
Vì sao chia thành 3 giai đoạn 30 ngày?
Bộ não con người không thể "vừa học vừa tạo dấu ấn vừa dẫn dắt" cùng lúc trong môi trường mới. Roadmap 90 ngày chia thành ba pha có trọng tâm khác nhau, mỗi pha xây trên nền của pha trước:
- Ngày 1–30: Observe & Learn (Quan sát và Học). Mục tiêu duy nhất là hiểu. Hiểu sản phẩm, hiểu quy trình, hiểu con người, hiểu "luật bất thành văn". Ở giai đoạn này, im lặng có giá trị hơn lời nói.
- Ngày 31–60: Contribute & Validate (Đóng góp và Kiểm chứng). Bắt đầu nhận task thật, viết tài liệu thật, nhưng luôn kiểm chứng giả định với người có kinh nghiệm. Đây là pha "tập đi có người dắt".
- Ngày 61–90: Own & Lead (Sở hữu và Dẫn dắt). Bạn tự chủ một luồng công việc, chủ trì một buổi họp, và bắt đầu để lại dấu ấn cá nhân.
Khác biệt cốt lõi so với Sales
Ở Sales, đồng hồ đếm ngược ngay từ ngày đầu — bạn bị đo bằng deal, bằng số. Bản năng "phải tạo kết quả nhanh" ăn sâu vào máu. Nhưng BA là nghề của độ chính xác về thông tin, không phải tốc độ chốt. Một requirement sai do bạn vội vàng "chốt" trong tuần đầu có thể khiến cả team dev làm lại sản phẩm sau 2 tháng — thiệt hại lớn hơn nhiều so với việc bạn chậm vài ngày để hỏi cho kỹ.
Hãy ghi nhớ công thức tâm lý này: Trong 30 ngày đầu, đơn vị đo thành công của bạn không phải là "tôi đã làm được gì" mà là "tôi đã hiểu được gì".
Ba "tài sản" cần thu thập trong 90 ngày
- Domain knowledge — kiến thức nghiệp vụ của sản phẩm/ngành công ty đang làm.
- Relationship capital — vốn quan hệ với dev, QA, PO, stakeholder. Đây là thứ ex-Sales có lợi thế tự nhiên, hãy tận dụng tối đa.
- Process fluency — sự thành thạo về cách team vận hành: công cụ (Jira, Confluence), nghi thức (ceremony), và chuẩn tài liệu.
Tình huống thực tế
Ví dụ 1: Anh Tuấn — ex-BD bất động sản nói quá nhiều trong tuần đầu
Anh Tuấn, 31 tuổi, từng là BD cho một sàn bất động sản tại TP.HCM, chuyển sang làm BA cho một công ty proptech (công nghệ bất động sản) khoảng 80 nhân sự. Tuần đầu tiên, trong buổi Sprint Planning, anh nghe team thảo luận về tính năng "đăng tin ký gửi". Theo bản năng BD, anh nhảy vào ngay: "Cái này dễ mà, bên sàn cũ anh làm hoài, mình cứ làm form 5 bước là xong."
Vấn đề: hệ thống của công ty mới có ràng buộc về xác thực giấy tờ pháp lý qua API của bên thứ ba — thứ anh hoàn toàn không biết. Đề xuất "5 bước" của anh bỏ qua bước verify quan trọng nhất. Tệ hơn, anh đã phát biểu với giọng điệu chắc nịch khiến một bạn dev senior cảm thấy bị "dạy nghề".
Bài học rút ra: Kinh nghiệm domain cũ của bạn là tài sản, nhưng đừng để nó biến thành định kiến. Trong 30 ngày đầu, hãy đổi câu khẳng định thành câu hỏi: thay vì "mình cứ làm form 5 bước", hãy hỏi "ở sàn cũ em từng thấy quy trình 5 bước, không biết bên mình có ràng buộc pháp lý gì khác không ạ?" Cùng một kiến thức, nhưng cách trình bày khiêm tốn giúp bạn vừa thể hiện năng lực vừa không gây mất lòng.
Ví dụ 2: Chị Linh — ex-Sales SaaS tận dụng 1-on-1 để xây vốn quan hệ
Chị Linh chuyển từ vị trí Account Executive (Sales) sang BA tại một công ty SaaS quản lý nhân sự ở Hà Nội. Chị áp dụng đúng nguyên tắc "im lặng quan sát" nhưng làm thông minh hơn: trong 3 tuần đầu, chị chủ động đặt lịch cà phê 1-on-1 với từng người — 2 dev, 1 QA, 1 PO, và 3 stakeholder bên phòng vận hành.
Mỗi buổi, chị chỉ hỏi ba câu đơn giản: "Anh/chị đang đau đầu nhất với điều gì trong sản phẩm hiện tại?", "Theo anh/chị, một BA tốt ở đây nên làm gì khác đi?", và "Em nên đọc tài liệu nào trước tiên?". Kết quả: đến cuối tháng đầu, chị đã có một bản đồ stakeholder rõ ràng, biết ai là người ra quyết định thật sự (không phải lúc nào cũng là người có chức danh cao nhất), và quan trọng nhất — mọi người đều có thiện cảm vì chị "chịu lắng nghe".
Khi đến giai đoạn 60 ngày, chị cần một stakeholder bên vận hành dành thời gian review BRD gấp. Người này — vốn nổi tiếng khó tính — đồng ý ngay, vì chị đã "gửi tiền vào tài khoản quan hệ" từ những buổi cà phê đầu tiên.
Bài học rút ra: Kỹ năng đọc vị con người và xây quan hệ của ex-Sales là vũ khí cực mạnh trong onboarding BA. Nhưng hãy dùng nó để thu thập thông tin và xây niềm tin, chứ không phải để "bán" bản thân. 1-on-1 không phải buổi pitch về bạn — đó là buổi để bạn lắng nghe.
Ví dụ 3: Anh Hùng — bỏ qua việc đọc tài liệu cũ và trả giá
Anh Hùng vào làm BA cho một startup fintech ví điện tử ở Singapore (chi nhánh có team VN). Tự tin với khả năng "học nhanh qua trò chuyện" kiểu Sales, anh bỏ qua kho tài liệu cũ — BRD, SRS, và đặc biệt là RTM (Requirements Traceability Matrix, ma trận truy vết yêu cầu liên kết requirement với test case và tính năng).
Tuần thứ 5, anh được giao viết spec cho tính năng "hoàn tiền giao dịch lỗi". Anh viết một bản spec mới tinh, rất gọn gàng. Nhưng khi đưa cho QA, bạn ấy phát hiện: spec của anh mâu thuẫn với một business rule đã được chốt 6 tháng trước về "thời hạn hoàn tiền tối đa 7 ngày làm việc" — thứ được ghi rõ trong RTM mà anh chưa từng mở ra. Anh phải viết lại toàn bộ, mất 3 ngày, và mất một chút uy tín với team.
Bài học rút ra: Tài liệu cũ là "bộ nhớ tập thể" của dự án. Với ex-Sales quen học qua hội thoại, đây là điểm yếu cố hữu — bạn thích hỏi người hơn đọc tài liệu. Hãy ép bản thân dành ít nhất 30% thời gian tuần đầu để đọc BRD, SRS, RTM và các tài liệu quyết định kiến trúc. Hỏi người là để bổ sung cho tài liệu, không phải thay thế tài liệu.
Hướng dẫn từng bước
Giai đoạn 1 (Ngày 1–30): Observe & Learn
- Đọc toàn bộ tài liệu nền tảng. Yêu cầu manager hoặc PO cho bạn quyền truy cập Confluence/SharePoint. Ưu tiên đọc theo thứ tự: tài liệu tổng quan sản phẩm (product overview) → BRD (Business Requirements Document) → SRS (Software Requirements Specification) → RTM → các quyết định kiến trúc gần đây. Ghi chú lại mọi thuật ngữ lạ vào một file "glossary cá nhân".
- Thực hiện 1-on-1 có cấu trúc. Đặt lịch với từng thành viên trong team (dev, QA, PO/PM, designer) và 3–5 stakeholder chính. Dùng bộ ba câu hỏi: pain point hiện tại, kỳ vọng với vai trò BA, và tài liệu nên đọc. Sau mỗi buổi, cập nhật stakeholder map của bạn (ai ảnh hưởng, ai ra quyết định).
- Tham gia mọi ceremony với tâm thế "ghi chép, không phán xét". Dự đầy đủ Daily Standup, Sprint Planning, Refinement, Retrospective, Review. Quy tắc: nói ít, ghi nhiều. Mục tiêu là hiểu nhịp của team và quy ước giao tiếp.
- Lập "câu hỏi tồn đọng". Mỗi khi gặp điều chưa hiểu, đừng ngắt ngang buổi họp. Ghi vào một danh sách, rồi gom lại hỏi mentor/buddy trong buổi review riêng. Điều này thể hiện sự tôn trọng thời gian tập thể.
Giai đoạn 2 (Ngày 31–60): Contribute & Validate
- Nhận task thật nhưng quy mô nhỏ. Xin manager giao cho bạn một user story hoặc một spec nhỏ, độc lập, ít rủi ro. Viết requirement, rồi luôn nhờ một BA/PO có kinh nghiệm review trước khi đưa cho dev.
- Tự kiểm chứng giả định. Trước khi viết, hãy đối chiếu với RTM và business rule catalog. Hỏi: "Giả định này của tôi đã được ai xác nhận chưa?" Đây chính là kỷ luật mà ví dụ anh Hùng ở trên thiếu.
- Bắt đầu đóng góp trong ceremony. Giờ bạn có thể phát biểu, nhưng theo công thức "quan sát + câu hỏi" thay vì "khẳng định". Ví dụ: "Em thấy story này chưa có acceptance criteria cho trường hợp lỗi mạng, mình có cần bổ sung không ạ?"
Giai đoạn 3 (Ngày 61–90): Own & Lead
- Sở hữu một luồng công việc end-to-end. Tự chịu trách nhiệm một epic hoặc một feature từ elicitation đến khi dev nhận đủ requirement. Bạn vẫn có thể hỏi, nhưng giờ bạn là người dẫn.
- Chủ trì ít nhất một buổi họp. Lý tưởng nhất là một buổi Refinement hoặc một workshop elicitation nhỏ. Đây là lúc kỹ năng facilitation từ nền Sales tỏa sáng.
- Xin feedback chính thức và lập kế hoạch tiếp theo. Đặt một buổi review 90 ngày với manager. Hỏi thẳng: "Em đang làm tốt điều gì, và đâu là điều em cần cải thiện trong quý tới?" Dùng câu trả lời để lập kế hoạch phát triển cho 3 tháng kế.
Lỗi thường gặp & mẹo
Lỗi 1: "Hội chứng chốt deal" — vội tạo kết quả trong tháng đầu. Ex-Sales bị áp lực tâm lý phải "ghi điểm" ngay. Đừng. Mẹo: tự nhắc bản thân rằng trong 30 ngày đầu, "thành tích" của bạn chính là chất lượng câu hỏi bạn đặt ra, không phải số tài liệu bạn viết.
Lỗi 2: Nói át dev trong các buổi kỹ thuật. Sự tự tin giao tiếp của Sales dễ trở thành "nói lấn". Mẹo: áp dụng quy tắc "lắng nghe 70%, nói 30%" trong tháng đầu. Khi muốn phản biện, hãy mở đầu bằng câu hỏi.
Lỗi 3: Bỏ qua tài liệu cũ vì thích học qua hội thoại. Mẹo: đặt KPI cá nhân — đọc xong BRD và RTM trước ngày thứ 10. Coi đó là "deal" bạn phải chốt với chính mình.
Lỗi 4: Không xây buddy/mentor relationship. Mẹo: ngay tuần đầu, chủ động hỏi manager "Em có thể nhờ ai làm buddy để hỏi những câu nhỏ không làm phiền cả team không?" Có một người để hỏi giúp bạn học nhanh gấp đôi.
Lỗi 5: Cố tỏ ra biết tất cả về tech. Bạn từ Sales sang, không ai kỳ vọng bạn rành code. Mẹo: nói thẳng "phần kỹ thuật này em chưa rõ, anh giải thích giúp em" — sự trung thực này xây niềm tin nhanh hơn việc giả vờ hiểu.
Mẹo vàng cho ex-Sales: Biến mỗi cuộc trò chuyện thành cơ hội elicitation. Bản năng "đặt câu hỏi mở để hiểu khách hàng" của bạn chính là kỹ năng elicitation cốt lõi của BA — chỉ là giờ "khách hàng" của bạn là stakeholder nội bộ và dev. Đây là lợi thế mà ít người chuyển ngành nào có được.
Bài tập thực hành
- Lập roadmap 30-60-90 cá nhân. Tạo một bảng (Google Sheet) với 3 cột tương ứng 3 giai đoạn. Với mỗi giai đoạn, viết: 3 mục tiêu chính, 3 hoạt động cụ thể, và 1 chỉ số "biết mình thành công" (ví dụ: "cuối ngày 30 — hoàn thành stakeholder map đầy đủ").
- Soạn bộ câu hỏi 1-on-1 của riêng bạn. Viết ra 5 câu hỏi bạn sẽ dùng trong buổi cà phê với dev, và 5 câu khác dành cho stakeholder business. Yêu cầu: tất cả phải là câu hỏi mở.
- Mô phỏng tình huống "nói lấn". Viết lại một câu khẳng định kiểu Sales — ví dụ "tính năng này làm 3 bước là xong" — thành 3 phiên bản câu hỏi khiêm tốn khác nhau. So sánh cảm giác người nghe.
- Thiết kế checklist đọc tài liệu. Liệt kê 5 loại tài liệu bạn sẽ ưu tiên đọc trong tuần đầu tại công ty mới, kèm thứ tự ưu tiên và lý do.
Tóm tắt
90 ngày đầu làm BA là giai đoạn định hình cả sự nghiệp chuyển ngành của bạn. Với người từ nền Sales/BD, hãy nhớ ba điều cốt lõi:
- Ngày 1–30: Quan sát và Học. Đọc hết tài liệu (BRD, SRS, RTM), thực hiện 1-on-1 có cấu trúc với cả team và 3–5 stakeholder, tham gia mọi ceremony với tâm thế "nói ít, ghi nhiều". Thước đo thành công là hiểu được bao nhiêu, không phải làm được bao nhiêu.
- Ngày 31–60: Đóng góp và Kiểm chứng. Nhận task nhỏ, luôn nhờ review, đối chiếu giả định với tài liệu trước khi viết.
- Ngày 61–90: Sở hữu và Dẫn dắt. Tự chủ một luồng việc, chủ trì một buổi họp, xin feedback chính thức và lập kế hoạch quý tiếp theo.