Bài 57 — Onboarding 90-day plan CS-ex BA Mid

Mở đầu — vì sao bài này quan trọng

Bạn đã đọc bài 39 (30 ngày đầu) và bài 40 (60-90 ngày để trở thành BA độc lập) rồi. Nhưng hai bài đó viết cho người vào vị trí BA Junior/Fresher. Bài 57 này khác về bản chất: nó dành cho người có nền Customer Service (CS) đủ mạnh — thường 3-5 năm, có thể từng là CS Lead, Team Leader hoặc Senior CS — và được tuyển thẳng vào vị trí BA Mid-level (Business Analyst bậc trung).

Đây là tình huống rất thực tế ở Việt Nam. Nhiều bạn CS Lead có domain knowledge sâu, kỹ năng giao tiếp tốt, hiểu khách hàng đến từng ngóc ngách, nên khi phỏng vấn, nhà tuyển dụng "nhìn thấy tiềm năng Mid" và trả offer Mid luôn (thường 18-28 triệu/tháng thay vì mức Junior 12-16 triệu). Nghe thì mừng, nhưng đây chính là cái bẫy kỳ vọng: bạn được trả lương Mid, nghĩa là công ty kỳ vọng bạn hành xử như một BA Mid ngay từ sớm — trong khi kinh nghiệm BA thực tế của bạn gần như bằng 0.

90 ngày đầu quyết định việc bạn có "qua thử việc trong danh dự" hay không. Với Junior, người ta tha thứ cho sự chậm chạp. Với Mid, người ta không tha thứ — họ đo bạn bằng thước đo của một người đã biết việc. Bài này cho bạn một kế hoạch 90 ngày được thiết kế riêng cho nghịch lý đó: kỳ vọng cấp Mid, kinh nghiệm BA cấp Junior, nhưng domain/soft-skill cấp Senior. Chúng ta sẽ biến điểm mạnh CS thành đòn bẩy để bù cho khoảng trống kỹ thuật, và làm điều đó nhanh hơn một BA Junior thông thường.

Khái niệm cốt lõi

90-day plan cho Mid khác Junior ở đâu?

Điểm mấu chốt là tốc độ ramp-up (thời gian bắt nhịp) và mức độ chủ động được kỳ vọng. Hãy so sánh:

Nói cách khác, với vị trí Mid, bạn có ba nhiệm vụ chồng lên nhau trong 90 ngày: (1) học kỹ thuật BA nhanh gấp rưỡi Junior, (2) tận dụng domain/CS insight để tạo giá trị sớm, và (3) định vị bản thân như một người đáng tin để giao việc lớn.

Ba trụ cột của kế hoạch: Credibility, Capability, Contribution

Tôi thường tóm gọn 90 ngày của một ex-CS BA Mid thành ba trụ cột (3C):

Credibility (Uy tín) — Đây là thứ bạn phải xây trước, vì với Mid, người ta cho bạn "hạn mức tín nhiệm" ban đầu rồi quan sát xem bạn có xứng đáng không. Uy tín của ex-CS đến từ domain: bạn biết khách hàng thật sự đau ở đâu, biết edge case nào hay xảy ra, biết quy trình nào đang gãy. Đây là thứ một BA "sách vở" không có.

Capability (Năng lực kỹ thuật) — Đây là khoảng trống lớn nhất và nguy hiểm nhất: elicitation có cấu trúc, viết requirement/user story đạt chuẩn team, đọc data, mô hình hóa quy trình, dùng công cụ (Jira, Confluence, Figma...). Bạn phải lấp nó một cách có hệ thống, không để "hội chứng kẻ mạo danh" (imposter syndrome) làm bạn giấu dốt.

Contribution (Đóng góp thấy được) — Đến ngày 60-90, bạn phải có ít nhất 1-2 deliverable mang tên mình mà team công nhận. Với Mid, "hoàn thành onboarding" không đủ; bạn phải để lại dấu vết giá trị.

Bản đồ 3 giai đoạn (0-30, 30-60, 60-90)

• Giai đoạn 1 (Ngày 0-30) — Absorb & Anchor: Hấp thụ context nhanh, neo uy tín bằng CS insight, nhưng khiêm tốn. Mục tiêu: hiểu domain sản phẩm, hệ thống, team, và tìm ra 1 initiative để dẫn dắt.
• Giai đoạn 2 (Ngày 30-60) — Lead a slice: Chính thức cầm một mảng việc nhỏ trọn vẹn, chứng minh capability. Đây là giai đoạn Mid phải "ramp xong".
• Giai đoạn 3 (Ngày 60-90) — Own & Scale: Sở hữu một mảng lớn hơn, làm việc độc lập với stakeholder, và bắt đầu tạo ảnh hưởng lên cách team làm việc.

