Mở đầu — vì sao bài này quan trọng
Khi mới chuyển từ Marketing sang BA, ba câu hỏi khiến nhiều người hoang mang nhất không phải là "BA làm gì" (bài 2 đã trả lời), mà là: "Tôi phải dùng phần mềm gì hằng ngày? Một 'sprint' diễn ra như thế nào? Và tôi đứng ở đâu trong cái guồng quay đó?". Đây chính xác là phần mà người làm Marketing thường bị sốc nhất khi bước chân vào đội phát triển sản phẩm — không phải vì khó, mà vì nó là một ngôn ngữ vận hành hoàn toàn mới.
Tin tốt là: nếu bạn từng chạy campaign theo từng đợt, từng dùng Trello hoặc Asana để quản lý lịch content, từng họp weekly review để xem chỉ số và điều chỉnh ngân sách quảng cáo, thì bạn đã có sẵn 60% tư duy cần thiết cho Agile. Bài này sẽ giúp bạn nối phần còn lại: làm chủ bộ công cụ (tool stack) thực tế mà một BA dùng mỗi ngày, và hiểu quy trình Agile/Scrum đủ để tự tin tham gia ngay từ tuần đầu đi làm.
Lưu ý: bài này tập trung vào công cụ và quy trình vận hành thường nhật của BA. Phần kỹ thuật viết User Story chi tiết, wireframe, hay phân tích dữ liệu sẽ được đào sâu ở các bài sau. Ở đây, mục tiêu là cho bạn một bản đồ tổng thể để không bị lạc trong ngày đầu tiên.
Khái niệm cốt lõi
Tool stack của một BA gồm những gì
Hãy hình dung công cụ của BA chia làm bốn nhóm, tương ứng bốn việc bạn làm mỗi ngày:
1. Quản lý công việc và backlog — Jira (hoặc Azure DevOps, ClickUp). Đây là "trái tim" của đội Agile. Mọi yêu cầu (requirement) được chẻ nhỏ thành các ticket: Epic (mục tiêu lớn), Story (một tính năng nhỏ có giá trị cho người dùng), Task và Bug. BA thường là người tạo và chăm sóc các Story này. Nếu bạn từng quản lý một bảng Kanban content trên Trello — mỗi thẻ là một bài viết cần làm — thì Jira chính là phiên bản "công nghiệp hóa" của thói quen đó, với thêm điểm số, sprint và trạng thái.
2. Tài liệu và tri thức — Confluence (hoặc Notion, Google Docs). Nơi BA lưu tài liệu phân tích, biên bản họp, sơ đồ quy trình, quyết định thiết kế. Marketer vốn quen viết content brief, campaign plan — kỹ năng viết mạch lạc đó chuyển thẳng sang viết tài liệu BA.
3. Trực quan hóa và thiết kế giao tiếp — Figma và Miro. Figma để xem (và đôi khi vẽ phác) giao diện; Miro để vẽ sơ đồ luồng người dùng (user flow), brainstorm cùng team, dán sticky note trong workshop. Người làm Marketing từng dựng landing page mockup hay vẽ customer journey trên Canva/Miro sẽ thấy đây là sân nhà.
4. Giao tiếp và họp — Slack/Microsoft Teams và Google Meet/Zoom. Tưởng đơn giản nhưng cực kỳ quan trọng: BA là cầu nối, nên phần lớn giá trị bạn tạo ra đi qua tin nhắn và cuộc họp.
Bạn không cần thành thạo cả bốn nhóm trong ngày đầu. Thực tế, 80% thời gian tuần đầu của một BA junior xoay quanh Jira và Confluence.
Agile là gì — giải thích cho dân Marketing
Agile không phải một phần mềm, mà là một triết lý làm việc: thay vì lập kế hoạch khổng lồ cho 12 tháng rồi mới giao sản phẩm (kiểu Waterfall — thác nước), đội Agile làm theo từng vòng lặp ngắn 1–4 tuần, mỗi vòng giao một phần nhỏ dùng được, rồi học hỏi và điều chỉnh.
So sánh dễ hiểu cho marketer: Waterfall giống như bỏ ra 6 tháng làm một TVC hoành tráng rồi mới tung ra — nếu sai thông điệp, bạn mất trắng. Agile giống chạy performance ads: bạn tung một biến thể, đo chỉ số sau vài ngày, tắt cái dở, nhân cái tốt, lặp lại. Triết lý "thử nhanh — học nhanh — điều chỉnh" này bạn đã sống với nó hằng ngày trong Marketing.
Scrum — khung Agile phổ biến nhất
Scrum là cách triển khai Agile cụ thể nhất ở Việt Nam. Bạn cần nắm bốn "nghi thức" (ceremony) và ba vai trò:
Sprint: một chu kỳ làm việc cố định, thường 2 tuần. Đầu sprint cam kết làm gì, cuối sprint giao kết quả.
Bốn ceremony trong một sprint 2 tuần:
- Sprint Planning (đầu sprint): team chọn các Story sẽ làm trong sprint này. BA phải đảm bảo các Story đã rõ ràng để team ước lượng được.
- Daily Standup (mỗi sáng, 15 phút): mỗi người nói hôm qua làm gì, hôm nay làm gì, có vướng gì không. Ngắn, đứng họp cho nhanh.
- Sprint Review (cuối sprint): team demo sản phẩm cho stakeholder. Giống buổi báo cáo kết quả campaign.
- Sprint Retrospective (cuối sprint): team nhìn lại cách làm việc — cái gì tốt, cái gì cần cải thiện. Giống buổi rút kinh nghiệm sau một mùa sale.
Vị trí thực tế của BA trong Scrum
Ở phần lớn công ty Việt Nam, BA hoạt động như một "cánh tay phải" của Product Owner, hoặc đôi khi kiêm luôn vai PO ở các công ty nhỏ. Cụ thể, BA là người:
- Chuẩn bị và làm rõ (refine) các Story trong backlog trước Sprint Planning, để buổi planning không bị tắc.
- Trả lời câu hỏi của dev khi họ code giữa sprint ("logic ở trường hợp này thế nào?").
- Tham gia kiểm thử nghiệm thu (UAT) cuối sprint để xác nhận tính năng đúng yêu cầu.
- Làm cầu nối giữa stakeholder kinh doanh và đội kỹ thuật.
Tình huống thực tế
Tình huống 1: Marketer bối rối trong tuần đầu tại một startup fintech ở TP.HCM
Chị Linh, 4 năm làm Digital Marketing cho một agency, được nhận vào vị trí BA Junior tại một startup ví điện tử ở quận 1. Ngày đầu, chị được thêm vào một board Jira có hơn 200 ticket, với những trạng thái lạ hoắc: "Ready for Dev", "In Review", "Blocked". Chị hoảng vì tưởng phải làm hết.
Mentor của chị chỉ ra một điều đơn giản: chị chỉ cần quan tâm các Story đang ở cột "To Refine" — những thứ chưa rõ ràng và cần BA làm rõ. Chị lọc Jira theo assignee = Linh và status = To Refine, lập tức từ 200 ticket xuống còn 6. Trong hai ngày, chị xử lý gọn 6 cái đó bằng cách viết rõ tiêu chí chấp nhận (acceptance criteria) và đính kèm link Figma.
Bài học: Đừng bị "ngợp" bởi cả board. Một BA giỏi biết dùng bộ lọc (filter) của Jira để cô lập đúng phần việc của mình. Kỹ năng phân khúc (segmentation) mà bạn dùng để lọc tệp khách hàng trong Marketing chính là kỹ năng lọc backlog ở đây.
Tình huống 2: Sprint Review cứu một tính năng ở công ty e-commerce
Một đội sản phẩm tại một sàn thương mại điện tử (giả định kiểu Tiki/Shopee) đang xây tính năng "gợi ý sản phẩm liên quan" ở trang giỏ hàng. BA — anh Hoàng, vốn từ nền Growth Marketing — viết Story rất kỹ về mặt logic, dev code đúng y. Nhưng đến Sprint Review, khi demo cho team Kinh doanh, một trưởng phòng buột miệng: "Sao gợi ý toàn sản phẩm đắt tiền hơn? Khách đang muốn thanh toán nhanh mà bị làm phiền."
Vì làm theo Scrum với vòng lặp 2 tuần, vấn đề lộ ra sớm — trước khi tính năng lên production. Team ghi nhận, sprint sau điều chỉnh thuật toán gợi ý sang sản phẩm bổ trợ giá thấp (mua kèm). Kết quả A/B test sau đó cho thấy tỷ lệ thêm vào giỏ tăng 8%.
Bài học: Sprint Review không phải thủ tục hình thức. Nó là cơ chế "feedback loop" giống hệt việc bạn đọc chỉ số campaign sau 3 ngày để tắt cái không hiệu quả. Là BA, bạn phải chủ động kéo đúng stakeholder vào buổi review — đúng người mới cho đúng phản hồi.
Tình huống 3: Daily Standup bị biến thành buổi báo cáo dài lê thê
Tại một công ty outsourcing ở Đà Nẵng, một đội 8 người có daily standup kéo dài tới 40 phút mỗi sáng vì mọi người sa đà vào tranh luận kỹ thuật. BA mới — chị Thảo, từ nền Content Marketing — nhận ra mình mất gần 3,5 giờ mỗi tuần chỉ cho standup. Chị đề xuất một quy tắc trong buổi Retrospective: ai có vấn đề cần bàn sâu thì ghi vào "parking lot" và bàn riêng sau standup với đúng người liên quan. Standup rút còn 12 phút.
Bài học: Mỗi ceremony có mục đích riêng và thời lượng riêng. Standup là để đồng bộ nhanh và phát hiện vướng mắc, không phải để giải quyết chúng. Là BA, bạn nên là người tinh ý nhận ra quy trình đang "phình" và đề xuất cải tiến — đúng tinh thần Agile.
Hướng dẫn từng bước
Đây là lộ trình thực dụng để bạn làm chủ tool và quy trình trong 2–3 tuần đầu đi làm (hoặc tự luyện trước khi đi phỏng vấn):
Bước 1 — Lập tài khoản và làm quen Jira miễn phí. Atlassian cho dùng Jira free tới 10 người. Tạo một project mẫu, tạo thử một Epic "Tính năng đăng nhập", chẻ thành 3 Story, kéo qua các cột trên board. Mục tiêu: hiểu vòng đời một ticket từ "To Do" đến "Done".
Bước 2 — Học cấu trúc phân cấp công việc. Nắm rõ Epic → Story → Sub-task. Tập viết một Story theo cấu trúc quen thuộc: "Là một [người dùng], tôi muốn [làm gì], để [đạt mục đích gì]" kèm vài tiêu chí chấp nhận. (Phần này chỉ cần làm quen định dạng; cách viết chuẩn INVEST sẽ học sâu ở bài sau.)
Bước 3 — Dựng không gian tài liệu trên Confluence hoặc Notion. Tạo một trang "Biên bản họp" và một trang "Tài liệu yêu cầu". Thói quen ghi chép có cấu trúc là vũ khí lớn nhất của BA.
Bước 4 — Mô phỏng một sprint 2 tuần cho riêng bạn. Lấy một dự án giả định (ví dụ: app đặt lịch cắt tóc). Tự chạy Sprint Planning (chọn 4 Story), giả lập daily standup bằng cách mỗi ngày cập nhật trạng thái ticket, rồi cuối kỳ viết một bản "review" và "retro" ngắn.
Bước 5 — Xem và thao tác cơ bản trên Figma. Mở một file Figma cộng đồng, học cách dùng chế độ xem để đọc thông số (spacing, màu, text), để lại comment. BA không cần thiết kế đẹp, nhưng phải biết "đọc" thiết kế và giao tiếp với designer.
Bước 6 — Vẽ một user flow trên Miro. Lấy luồng "khách đặt lịch thành công" và vẽ sơ đồ các bước. Đây là cách bạn biến tư duy customer journey của Marketing thành ngôn ngữ của đội sản phẩm.
Bước 7 — Tập "ngôn ngữ" ceremony. Viết ra cho mình một câu mẫu cho mỗi ceremony: bạn sẽ nói gì trong standup, hỏi gì trong planning, chốt gì trong review. Diễn tập trước giúp bạn tự tin ngay buổi đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng phải thành thạo mọi tool ngay. Không. Hãy giỏi Jira và Confluence trước; Figma/Miro học dần khi cần. Nhà tuyển dụng BA junior không kỳ vọng bạn là chuyên gia Figma.
Lỗi 2 — Nhầm Agile là "làm việc không cần kế hoạch". Sai lầm phổ biến. Agile vẫn lập kế hoạch — chỉ là theo từng vòng ngắn thay vì một lần cho cả năm. "Linh hoạt" không có nghĩa là "tùy hứng".
Lỗi 3 — Im lặng trong Sprint Planning vì sợ nói sai. Marketer mới chuyển hay ngại vì "chưa hiểu kỹ thuật". Nhưng BA chính là người làm rõ nghiệp vụ, không phải người code. Câu hỏi "điều gì xảy ra nếu người dùng làm sai bước này?" đáng giá hơn nhiều so với im lặng.
Lỗi 4 — Viết Story xong là xong. Story sống động suốt sprint; dev sẽ hỏi lại. Hãy luôn sẵn sàng làm rõ giữa chừng.
Mẹo 1 — Tận dụng bộ lọc Jira (JQL). Học vài câu lọc cơ bản như assignee = currentUser() AND status = "In Progress". Nó tiết kiệm cho bạn hàng giờ mỗi tuần.
Mẹo 2 — Liên kết Jira với Confluence. Đính link tài liệu Confluence vào ticket Jira để dev luôn có ngữ cảnh đầy đủ. Đây là dấu hiệu của một BA chuyên nghiệp.
Mẹo 3 — Quan sát một sprint trọn vẹn trước khi cải tiến. Đừng vội đề xuất thay đổi quy trình trong tuần đầu. Hãy trải qua ít nhất một sprint để hiểu vì sao team làm như vậy, rồi mới góp ý trong Retrospective.
Mẹo 4 — Dùng template. Tạo sẵn mẫu Story, mẫu biên bản họp, mẫu acceptance criteria. Tốc độ và sự nhất quán là điểm cộng lớn.
Bài tập thực hành
- Dựng board cá nhân: Tạo tài khoản Jira free, lập project cho một sản phẩm giả định bạn yêu thích (app giao đồ ăn, sàn khóa học...). Tạo 1 Epic, 4 Story, mỗi Story có ít nhất 2 acceptance criteria. Kéo các ticket qua đủ các trạng thái.
- Mô phỏng sprint 1 tuần: Tự chạy một sprint rút gọn. Viết bản Sprint Planning (chọn việc), ghi 3 ngày "standup" (cập nhật tiến độ + ghi 1 vướng mắc giả định), rồi viết Sprint Review và Retrospective mỗi phần 5–7 dòng.
- Đối chiếu Marketing ↔ Agile: Lập một bảng 2 cột, liệt kê 5 hoạt động bạn từng làm trong Marketing và ánh xạ mỗi cái sang một khái niệm Agile/Scrum tương ứng (ví dụ: "weekly campaign review" → "Sprint Review"). Bài tập này giúp bạn tự tin kể câu chuyện chuyển nghề khi phỏng vấn.
- Vẽ một user flow trên Miro: Chọn một luồng nghiệp vụ đơn giản và vẽ sơ đồ các bước cùng các nhánh xử lý lỗi. Lưu lại để đưa vào portfolio sau này.
Tóm tắt
Bộ công cụ của BA xoay quanh bốn nhóm: quản lý backlog (Jira), tài liệu (Confluence/Notion), trực quan hóa (Figma/Miro) và giao tiếp (Slack/Teams) — nhưng tuần đầu bạn chỉ cần làm chủ Jira và Confluence. Agile là triết lý "thử nhanh — học nhanh — điều chỉnh", một tư duy mà người làm Marketing đã quen qua việc tối ưu campaign theo chu kỳ. Scrum cụ thể hóa Agile bằng các sprint cố định cùng bốn ceremony (Planning, Standup, Review, Retrospective) và ba vai trò; BA thường đứng cạnh Product Owner, làm rõ Story, trả lời dev và tham gia nghiệm thu.
Điều quan trọng nhất cần nhớ: bạn không bước vào một thế giới xa lạ. Bảng Kanban content, buổi review chỉ số hằng tuần, tư duy phân khúc tệp — tất cả đều có "phiên bản BA" tương ứng. Việc của bạn ở giai đoạn này là gọi đúng tên các khái niệm, thực hành trên tool thật, và bước vào sprint đầu tiên với sự tự tin rằng nền tảng Marketing chính là lợi thế chứ không phải gánh nặng.