Mở đầu — vì sao bài này quan trọng
Khi bạn còn là Designer, "công cụ làm việc" của bạn xoay quanh Figma, Adobe XD, Miro, có thể thêm Notion để ghi chú. Bạn quen với không gian trực quan, kéo thả, màu sắc. Nhưng bước sang thế giới BA, bạn sẽ nhanh chóng nhận ra rằng phần lớn cuộc sống nghề nghiệp của một Business Analyst diễn ra trong hai công cụ nghe khá "khô khan": Jira và Confluence.
Đây không phải chuyện nhỏ. Trong phần lớn các công ty phần mềm tại Việt Nam — từ product company như MoMo, Tiki, VNG cho đến các outsourcing lớn như FPT Software, KMS, NashTech — Jira và Confluence gần như là "hệ thần kinh trung ương" của cả tổ chức. Nếu tài liệu của bạn không nằm trong Confluence, coi như nó không tồn tại. Nếu công việc của bạn không được theo dõi bằng ticket Jira, coi như nó không được tính. Một BA giỏi về nghiệp vụ nhưng lúng túng khi tạo Epic, không biết link requirement với ticket dev, hay viết Confluence page lộn xộn — sẽ nhanh chóng bị đánh giá là "chưa chuyên nghiệp", dù chuyên môn phân tích thực sự tốt.
Tin vui cho bạn — người từ nền Design — là bạn có lợi thế bất ngờ. Tư duy cấu trúc thông tin (information architecture), khả năng sắp xếp trực quan, thói quen làm mọi thứ dễ đọc và dễ điều hướng, tất cả đều cực kỳ hữu ích khi tổ chức một không gian Confluence hay một board Jira. Rất nhiều BA thuần nghiệp vụ viết tài liệu như bức tường chữ; bạn thì có con mắt biết khi nào cần bảng, khi nào cần diagram, khi nào cần khoảng trắng. Bài học này sẽ giúp bạn chuyển hóa lợi thế đó thành một workflow BA chuẩn mực.
Khái niệm cốt lõi
Confluence là gì và nó khác Notion ở đâu
Confluence là công cụ wiki tài liệu của Atlassian. Bạn có thể hình dung nó như một "thư viện tri thức" của cả team và công ty: mọi tài liệu nghiệp vụ, biên bản họp, quyết định thiết kế, và đặc tả kỹ thuật đều sống ở đây. Điểm mấu chốt khiến Confluence khác Google Docs hay Notion là nó liên kết chặt với Jira — bạn có thể nhúng một ticket Jira vào giữa trang tài liệu, và trạng thái ticket tự cập nhật.
Với vai trò BA, Confluence là nơi bạn đặt "phần WHAT và WHY" của một dự án: BRD (Business Requirements Document), SRS (Software Requirements Specification), sơ đồ BPMN, business rule catalog, đường link tới mockup/prototype, biên bản workshop, và các quyết định phân tích. Đây là nguồn sự thật (single source of truth) cho toàn bộ tri thức nghiệp vụ.
Jira là gì
Jira là công cụ theo dõi công việc (work tracking). Nếu Confluence trả lời câu hỏi "hệ thống cần làm gì và tại sao", thì Jira trả lời câu hỏi "ai đang làm gì, đến đâu rồi, và bao giờ xong". Jira quản lý công việc theo các cấp độ:
- Epic — một khối tính năng lớn, ví dụ "Thanh toán bằng ví điện tử". Một Epic thường kéo dài nhiều sprint.
- Story (User Story) — một mẩu giá trị người dùng có thể bàn giao, ví dụ "Là khách hàng, tôi muốn liên kết ví MoMo để thanh toán nhanh hơn". Đây là đơn vị làm việc chính của BA.
- Task / Sub-task — công việc kỹ thuật nhỏ hơn, thường do dev tự chia nhỏ từ Story.
- Bug — lỗi cần sửa.
Mối quan hệ Confluence ↔ Jira: xương sống workflow của BA
Đây là điều quan trọng nhất trong bài. Hai công cụ này không tách rời — chúng bổ trợ cho nhau theo một logic rõ ràng:
Confluence chứa chi tiết đầy đủ (deep documentation); Jira chứa đơn vị công việc để thực thi (executable units). Một Confluence page BRD có thể dài 10 trang mô tả toàn bộ luồng nghiệp vụ thanh toán. Nhưng dev không đọc 10 trang mỗi ngày — họ làm việc trên từng User Story trong Jira. Nhiệm vụ của BA là cắt tài liệu Confluence thành các Story Jira, và ngược lại, link mỗi Story trở về đúng đoạn tài liệu Confluence gốc. Nhờ vậy, khi dev đọc một Story và có thắc mắc về bối cảnh, họ chỉ cần bấm vào link "Requirement" gắn kèm để về đọc chi tiết đầy đủ.
Sự liên kết hai chiều này gọi là traceability — khả năng truy vết từ yêu cầu nghiệp vụ xuống tới dòng code và ngược lại. Đây là một trong những giá trị lớn nhất mà BA mang lại, và Jira + Confluence là công cụ giúp bạn làm điều đó một cách tự nhiên.
Tình huống thực tế
Ví dụ 1: Bạn Linh — Designer chuyển BA tại một fintech ở TP.HCM
Linh vừa chuyển từ vị trí UX Designer sang Associate BA tại một công ty fintech khoảng 120 người ở Quận 1. Nhiệm vụ đầu tiên của cô: đặc tả tính năng "Nạp tiền vào ví bằng thẻ ngân hàng". Theo thói quen Designer cũ, Linh viết toàn bộ mô tả tính năng vào phần Description của một Story Jira duy nhất — dài hơn 2.000 từ, kèm 8 ảnh mockup dán trực tiếp.
Kết quả: hai tuần sau, Story đó trở thành cơn ác mộng. Dev không tìm được acceptance criteria giữa rừng chữ. QA không biết test case nằm ở đâu. Khi PO muốn sửa một business rule về hạn mức nạp tối đa, không ai biết chỗ nào là "phiên bản đúng". Jira không được thiết kế để chứa tài liệu dài — nó không có mục lục, không phân trang, khó so sánh phiên bản.
Mentor của Linh chỉ cho cô cách làm chuẩn: viết toàn bộ đặc tả (luồng nghiệp vụ, business rule, bảng hạn mức, link mockup) thành một Confluence page có mục lục rõ ràng. Sau đó tạo một Epic "Nạp tiền qua thẻ ngân hàng" trong Jira, chẻ nhỏ thành 5 Story (nhập thông tin thẻ, xác thực OTP, xử lý giao dịch, hiển thị kết quả, xử lý lỗi). Mỗi Story chỉ ngắn gọn, có acceptance criteria riêng, và link "Requirement" trỏ về đúng section của Confluence page.
Bài học: Confluence để suy nghĩ sâu và lưu trữ đầy đủ; Jira để chia nhỏ và thực thi. Đừng nhồi tài liệu dài vào ticket. Story Jira nên đọc được trong 2 phút.
Ví dụ 2: Team outsourcing tại Đà Nẵng và bài toán "tài liệu mồ côi"
Một team gồm 4 BA tại một công ty outsourcing ở Đà Nẵng làm dự án cho khách hàng Nhật. Mỗi BA có cách tổ chức Confluence riêng: người tạo page rời rạc, người đặt tên kiểu "BRD_final_v2_thang3", người thì lưu tài liệu trong file Word đính kèm. Sau 6 tháng, không ai tìm nổi tài liệu của module nào. Khi khách hàng hỏi "business rule tính phí trễ hạn nằm ở đâu", cả team mất nửa ngày lục lọi.
Giải pháp họ áp dụng là xây một cấu trúc Confluence space chuẩn hóa với cây phân cấp cố định: mỗi module là một page cha, dưới đó có các page con theo template thống nhất (Overview → Process Flow → Requirements → Business Rules → Open Questions). Họ dùng tính năng page template của Confluence để mọi BA tạo tài liệu mới theo đúng khuôn. Họ cũng dùng labels (nhãn) như payment, late-fee, phase-2 để lọc tài liệu chéo giữa các module.
Sau khi chuẩn hóa, thời gian tìm một quyết định nghiệp vụ giảm từ trung bình 20 phút xuống dưới 2 phút, và khách hàng Nhật — vốn khắt khe về tài liệu — đánh giá cao rõ rệt.
Bài học: Cấu trúc thông tin (information architecture) là kỹ năng Designer sẵn có. Đừng để mỗi người tự do một kiểu — hãy áp một cây phân cấp và template thống nhất. Đây chính là lúc con mắt IA của bạn tỏa sáng.
Ví dụ 3: Sprint planning tại một product team và giá trị của link hai chiều
Tại một product team khoảng 30 người (2 squad), một BA tên Đức chịu trách nhiệm module "Chương trình khách hàng thân thiết". Trong buổi sprint planning, dev hỏi: "Story tích điểm này, nếu khách hoàn trả đơn hàng thì điểm đã tích có bị trừ không?" Đức không nhớ chi tiết, nhưng vì mỗi Story của anh đều có link "Requirement" trỏ về Confluence, anh bấm vào ngay tại buổi họp, cuộn xuống mục Business Rules, và đọc: "BR-07: Khi đơn hàng bị hoàn trả trong 30 ngày, điểm tích tương ứng bị thu hồi."
Cả buổi họp mất đúng 40 giây để có câu trả lời chính xác, có nguồn gốc rõ ràng, thay vì tranh luận cảm tính rồi "để về check lại". Đó là sức mạnh của traceability được thiết lập từ đầu.
Bài học: Việc bỏ 30 giây gắn một link khi tạo Story sẽ tiết kiệm cho cả team hàng giờ tranh luận về sau. Link hai chiều Jira ↔ Confluence là "bảo hiểm" cho trí nhớ của bạn.
Hướng dẫn từng bước
Đây là workflow chuẩn mà một BA nên thực hiện khi nhận một tính năng mới. Hãy coi đây là checklist để lặp lại.
Bước 1 — Tạo trang tài liệu trong Confluence trước. Với mỗi tính năng lớn, mở một Confluence page (dùng template nếu team đã có). Cấu trúc gợi ý: (1) Tổng quan & mục tiêu nghiệp vụ, (2) Stakeholder liên quan, (3) As-Is / To-Be process flow (nhúng sơ đồ BPMN), (4) Functional requirements, (5) Business rule catalog dạng bảng, (6) Link tới mockup/prototype Figma, (7) Open questions & decisions. Đây là nơi bạn tư duy sâu.
Bước 2 — Tạo Epic trong Jira tương ứng. Đặt tên Epic khớp với tính năng, ví dụ "Nạp tiền qua thẻ ngân hàng". Trong phần mô tả Epic, dán link tới Confluence page ở bước 1. Vậy là Epic đã "biết" tài liệu gốc của nó nằm đâu.
Bước 3 — Chẻ Epic thành User Story. Từ functional requirements trong Confluence, tách thành các Story theo giá trị người dùng. Nguyên tắc: mỗi Story nên đủ nhỏ để hoàn thành trong một sprint, và độc lập bàn giao được. Viết theo format quen thuộc "Là [vai trò], tôi muốn [hành động] để [giá trị]".
Bước 4 — Viết acceptance criteria cho từng Story. Đây là phần dev và QA dùng nhiều nhất. Viết rõ điều kiện nghiệm thu (ở bài về Gherkin bạn sẽ học cú pháp Given-When-Then chi tiết hơn). Ở đây, điểm cần nhớ là acceptance criteria sống trong Story Jira, không phải trong Confluence — vì nó gắn trực tiếp với việc test.
Bước 5 — Link Story trở về Confluence. Trong mỗi Story, thêm một link tới đúng section tài liệu gốc. Đây là bước mà 80% BA mới quên, nhưng lại tạo ra khác biệt lớn về traceability.
Bước 6 — Dùng Confluence để nhúng ngược Jira. Trong page BRD, dùng macro "Jira Issues/Filter" để nhúng danh sách các Story của Epic. Kết quả: khi ai đó đọc tài liệu, họ thấy luôn trạng thái thực thi (To Do / In Progress / Done) cập nhật tự động. Tài liệu và tiến độ nằm cùng một chỗ.
Bước 7 — Cập nhật liên tục trong sprint. Khi có thay đổi requirement, sửa Confluence trước (vì đó là nguồn sự thật), rồi phản ánh xuống Story Jira liên quan, và comment vào Story để dev biết có thay đổi. Đừng bao giờ chỉ sửa Jira mà quên Confluence — sẽ dẫn tới hai phiên bản mâu thuẫn.
Bước 8 — Ghi lại quyết định (decision log). Mỗi khi có một quyết định nghiệp vụ quan trọng (ví dụ: chốt hạn mức nạp tối đa 20 triệu/ngày), ghi vào mục "Decisions" trong Confluence kèm ngày và người quyết định. Sau này khi ai đó hỏi "tại sao lại là 20 triệu", bạn có câu trả lời.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết tài liệu dài trong Jira. Như tình huống của Linh, Jira không phải chỗ để đặc tả 2.000 từ. Quy tắc ngón tay cái: nếu ticket của bạn cần cuộn chuột quá 2 lần, phần lớn nội dung nên nằm ở Confluence.
Lỗi 2 — Không link hai chiều. Story không link về Confluence, hoặc Confluence không nhúng Jira. Khi thiếu link, bạn phá vỡ traceability và biến mình thành "người phiên dịch" duy nhất — mỗi lần dev hỏi, họ phải hỏi bạn thay vì tự tra được.
Lỗi 3 — Epic quá to hoặc quá nhỏ. Epic "Toàn bộ hệ thống thanh toán" thì quá lớn (kéo dài cả năm, không đo được tiến độ). Ngược lại, mỗi nút bấm một Epic thì quá vụn. Epic tốt là một khối tính năng có thể ra mắt độc lập và có giá trị nghiệp vụ rõ ràng.
Lỗi 4 — Dùng Confluence như ổ cứng lưu file Word. Đính kèm file .docx rồi bắt mọi người tải về là thói quen tệ — mất khả năng comment inline, mất phiên bản, mất tìm kiếm full-text. Hãy viết nội dung trực tiếp bằng native Confluence page.
Mẹo 1 — Tận dụng template. Tạo sẵn page template cho BRD, biên bản họp, business rule. Mỗi lần bắt đầu tài liệu mới chỉ cần chọn template, đảm bảo tính nhất quán và không quên mục nào.
Mẹo 2 — Dùng labels và @mention. Gắn nhãn cho tài liệu để lọc chéo. Dùng @mention để tag đúng người vào comment thay vì gửi email lẻ — mọi trao đổi được lưu ngay tại ngữ cảnh.
Mẹo 3 — Học vài JQL cơ bản. JQL (Jira Query Language) giúp bạn lọc nhanh, ví dụ Epic Link = "Nạp tiền qua thẻ" AND status != Done để thấy còn Story nào chưa xong. Chỉ cần vài câu lệnh đơn giản là bạn đã tự chủ được board.
Mẹo 4 — Phát huy con mắt Designer của bạn. Dùng bảng, panel màu, expand section, và khoảng trắng để tài liệu Confluence dễ đọc. Một business rule catalog trình bày dạng bảng gọn gàng sẽ được cả team biết ơn — đây là lợi thế cạnh tranh của người từ nền Design.
Bài tập thực hành
Hãy chọn một tính năng đơn giản mà bạn quen thuộc — gợi ý: "Đặt lại mật khẩu qua email" cho một ứng dụng bất kỳ. Thực hiện đầy đủ vòng workflow:
- Tạo một Confluence page (nếu chưa có tài khoản, dùng bản dùng thử miễn phí của Atlassian hoặc phác trên Notion/Google Docs mô phỏng cấu trúc). Bao gồm ít nhất: tổng quan, process flow đơn giản, 3 functional requirements, một bảng business rule (ví dụ: "link reset hết hạn sau 15 phút").
- Tạo một Epic tên "Đặt lại mật khẩu" và chẻ thành 3–4 User Story theo format "Là... tôi muốn... để...".
- Viết acceptance criteria cho ít nhất một Story.
- Thiết lập link hai chiều: mỗi Story trỏ về Confluence, và page Confluence nhúng danh sách Story.
- Viết một decision log entry giả định, ví dụ: "Quyết định 27/06: link reset hết hạn 15 phút thay vì 60 phút để tăng an toàn — chốt bởi PO."
Tóm tắt
Jira và Confluence là bộ đôi công cụ trung tâm trong đời sống của một BA tại các công ty phần mềm Việt Nam. Nguyên tắc cốt lõi để nhớ mãi: Confluence chứa tri thức sâu (WHAT và WHY), Jira chứa đơn vị công việc để thực thi (WHO và WHEN), và bạn nối chúng bằng link hai chiều để tạo traceability. Cấu trúc phân cấp Epic → Story → Task là cầu nối tự nhiên giữa thế giới nghiệp vụ của BA và thế giới thực thi của dev.
Đừng nhồi tài liệu dài vào ticket, đừng để tài liệu mồ côi không có cấu trúc, và đừng quên gắn link — ba lỗi này chiếm phần lớn khoảng cách giữa một BA nghiệp dư và một BA chuyên nghiệp. Với lợi thế tư duy cấu trúc thông tin và con mắt trình bày trực quan từ nền Design, bạn hoàn toàn có thể trở thành người tổ chức không gian Jira + Confluence gọn gàng và dễ dùng nhất team — một giá trị mà rất nhiều BA thuần nghiệp vụ không có được.