Tình huống thực tế

Ví dụ 1: Chị Ngọc — CS Lead sàn TMĐT chuyển sang BA Mid, và cái bẫy "biết quá nhiều"

Chị Ngọc từng là CS Lead 4 năm tại một sàn thương mại điện tử tầm trung ở TP.HCM (giả định: khoảng 200 nhân sự). Chị được tuyển vào team Product với vai trò BA Mid, lương 24 triệu, cao hơn hẳn mức CS Lead cũ (16 triệu). Tháng đầu, chị hào hứng vì thấy mình biết mọi thứ về khách hàng — chị nhảy vào mọi cuộc họp và liên tục nói "khách hàng sẽ không thích cái này", "cái này bên CS xử lý tay hoài".

Vấn đề: đến tuần thứ 5, Product Manager kéo chị ra nói chuyện riêng. Team thấy chị "phản biện nhiều nhưng không đưa được yêu cầu viết ra giấy". Chị có insight nhưng chưa biết chuyển insight thành requirement có cấu trúc — không có acceptance criteria, không có luồng nghiệp vụ vẽ ra, chỉ có ý kiến bằng lời.

Diễn giải: Đây là lỗi kinh điển của ex-CS Mid. Domain knowledge làm bạn tự tin quá sớm, và bạn nói bằng "ngôn ngữ CS" (cảm tính, giai thoại) thay vì "ngôn ngữ BA" (có cấu trúc, có bằng chứng, có đặc tả). Chị Ngọc điều chỉnh bằng cách: mỗi khi định phát biểu một insight, chị tự ép mình viết nó thành 1 dòng problem statement + 1 gợi ý acceptance criteria trước khi mở miệng. Đến ngày 60, chị đã lead được feature "cải thiện luồng hoàn tiền" — đúng mảng chị hiểu sâu nhất từ thời CS — và deliver một bộ user story được team QA khen là "viết edge case đầy đủ hiếm thấy".

Bài học: Insight chỉ có giá trị khi được đóng gói thành sản phẩm BA. Domain là đòn bẩy, không phải cái cớ để bỏ qua kỹ thuật.

Ví dụ 2: Anh Tuấn — ngân hàng số, ramp nhanh nhờ chọn đúng "initiative đầu tiên"

Anh Tuấn làm CS/support tổng đài 5 năm tại mảng thẻ của một ngân hàng, rồi được nhận vào team chuyển đổi số với vai trò BA Mid. Anh làm một việc rất khôn ngoan trong 2 tuần đầu: thay vì cố học hết mọi hệ thống, anh xin PM cho phân tích backlog ticket khiếu nại 6 tháng gần nhất — thứ anh đọc nhanh gấp 5 lần người khác vì anh từng sống trong đó.

Anh phát hiện 34% ticket liên quan đến một bước xác thực OTP gây rớt giao dịch. Anh gom lại thành một mini-report có số liệu, và đề xuất đây là initiative đầu tiên mình muốn dẫn. PM đồng ý ngay vì đề xuất có bằng chứng, không phải cảm tính.

Diễn giải: Anh Tuấn ramp xong trong khoảng 45 ngày — nhanh hơn cả kỳ vọng 60 ngày cho Mid. Bí quyết là chọn "cửa vào" nơi lợi thế CS lớn nhất và độ rủi ro thấp nhất. Anh không cố tỏ ra giỏi kỹ thuật ngay; anh dùng data support (thứ anh thạo) để giành quyền dẫn một việc, rồi vừa làm vừa học phần kỹ thuật (viết BRD, vẽ luồng) trên chính việc đó.

Bài học: "Initiative đầu tiên" nên nằm ở giao điểm giữa (a) chỗ CS insight của bạn mạnh nhất và (b) chỗ team đang thực sự đau. Đó là con đường ramp nhanh nhất.

Ví dụ 3: Chị Linh — vấp vì bỏ qua bước xây quan hệ stakeholder

Chị Linh, ex-CS tại một công ty SaaS logistics, giỏi kỹ thuật hơn hai bạn trên — chị tự học BABOK, viết user story tốt. Nhưng 90 ngày của chị suýt trượt vì lý do bất ngờ: chị làm việc như một "cỗ máy tạo tài liệu", đầu cắm vào Confluence, ít nói chuyện với dev và QA. Đến sprint review, dev phàn nàn requirement của chị "đúng nhưng thiếu context, phải hỏi lại nhiều".

