Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi một BA đã đi làm 2-3 năm rằng họ dành nhiều thời gian nhất cho phần mềm nào trong ngày, câu trả lời gần như chắc chắn là Jira và Confluence. Đây không phải là hai công cụ "biết thì tốt", mà là hai môi trường làm việc mặc định của ngành phần mềm. Backlog nằm trong Jira. Requirement specification, biên bản họp, sơ đồ, quyết định thiết kế nằm trong Confluence. Khi nhà tuyển dụng đăng tin "BA có kinh nghiệm Jira/Confluence là một lợi thế", thực chất họ đang nói: chúng tôi không muốn mất hai tuần đầu chỉ để dạy bạn cách tạo một story đúng chuẩn.
Vấn đề là phần lớn BA dùng Jira ở mức "biết bấm nút": tạo issue, kéo thả trên board, gõ vài dòng mô tả. Họ chưa thực sự hiểu cấu trúc phân cấp công việc, chưa biết tận dụng JQL để trả lời câu hỏi của sếp trong 30 giây thay vì 30 phút, chưa biết cách link Confluence với Jira để requirement và implementation luôn đồng bộ. Sự khác biệt giữa một BA "dùng được Jira" và một BA "làm chủ Jira" thể hiện rõ nhất ở những thời điểm áp lực: lúc cần báo cáo tiến độ cho stakeholder, lúc impact analysis một thay đổi, lúc một bug production cần truy ngược về requirement gốc.
Bài này tập trung đúng vào việc đó: biến hai công cụ tưởng chừng đơn giản thành đòn bẩy năng suất và uy tín nghề nghiệp của bạn. Lưu ý phạm vi: ở đây chúng ta nói về cách vận hành công cụ và quy trình quanh nó, không đi sâu lại vào lý thuyết viết user story (đã có ở Bài 36), backlog refinement (Bài 37) hay traceability matrix (Bài 32) — bài này chỉ chỉ ra cách hiện thực hóa những khái niệm đó bên trong Jira và Confluence.
Khái niệm cốt lõi
Cấu trúc phân cấp trong Jira
Jira tổ chức công việc theo nhiều tầng, và hiểu đúng tầng này là nền tảng của mọi thứ:
- Project: container lớn nhất, thường tương ứng một sản phẩm, một hệ thống hoặc một đội. Mỗi project có key riêng (ví dụ
EKYC,PAY), và key này gắn vào mọi issue (EKYC-101, EKYC-102). - Epic: một khối công việc lớn, thường kéo dài nhiều sprint, đại diện cho một tính năng hoặc mục tiêu nghiệp vụ. Ví dụ: "Đăng nhập bằng sinh trắc học".
- Story: một yêu cầu mang lại giá trị cho người dùng, đủ nhỏ để hoàn thành trong một sprint. Đây là đơn vị làm việc chính của BA.
- Sub-task: việc nhỏ tách ra từ một story, thường là phần kỹ thuật (backend API, frontend UI, viết test).
- Story: yêu cầu từ góc nhìn người dùng.
- Bug: lỗi cần sửa.
- Task: công việc không nhất thiết mang giá trị trực tiếp cho user (ví dụ "cấu hình môi trường staging").
- Epic: như trên, là một loại issue đặc biệt.
- Spike: một việc nghiên cứu/thử nghiệm có timebox, dùng khi đội cần tìm hiểu trước khi ước lượng được. Ví dụ "Spike: đánh giá 3 nhà cung cấp OCR cho CMND".
Workflow và trạng thái
Mỗi issue di chuyển qua một workflow — chuỗi trạng thái có quy tắc chuyển tiếp. Workflow mặc định đơn giản là To Do → In Progress → Done, nhưng đội thực tế thường mở rộng: Backlog → Ready → In Progress → In Review → In Test → Done. BA cần nắm workflow vì nó định nghĩa "Definition of Ready" và "Definition of Done" được mã hóa thành các transition. Một story chỉ nên vào Ready khi đã đủ acceptance criteria — đây là chốt chặn chất lượng mà BA phải canh giữ.
JQL — ngôn ngữ truy vấn của Jira
Đây là kỹ năng phân biệt BA giỏi. JQL (Jira Query Language) cho phép bạn lọc issue bằng câu lệnh thay vì bấm nút. Ví dụ:
project = EKYC AND issuetype = Story AND status != Done AND sprint in openSprints() ORDER BY priority DESC
Câu này trả về mọi story chưa xong trong sprint hiện tại, sắp theo độ ưu tiên. Một số mẫu cực hữu ích cho BA:
project = PAY AND status changed to Done DURING (-7d, now())
assignee = currentUser() AND status = "In Review"
labels = regulatory AND fixVersion = "Release 2.4"
JQL biến Jira từ một bảng kanban tĩnh thành công cụ trả lời câu hỏi tức thời cho stakeholder.
Confluence — bộ nhớ dài hạn của dự án
Nếu Jira là "việc đang làm" thì Confluence là "vì sao chúng ta làm và đã quyết định gì". Confluence tổ chức theo Space (không gian, thường một space cho một dự án/đội) chứa các Page lồng nhau theo cây. Với BA, ba loại tài liệu sống ở đây là: tài liệu requirement (BRD/FRD — phân biệt đã học ở Bài 33), biên bản họp và quyết định (decision log), cùng các trang kiến thức nghiệp vụ.
Sức mạnh thật sự nằm ở tích hợp Jira-Confluence: bạn có thể nhúng một bộ lọc JQL trực tiếp vào trang Confluence bằng macro Jira Issues. Khi đó trang requirement không chỉ mô tả tính năng mà còn hiển thị real-time danh sách story đang triển khai tính năng đó, kèm trạng thái. Macro Page Properties Report giúp tổng hợp metadata từ nhiều trang con thành một bảng — lý tưởng cho việc theo dõi trạng thái nhiều requirement.
Tình huống thực tế
Tình huống 1 — Đội eKYC ngân hàng và cây Epic-Story rối loạn
Tại một dự án eKYC của một ngân hàng số ở TP.HCM (giả định, đội khoảng 12 người), BA mới vào tạo tất cả yêu cầu thành Story phẳng, không gắn Epic. Sau 4 sprint, board có 140 story rời rạc. Khi giám đốc sản phẩm hỏi "tính năng xác thực khuôn mặt đã xong bao nhiêu phần trăm?", không ai trả lời được vì các story liên quan nằm rải rác.
Diễn giải: BA dành một buổi để gom story vào 6 Epic theo nhóm tính năng (Chụp giấy tờ, OCR, Đối chiếu khuôn mặt, Kiểm tra liveness, Tích hợp CIC, Phê duyệt thủ công). Sau đó dùng báo cáo Epic Burndown, câu hỏi tiến độ được trả lời trong 10 giây. Bài học: cấu trúc phân cấp không phải hình thức — nó quyết định bạn có trả lời được câu hỏi quản trị hay không. Hãy tạo Epic trước, rồi mới đẻ story bên dưới.
Tình huống 2 — Tiki và một dashboard JQL cứu cuộc họp standup
Giả định tại một đội thuộc một sàn thương mại điện tử lớn của Việt Nam, mỗi sáng standup mất 25 phút chỉ để PO đọc qua từng cột board. BA đề xuất xây một dashboard Jira với 3 gadget dựa trên JQL: (1) story In Progress quá 3 ngày — status = "In Progress" AND status changed to "In Progress" before -3d; (2) issue bị blocked — status = Blocked; (3) bug ưu tiên cao mở — issuetype = Bug AND priority in (High, Highest) AND status != Done.
Diễn giải: standup rút còn 10 phút vì đội chỉ tập trung vào những gì bất thường thay vì điểm danh toàn bộ. BA ở đây không viết code, không quản lý đội, nhưng tạo ra giá trị bằng cách thiết kế cách nhìn dữ liệu. Bài học: JQL là kỹ năng đòn bẩy cao nhất của BA trong Jira — đầu tư một buổi học nó, dùng cả sự nghiệp.
Tình huống 3 — Trang Confluence "sống" cho dự án BNPL
Một đội FinTech làm sản phẩm Buy Now Pay Later (giả định, hợp tác với một ví điện tử) gặp vấn đề kinh điển: tài liệu FRD trên Confluence viết xong là "chết", còn thực tế triển khai trong Jira thì trôi đi mỗi ngày, hai bên lệch nhau. Khi audit nội bộ hỏi "requirement X đã được build và test chưa", BA phải lục thủ công.
Diễn giải: BA tái cấu trúc trang FRD, mỗi mục requirement nhúng một macro Jira Issues lọc theo label tương ứng (label = req-installment-calc). Từ đó trang requirement luôn hiển thị trạng thái triển khai real-time. Đồng thời mỗi story trong Jira được link ngược về trang Confluence qua mục "Confluence pages" trong issue. Bài học: đừng để Jira và Confluence là hai ốc đảo. Link hai chiều biến chúng thành một hệ thống truy vết sống, tiết kiệm hàng giờ mỗi đợt audit.
Hướng dẫn từng bước
Đây là quy trình một BA nên làm khi nhận một tính năng mới và đưa nó vào hệ thống Jira-Confluence:
- Tạo trang requirement trên Confluence trước. Dùng template "Product Requirements" có sẵn của Confluence. Ghi rõ mục tiêu nghiệp vụ, scope, các yêu cầu, và acceptance criteria ở mức tính năng. Đây là nguồn sự thật.
- Tạo Epic trong Jira đại diện cho tính năng. Đặt tên ngắn gọn, mô tả link về trang Confluence vừa tạo (dán URL, Jira tự nhận diện và tạo liên kết hai chiều).
- Phân rã thành Story dưới Epic. Mỗi story viết theo chuẩn đã học ở Bài 36, điền acceptance criteria vào phần mô tả hoặc field riêng. Gắn label nhất quán (ví dụ
req-onboarding) để sau này lọc được bằng JQL.
- Gắn story vào Epic qua field "Epic Link" (hoặc "Parent" trên Jira phiên bản mới). Kiểm tra board hiển thị đúng cây phân cấp.
- Tách sub-task khi cần — thường để đội dev tự làm, nhưng BA nên thống nhất quy ước (ví dụ luôn có sub-task "viết test case").
- Nhúng bộ lọc JQL vào trang Confluence. Trên trang requirement, thêm macro Jira Issues với JQL lọc theo Epic hoặc label. Giờ trang tài liệu tự cập nhật trạng thái.
- Thiết lập dashboard cá nhân. Tạo dashboard với các gadget JQL phục vụ vai trò BA: story thiếu acceptance criteria, story sắp vào sprint, bug liên quan tính năng của bạn.
- Duy trì decision log trên Confluence. Mỗi quyết định quan trọng (thay đổi scope, chọn giải pháp) ghi vào một trang riêng có ngày tháng và người quyết — vô giá khi bị hỏi lại sau 6 tháng.
Lỗi thường gặp & mẹo
Lỗi: dùng Story và Task lẫn lộn. Nhiều BA gọi mọi thứ là Story. Hậu quả là báo cáo velocity sai (Task thường không tính point) và board nhiễu. Mẹo: Story phải có người dùng và giá trị; nếu không, đó là Task.
Lỗi: mô tả issue sơ sài "theo như đã trao đổi". Dev không đọc được suy nghĩ của bạn. Mẹo: mỗi story luôn có bối cảnh, acceptance criteria rõ ràng, và link tới mockup/Confluence. Nếu một story không thể tự đứng một mình khi đọc, nó chưa Ready.
Lỗi: bỏ qua JQL, dùng tay lọc. Tốn thời gian và dễ sót. Mẹo: học 10 mẫu JQL phổ biến, lưu thành "saved filter" để tái dùng và chia sẻ cho đội.
Lỗi: Confluence thành bãi rác tài liệu. Trang tạo lung tung, không cây thư mục, search không ra. Mẹo: thống nhất cấu trúc space ngay từ đầu, dùng label cho trang, đặt tên trang theo quy ước (ví dụ [FRD] Tên tính năng).
Lỗi: tài liệu Confluence lệch với Jira. Mẹo: dùng macro nhúng JQL và link hai chiều thay vì copy-paste trạng thái thủ công.
Mẹo nâng cao: học dùng bulk change trong Jira để cập nhật hàng loạt issue (đổi sprint, gắn label, đổi fixVersion) thay vì sửa từng cái. Và bật automation rule đơn giản, ví dụ tự động comment nhắc khi một story ở In Review quá 2 ngày.
Bài tập thực hành
- Dựng cây phân cấp. Lấy một tính năng giả định "Thanh toán bằng QR code" cho một ví điện tử. Tạo 1 Epic, ít nhất 4 Story, mỗi Story 2 sub-task. Gắn label nhất quán cho cả nhóm.
- Viết 5 câu JQL trả lời các câu hỏi sau: (a) story chưa xong trong sprint hiện tại; (b) bug ưu tiên cao chưa có người nhận; (c) issue do bạn tạo trong 7 ngày qua; (d) story thuộc Epic "Thanh toán QR" còn mở; (e) issue đã chuyển sang Done tuần này.
- Tạo một trang Confluence requirement cho tính năng trên, có ít nhất: mục tiêu nghiệp vụ, danh sách yêu cầu, acceptance criteria, và một macro nhúng JQL hiển thị các story liên quan (lọc theo label).
- Thiết kế một dashboard BA với 3 gadget dựa trên JQL phục vụ standup. Viết ra lý do bạn chọn 3 góc nhìn đó.
- Thử nghiệm liên kết hai chiều: từ một story, link tới trang Confluence; từ trang Confluence, kiểm tra liên kết ngược xuất hiện. Ghi lại các bước.
Tóm tắt
Jira và Confluence không phải là kỹ năng phụ — chúng là môi trường làm việc hằng ngày của BA và là nơi uy tín nghề nghiệp của bạn được nhìn thấy. Nắm vững cấu trúc phân cấp Project–Epic–Story–Sub-task và các issue type (Story, Bug, Task, Epic, Spike) cho bạn nền tảng tổ chức công việc rõ ràng. Hiểu workflow giúp bạn canh giữ chất lượng tại các chốt Ready và Done. Nhưng kỹ năng tạo khác biệt lớn nhất là JQL — nó biến Jira thành công cụ trả lời câu hỏi tức thời, giúp bạn tỏa sáng trong những khoảnh khắc áp lực với stakeholder.
Confluence là bộ nhớ dài hạn của dự án: nơi lưu requirement, quyết định và kiến thức nghiệp vụ. Sức mạnh thực sự đến khi bạn kết nối hai công cụ — nhúng JQL vào trang requirement, link hai chiều giữa story và tài liệu — để tạo nên một hệ thống truy vết sống thay vì hai ốc đảo lệch nhau. Ba tình huống eKYC, thương mại điện tử và BNPL ở trên đều chung một bài học: BA giỏi không chỉ nhập liệu vào công cụ, mà thiết kế cách dữ liệu chảy và được nhìn. Hãy luyện những thao tác này đến mức phản xạ, và bạn sẽ tiết kiệm cho mình hàng trăm giờ, đồng thời được đội nhìn nhận như một người làm chủ guồng máy dự án.