Mở đầu — vì sao bài này quan trọng
Bạn đã học xong rất nhiều: bạn hiểu requirements types, biết viết user story chuẩn INVEST, nắm BPMN, biết làm gap analysis, đã có CV và đi qua mock interview. Nhưng có một sự thật phũ phàng mà ít ai nói với bạn: 90 ngày đầu tiên ở vai trò BA mới quyết định 80% việc bạn có trụ được lâu dài hay không.
Đây không phải lời dọa. Trong tuyển dụng, hầu hết hợp đồng lao động Việt Nam có thời gian thử việc 2 tháng (60 ngày), và nhiều công ty công nghệ đánh giá chính thức ở mốc 90 ngày. Với một người chuyển ngành từ Dev sang BA, áp lực còn lớn hơn người BA "thuần": cả team đang ngầm tự hỏi "ông dev này làm BA có ổn không, hay lại nhảy vào sửa code rồi bỏ bê tài liệu?". Bạn vừa phải chứng minh năng lực BA, vừa phải xóa đi định kiến về xuất thân.
Tin tốt là: một kế hoạch 90 ngày rõ ràng biến giai đoạn hỗn loạn nhất thành giai đoạn có kiểm soát. Thay vì lăn xả vô định rồi kiệt sức, bạn đi theo lộ trình Hiểu môi trường → Đóng góp có kiểm soát → Tự chủ và tạo dấu ấn. Bài này cho bạn đúng kế hoạch đó, được thiết kế riêng cho người có nền tảng kỹ thuật. Đây là bài về cách bạn sống sót và tỏa sáng trong 3 tháng đầu — khác hẳn các bài về kỹ thuật BA, vì ở đây trọng tâm là chiến lược hòa nhập, xây niềm tin và quản lý kỳ vọng.
Khái niệm cốt lõi
90-day plan là gì và tại sao chia làm ba pha
90-day onboarding plan (kế hoạch hòa nhập 90 ngày) là một bản đồ hành động chia ba giai đoạn, mỗi giai đoạn 30 ngày, với mục tiêu và "đầu ra" (deliverable) rõ ràng. Mô hình kinh điển được Michael Watkins đề xuất trong cuốn The First 90 Days và được giới quản lý dùng phổ biến:
- Ngày 1–30 — LEARN (Hiểu): Mục tiêu là hấp thụ. Bạn không tạo ra giá trị lớn ngay, mà xây nền hiểu biết về sản phẩm, domain nghiệp vụ, con người và quy trình. Đây là lúc đặt câu hỏi mà không sợ "ngốc".
- Ngày 31–60 — CONTRIBUTE (Đóng góp có kiểm soát): Bắt đầu cầm việc thật nhưng có người kèm. Bạn viết tài liệu, facilitate họp nhỏ, lấy requirement cho một module dưới sự giám sát của BA senior hoặc PM.
- Ngày 61–90 — OWN (Tự chủ): Bạn sở hữu trọn vẹn ít nhất một mảng việc từ đầu đến cuối, được tin tưởng giao tiếp trực tiếp với stakeholder, và bắt đầu để lại dấu ấn cải tiến.
Vì sao người từ Dev dễ vấp ở pha LEARN
Dev được huấn luyện để giải quyết vấn đề nhanh. Bản năng đó cực kỳ nguy hiểm trong 30 ngày đầu làm BA. Bạn nhìn vào một quy trình nghiệp vụ rối rắm và lập tức nghĩ "cái này chỉ cần thêm một bảng trạng thái là xong". Nhưng bạn chưa hiểu vì sao nó được thiết kế rối như vậy — có thể vì một quy định pháp lý, một thói quen của khách hàng lớn, hay một sự cố trong quá khứ. Nhảy vào giải pháp quá sớm (solution-jumping) khiến stakeholder mất niềm tin: "anh này chưa hiểu gì đã phán".
Vì vậy nguyên tắc vàng của pha LEARN với dev-turned-BA là: lắng nghe gấp đôi nói, hỏi "tại sao" trước khi nghĩ "làm thế nào".
Ba loại "vốn" cần tích lũy
Trong 90 ngày, bạn cần xây ba loại vốn song song:
- Vốn kiến thức (knowledge capital): hiểu sản phẩm, domain, hệ thống.
- Vốn quan hệ (relationship capital): dev tin bạn không "ngáng đường", business tin bạn hiểu nhu cầu của họ, QA tin tài liệu của bạn test được.
- Vốn uy tín (credibility capital): giao đúng hẹn, tài liệu rõ ràng, không gây ra rework.
Quy tắc "quick win" có kiểm soát
Một quick win là một đóng góp nhỏ nhưng hữu hình, tạo ra trong 30–45 ngày đầu, giúp bạn ghi điểm. Với dev-turned-BA, quick win lý tưởng tận dụng lợi thế kỹ thuật: vẽ lại một sequence diagram tích hợp mà cả team đang mơ hồ, làm rõ một API contract đang gây tranh cãi giữa hai team, hoặc dựng một bảng truy vết requirement. Quan trọng: quick win phải nằm trong phạm vi được giao, không phải bạn tự ý "tối ưu" thứ không ai nhờ.
Tình huống thực tế
Tình huống 1 — Minh tại MoMo: ba mươi ngày im lặng đáng giá
Minh, 29 tuổi, từng là backend developer 4 năm (Java/Spring), chuyển sang vai trò BA tại một ví điện tử lớn ở TP.HCM (bối cảnh giống MoMo). Tuần đầu, anh được giao "shadow" chị Hà — một BA senior phụ trách mảng thanh toán hóa đơn.
Minh kể: "Tuần đầu tôi rất ngứa tay. Ngồi đọc tài liệu BRD cũ, tôi thấy logic xử lý timeout giao dịch viết rất lủng củng, và tôi muốn lao vào đề xuất sửa ngay trong buổi họp thứ ba." Chị Hà ngăn lại: "Em ghi vào sổ, đừng nói vội. Cuối tháng mình review."
Đúng một tháng sau, khi đã hiểu rằng cái "lủng củng" đó thực ra là để xử lý các nhà cung cấp điện nước có hệ thống phản hồi cực chậm (có nơi tới 45 giây), Minh mới hiểu thiết kế cũ không hề ngu ngốc. Nhưng anh cũng phát hiện một lỗ hổng thật: tài liệu không hề mô tả trường hợp người dùng đóng app giữa chừng. Đây là quick win của anh — anh bổ sung một sequence diagram cho luồng "giao dịch mồ côi" (orphan transaction) và đề xuất cơ chế đối soát. Đề xuất được duyệt vì nó dựa trên hiểu biết thật, không phải phản xạ dev.
Bài học: 30 ngày "im lặng có chủ đích" không phải lãng phí. Việc ghi nhận quan sát vào sổ thay vì phán xét ngay giúp Minh tránh mất uy tín, và khi anh lên tiếng thì lời nói có trọng lượng.
Tình huống 2 — Lan tại một startup logistics 50 người: vấp vì "code lậu"
Lan chuyển từ frontend dev sang BA tại một startup logistics ở Hà Nội. Ở pha CONTRIBUTE (tháng 2), cô được giao lấy requirement cho tính năng theo dõi đơn hàng. Trong lúc làm việc với team dev, thấy một bug nhỏ ở màn hình tracking, Lan — vốn là dev — tự nhận "để em sửa luôn cho nhanh", rồi tạo một pull request.
Hậu quả: dev lead khó chịu vì có người ngoài team đụng vào codebase không qua quy trình review, còn PM thì lo lắng vì BA "lại đi code thay vì làm tài liệu". Tệ hơn, hôm đó Lan trễ bản FRD đã hứa vì mất thời gian sửa bug. Niềm tin của cả hai phía đều giảm trong một ngày.
Sau buổi 1-1 với mentor, Lan rút ra: vai trò đã đổi thì ranh giới phải đổi. Cô chuyển bug đó thành một ticket mô tả rõ ràng, bàn giao cho dev qua đúng quy trình — và bất ngờ là dev lead lại khen "ticket viết rõ nhất từ trước tới giờ, có cả bước tái hiện". Đó mới là quick win đúng đắn của một BA có nền dev.
Bài học: Lợi thế kỹ thuật của bạn nên thể hiện qua chất lượng tài liệu và khả năng giao tiếp với dev, không phải qua việc giành làm việc của dev. Vượt ranh giới vai trò trong 90 ngày đầu là một trong những cách nhanh nhất phá hỏng cả vốn quan hệ lẫn vốn uy tín.
Tình huống 3 — Tuấn tại một công ty outsourcing cho khách Nhật: pha OWN và cú "demo nội bộ"
Tuấn, cựu dev .NET, vào làm Technical BA cho một dự án core banking outsourcing tại Đà Nẵng, khách hàng là một ngân hàng Nhật. Hai tháng đầu anh đi đúng lộ trình: tháng 1 đọc tài liệu và học domain ngân hàng, tháng 2 viết use case specification cho module mở tài khoản dưới sự kèm cặp.
Đến tháng thứ 3 (pha OWN), anh được giao chủ trì làm rõ requirement cho luồng eKYC. Thay vì chờ đến cuối sprint mới có tài liệu, Tuấn chủ động tổ chức một buổi "walkthrough" 30 phút giữa kỳ, trình bày BPMN luồng eKYC trước cả BA lead, dev và đại diện QA. Buổi đó phát hiện sớm một hiểu lầm: phía dev tưởng OTP gửi qua SMS, trong khi yêu cầu của khách Nhật là xác thực qua app ngân hàng. Phát hiện sớm này tiết kiệm khoảng hai tuần rework.
Bài học: Ở pha OWN, sự chủ động facilitate (điều phối, tạo không gian để mọi người thống nhất sớm) chính là thứ phân biệt BA giỏi với người chỉ "viết tài liệu". Tuấn tận dụng đúng lợi thế dev — đọc được kiến trúc kỹ thuật — để dẫn dắt một cuộc đối thoại business-tech, đúng vai trò cốt lõi của BA.
Hướng dẫn từng bước
Dưới đây là khung 90 ngày chi tiết. Hãy điều chỉnh theo bối cảnh công ty bạn, nhưng giữ nguyên tinh thần ba pha.
Tháng 1 (Ngày 1–30) — HIỂU MÔI TRƯỜNG
Tuần 1 — Shadow và đọc:
- Xin được "shadow" một BA senior hoặc PM: ngồi cùng các buổi họp, quan sát cách họ đặt câu hỏi, viết note.
- Đọc tài liệu dự án cũ: BRD, FRD, SRS, user story đã đóng, biên bản họp gần nhất. Lập một danh sách "câu hỏi tại sao" thay vì danh sách "đề xuất sửa".
- Lập sơ đồ stakeholder sơ bộ: ai là ai, ai quyết định gì.
- Cài đặt và làm chủ tool stack BA của công ty (Jira/Confluence, Notion, Figma, Draw.io...). Tự tạo một trang Confluence "Onboarding notes" của riêng bạn.
- Join standup hằng ngày ở chế độ observe: nghe để hiểu nhịp làm việc, thuật ngữ nội bộ, các điểm nghẽn.
- Lên lịch 1-1 (cà phê 30 phút) với 3–5 người chủ chốt: dev lead, QA lead, một người phía business, mentor. Mục tiêu là xây quan hệ, không phải đòi việc.
- Nhận một việc nhỏ có giám sát: cập nhật một đoạn tài liệu, viết lại một acceptance criteria, hỗ trợ ghi biên bản họp.
- Bắt đầu vẽ lại một quy trình AS-IS mà bạn đã hiểu, để kiểm tra hiểu biết của mình với người có kinh nghiệm.
- Trình bày lại hiểu biết của bạn về sản phẩm/domain cho mentor để được hiệu chỉnh.
- Hoàn thành một quick win nhỏ tận dụng nền kỹ thuật (sequence diagram, làm rõ API contract, bảng truy vết).
- Đặt mục tiêu rõ ràng cho tháng 2 cùng quản lý.
Tháng 2 (Ngày 31–60) — ĐÓNG GÓP CÓ KIỂM SOÁT
- Lead một mảng nhỏ: Chủ trì lấy requirement cho một module/tính năng cụ thể, từ elicitation đến viết user story/FRD, nhưng có BA senior review trước khi phát hành.
- Facilitate họp nhỏ: Tự điều phối một buổi requirement workshop hoặc refinement cho phần việc của bạn.
- Vòng phản hồi chặt: Mỗi tài liệu bạn viết, xin review và ghi lại các lỗi để không lặp lại. Đây là lúc bạn xây vốn uy tín.
- Giữ ranh giới vai trò: Tuyệt đối không tự ý sửa code; chuyển mọi phát hiện kỹ thuật thành ticket/tài liệu chất lượng cao.
Tháng 3 (Ngày 61–90) — TỰ CHỦ VÀ TẠO DẤU ẤN
- Sở hữu trọn một luồng: Cầm một feature từ elicitation đến UAT, giao tiếp trực tiếp với stakeholder mà không cần "phiên dịch" qua người khác.
- Chủ động facilitate: Tổ chức walkthrough giữa kỳ để phát hiện sớm hiểu lầm (như tình huống của Tuấn).
- Một cải tiến nhỏ: Đề xuất một cải thiện quy trình dựa trên những gì bạn quan sát được trong 2 tháng — ví dụ một template tài liệu, một cách truy vết requirement.
- Tự đánh giá 90 ngày: Trước buổi review chính thức, viết một bản tự tổng kết: đã giao được gì, học được gì, mục tiêu 90 ngày tiếp theo.
Lỗi thường gặp & mẹo
Lỗi 1 — Solution-jumping vì phản xạ dev. Thấy vấn đề là muốn sửa ngay. Mẹo: dùng "sổ tay quan sát". Mọi ý tưởng cải tiến trong tháng 1 đều ghi vào sổ, không nói ra ngay. Cuối tháng review lại — bạn sẽ thấy phần lớn ý tưởng ban đầu là do chưa hiểu đủ context.
Lỗi 2 — Đụng vào code. Như tình huống của Lan. Mẹo: tự đặt luật "BA không commit code trong 90 ngày đầu". Chuyển mọi đóng góp kỹ thuật thành tài liệu/ticket xuất sắc — đó mới là cách dev mới thực sự ghi điểm ở vai trò BA.
Lỗi 3 — Im lặng quá mức vì sợ sai. Ngược lại với lỗi 1, một số người dev hướng nội co lại hoàn toàn, không hỏi gì, dẫn đến hiểu sai âm thầm. Mẹo: đặt mục tiêu "mỗi ngày hỏi ít nhất một câu hỏi tại sao" trong tháng đầu. Hỏi thông minh được đánh giá cao hơn im lặng.
Lỗi 4 — Bỏ qua phía business, chỉ thân với dev. Vì thoải mái với dev, bạn vô tình bỏ bê việc xây quan hệ với stakeholder business. Mẹo: chủ động đặt lịch 1-1 với ít nhất 2 người phía nghiệp vụ ngay trong tuần 2.
Lỗi 5 — Không có mục tiêu đo được. "Cố gắng hết sức" không phải mục tiêu. Mẹo: cuối mỗi tháng, chốt với quản lý 2–3 deliverable cụ thể cho tháng sau (ví dụ: "tháng 2 hoàn thành FRD module thanh toán, được duyệt với dưới 3 vòng sửa").
Mẹo vàng: Lập một "kênh phản hồi nhanh" với mentor — 15 phút mỗi tuần. Một câu hỏi đơn giản: "Tuần này em có làm gì khiến anh/chị lo không?" sẽ giúp bạn phát hiện vấn đề trước khi nó vào bản đánh giá chính thức.
Bài tập thực hành
- Soạn 90-day plan cá nhân hóa. Lấy khung ba pha ở trên và viết lại thành kế hoạch riêng cho công ty/vị trí bạn đang (hoặc sắp) làm. Mỗi tuần điền: mục tiêu, hoạt động, deliverable, và "người cần kết nối". Trình bày trên một trang Confluence/Notion.
- Danh sách 10 câu hỏi tại sao. Giả định bạn vừa nhận một dự án mới. Viết 10 câu hỏi "tại sao" mà bạn sẽ hỏi trong tuần đầu — không câu nào được chứa đề xuất giải pháp. Đây là bài tập rèn phản xạ lắng nghe thay vì giải quyết.
- Thiết kế một quick win. Dựa trên nền kỹ thuật của bạn, mô tả một quick win cụ thể bạn có thể tạo ra trong 30–45 ngày đầu (ví dụ: vẽ lại một sequence diagram tích hợp, dựng bảng truy vết requirement). Ghi rõ nó tận dụng lợi thế dev thế nào và vì sao nó nằm trong phạm vi được giao.
- Phân tích tình huống Lan. Viết một đoạn 150 từ trả lời: nếu là Lan và phát hiện bug ở tháng 2, bạn sẽ xử lý thế nào để vừa thể hiện được giá trị, vừa không vượt ranh giới vai trò?
Tóm tắt
- 90 ngày đầu quyết định phần lớn sự thành công của hành trình Dev → BA. Với người chuyển ngành, đây còn là giai đoạn xóa định kiến về xuất thân.
- Chia hành trình thành ba pha 30 ngày: LEARN (hiểu) → CONTRIBUTE (đóng góp có kiểm soát) → OWN (tự chủ và tạo dấu ấn).
- Tích lũy song song ba loại vốn: kiến thức, quan hệ và uy tín. Lợi thế dev mạnh ở vốn kiến thức và quan hệ với dev team; cần chủ động bù đắp quan hệ với business và uy tín giao việc đúng hẹn.
- Cạm bẫy lớn nhất của dev-turned-BA: solution-jumping và đụng vào code. Hãy thể hiện lợi thế kỹ thuật qua chất lượng tài liệu và khả năng facilitate, không phải qua việc giành làm việc của dev.
- Một quick win đúng lúc, nằm trong phạm vi, tận dụng nền kỹ thuật, cộng với mục tiêu đo được mỗi tháng và một kênh phản hồi đều đặn với mentor — đó là công thức để 90 ngày đầu trở thành bệ phóng thay vì bãi mìn.