Diễn giải: Trớ trêu là điểm mạnh CS của chị — quan hệ con người — lại bị chị bỏ quên vì mải chứng minh năng lực kỹ thuật. Ở cấp Mid, stakeholder relationship không phải "nice to have" mà là KPI ngầm. Chị sửa bằng cách đặt lịch cà phê 1-1 với từng dev và QA trong tuần 7-8, hỏi họ thích nhận requirement theo format nào. Chỉ vậy thôi mà chất lượng cộng tác tăng vọt.

Bài học: Đừng để việc "chứng minh mình biết kỹ thuật" làm bạn vứt bỏ chính siêu năng lực CS của mình. Với Mid, quan hệ làm việc phải hình thành trong 60 ngày đầu, không để đến 90.

Hướng dẫn từng bước

Giai đoạn 1 — Ngày 0-30: Absorb & Anchor

• Tuần 1 — Lập bản đồ context. Xin ba thứ ngay: (a) sơ đồ hệ thống/sản phẩm hiện tại, (b) tài liệu quy trình team (Definition of Ready/Done, template requirement), (c) quyền đọc backlog và dữ liệu ticket/support cũ. Đọc backlog support trước — đây là chỗ bạn nhanh nhất.
• Tuần 1-2 — Lập "stakeholder map". Liệt kê PM, dev lead, QA, design, và stakeholder nghiệp vụ. Đặt lịch 1-1 làm quen với từng người (15-20 phút), hỏi họ: "Anh/chị kỳ vọng gì ở một BA tốt trong team này?". Ghi lại.
• Tuần 2-3 — Chọn "initiative đầu tiên". Tìm giao điểm giữa CS insight mạnh và pain thật của team (như anh Tuấn). Chuẩn bị một mini-analysis có số liệu để đề xuất.
• Tuần 3-4 — Học template chuẩn của team bằng cách bắt chước. Lấy 2-3 tài liệu BA cũ được đánh giá tốt, mổ xẻ cấu trúc, và viết thử một bản theo đúng khuôn đó cho một task nhỏ. Đừng sáng tạo format riêng lúc này.
• Chốt ngày 30: Bạn hiểu domain sản phẩm, có stakeholder map, đã đề xuất được 1 initiative và được giao chính thức.

Giai đoạn 2 — Ngày 30-60: Lead a slice

• Cầm trọn một mảng việc nhỏ end-to-end: từ elicitation → viết requirement/user story có acceptance criteria → làm rõ với dev/QA → theo đến khi được dev nhận. Đây là bài kiểm tra "ramp xong" cho Mid.
• Ép mình chuyển insight thành đặc tả: áp dụng thói quen của chị Ngọc — mọi ý kiến đều phải có problem statement + bằng chứng + gợi ý AC trước khi phát biểu trong họp.
• Chủ động xin feedback giữa chặng: cuối tuần 6, hỏi PM thẳng: "Nếu chấm em theo chuẩn Mid, em đang ở đâu, thiếu gì?". Người Mid chủ động xin thước đo; người Junior chờ bị đánh giá.
• Xây quan hệ cộng tác (đừng như chị Linh): cà phê 1-1 với dev/QA, hỏi format họ thích, hiểu nhịp làm việc của họ.
• Chốt ngày 60: một deliverable mang tên bạn đã đi vào sprint, quan hệ làm việc với team đã hình thành, PM tin bạn hiểu việc.

Giai đoạn 3 — Ngày 60-90: Own & Scale

• Nhận một mảng lớn hơn hoặc phức tạp hơn, làm việc trực tiếp với stakeholder nghiệp vụ mà không cần PM cầm tay.
• Bắt đầu tạo ảnh hưởng lên cách làm việc: đề xuất một cải tiến nhỏ dựa trên nền CS của bạn — ví dụ một cách gom "voice of customer" vào backlog đều đặn (liên hệ nhẹ tới bài 33), hoặc một checklist edge case.
• Chuẩn bị "bằng chứng qua thử việc": tổng hợp 2-3 deliverable + feedback tích cực để dùng trong buổi review cuối kỳ thử việc.
• Đặt mục tiêu 6 tháng tiếp theo cùng PM: bạn muốn tiến tới mảng nào, học kỹ năng kỹ thuật nào tiếp (SQL sâu hơn, BPMN, v.v.).

Lỗi thường gặp & mẹo

• Lỗi "biết quá nhiều nói quá sớm": dùng domain để phản biện liên tục nhưng không đóng gói thành sản phẩm BA. Mẹo: quy tắc "no insight without a spec" — không phát biểu insight nếu chưa gắn được với problem statement + hướng đặc tả.
• Lỗi giấu khoảng trống kỹ thuật vì sợ mất mặt Mid: imposter syndrome khiến bạn gật đầu giả vờ hiểu Jira/BPMN/SQL. Mẹo: tách bạch — tự tin về domain, cầu thị về kỹ thuật. Câu nói an toàn: "Về nghiệp vụ em nắm rõ, phần này em muốn học cách team mình đang làm để làm đúng chuẩn."
• Lỗi quên stakeholder relationship: cắm đầu vào tài liệu, bỏ quên chính siêu năng lực CS. Mẹo: đặt KPI cá nhân — 60 ngày đầu phải có quan hệ làm việc thật với ít nhất PM + 1 dev + 1 QA.
• Lỗi chọn sai initiative đầu tiên: chọn việc quá lớn/rủi ro cao để "chứng tỏ", rồi sa lầy. Mẹo: chọn việc nhỏ, thắng chắc, nơi CS insight của bạn tạo lợi thế rõ.
• Lỗi so mình với BA "gốc": tự ti vì chưa biết vẽ ERD đẹp bằng đồng nghiệp. Mẹo: nhớ rằng bạn được tuyển vì góc nhìn khách hàng — đó là thứ họ thiếu. Bù kỹ thuật dần, đừng đánh mất bản sắc.
• Mẹo tăng tốc chung: viết "learning log" mỗi tuần — 3 điều học được, 1 điều còn lơ mơ. Mang cái "lơ mơ" đi hỏi. Ex-CS ramp nhanh nhất là người biến sự tò mò thành câu hỏi có cấu trúc.

Bài tập thực hành

• Vẽ kế hoạch 90 ngày của riêng bạn theo khung 3 giai đoạn (0-30, 30-60, 60-90) và 3 trụ cột (Credibility, Capability, Contribution). Với mỗi giai đoạn viết 2-3 mục tiêu đo được. Lưu ý mốc "ramp xong ngày 60".
• Liệt kê 5 điểm mạnh CS của bạn và ghép mỗi điểm với một cơ hội tạo giá trị BA cụ thể trong 90 ngày (ví dụ: "thuộc lòng edge case hoàn tiền → dẫn feature cải thiện luồng refund").
• Soạn "initiative đầu tiên" giả định: dựa trên dữ liệu support bạn từng tiếp xúc, viết một mini-analysis nửa trang gồm: vấn đề, số liệu chứng minh, tác động, đề xuất bạn muốn dẫn. Đây là kịch bản để bạn thực chiến trong tuần 2-3.
• Viết ba câu tự bảo vệ khi gặp khoảng trống kỹ thuật — những câu vừa thành thật vừa giữ được uy tín Mid, để bạn không rơi vào phản xạ giấu dốt.
• Thiết kế một "stakeholder map" mẫu cho môi trường bạn sắp/đang vào, và soạn 3 câu hỏi bạn sẽ dùng trong buổi 1-1 làm quen.

Tóm tắt

Onboarding 90 ngày cho một ex-CS vào vai BA Mid không giống Junior: bạn được kỳ vọng ramp xong trong khoảng 60 ngày, dẫn dắt một initiative từ ngày 30, và xây được quan hệ stakeholder thật trong 60 ngày đầu. Nghịch lý bạn phải giải là "lương Mid, kinh nghiệm BA Junior, domain/soft-skill Senior".

Hãy đi theo ba trụ cột 3C — Credibility (dùng domain CS để neo uy tín sớm), Capability (lấp khoảng trống kỹ thuật một cách có hệ thống, không giấu dốt), Contribution (để lại 1-2 deliverable mang tên mình) — trải trên ba giai đoạn Absorb & Anchor, Lead a slice, Own & Scale.

Ba bài học lớn từ Ngọc, Tuấn và Linh: (1) insight chỉ có giá trị khi đóng gói thành đặc tả BA; (2) chọn đúng "initiative đầu tiên" ở giao điểm CS-mạnh và team-đau sẽ giúp bạn ramp nhanh nhất; (3) đừng để việc chứng minh kỹ thuật làm bạn vứt bỏ siêu năng lực quan hệ vốn có của CS. Làm đúng ba điều đó, bạn không chỉ qua thử việc — bạn qua nó với tư thế của một người được giao việc lớn.