Mở đầu — vì sao bài này quan trọng
Bạn có thể là một BA giỏi về lý thuyết: viết User Story chuẩn, vẽ Process Flow đẹp, phỏng vấn stakeholder mượt mà. Nhưng nếu tất cả những thứ đó nằm rải rác trong file Word, group chat Zalo, và email cá nhân, thì khi dự án bước vào tuần thứ 8 với 200 yêu cầu và 5 đợt thay đổi, bạn sẽ chìm nghỉm. Đây là lúc công cụ lên tiếng.
Trong thực tế đi làm tại Việt Nam, hai cái tên xuất hiện gần như mọi nơi: Jira (quản lý công việc, backlog, requirements) và Confluence (lưu tài liệu, kiến thức, đặc tả). Chúng là cặp đôi của hãng Atlassian, được thiết kế để dùng chung. FPT Software, MoMo, Tiki, VNG, Techcombank — phần lớn các team sản phẩm và outsourcing đều xài bộ này hoặc một biến thể tương tự.
Bài học này KHÔNG dạy bạn cách viết User Story (Bài 6 đã làm), cách viết PRD/BRD (Bài 7), hay cách vẽ Process Flow (Bài 8). Bài này tập trung vào một câu hỏi rất cụ thể: Khi đã có yêu cầu trong tay, BA dùng Jira và Confluence như thế nào để quản lý, kết nối, và vận hành luồng công việc (workflow) một cách chuyên nghiệp? Đây chính là kỹ năng "công cụ" mà nhà tuyển dụng luôn hỏi trong phỏng vấn: "Em đã dùng Jira chưa? Workflow của em như thế nào?"
Khái niệm cốt lõi
Jira — bộ não quản lý Backlog và Requirements
Jira là công cụ theo dõi công việc (issue tracking). Với BA, Jira không chỉ là nơi giao việc cho dev, mà là nơi requirements sống và tiến hóa. Để dùng Jira đúng, bạn cần nắm ba khái niệm nền tảng.
1. Issue Types (loại công việc) — hệ thống phân cấp
Jira tổ chức công việc theo cấu trúc phân cấp ba tầng:
- Epic: một khối yêu cầu lớn, một tính năng hoặc một nhóm mục tiêu nghiệp vụ. Ví dụ: "Thanh toán qua ví điện tử". Một Epic thường kéo dài nhiều Sprint.
- Story (hoặc Task): một yêu cầu nhỏ, mang lại giá trị độc lập, hoàn thành được trong một Sprint. Ví dụ: "Người dùng liên kết tài khoản MoMo". Mỗi Story nằm dưới một Epic.
- Sub-task: việc nhỏ để hoàn thành một Story, thường do dev/QA chia ra. Ví dụ: "Code API liên kết ví", "Viết test case liên kết ví".
Mẹo tư duy: Epic trả lời "Tại sao và cho ai?", Story trả lời "Người dùng làm được gì?", Sub-task trả lời "Cụ thể phải làm gì để xong?".
2. Custom Fields (trường tùy chỉnh) — nơi requirements gắn vào
Jira mặc định có Summary, Description, Assignee... nhưng với BA, trường quan trọng nhất cần thêm vào là Acceptance Criteria (tiêu chí chấp nhận). Đây là trường custom mà admin Jira tạo riêng, để mỗi Story đều có chỗ ghi rõ "thế nào là làm xong và đúng". Ngoài ra BA hay dùng các custom field khác: Priority (độ ưu tiên), Story Points (ước lượng độ phức tạp), Components (phân hệ — ví dụ Payment, User, Notification), và Labels (nhãn để lọc nhanh).
Nếu công ty không cho phép tạo custom field (thường gặp ở team nhỏ dùng bản free), BA sẽ đặt Acceptance Criteria ngay trong phần Description theo một format cố định. Quan trọng là nhất quán, không phải công cụ xịn.
3. Workflow (luồng trạng thái) — vòng đời của một yêu cầu
Workflow là chuỗi trạng thái mà một issue đi qua. Một workflow điển hình cho team có BA:
To Do → In Analysis → Ready for Dev → In Progress → In Review → In Testing → Done
Cái khác biệt khi có BA trong team là hai trạng thái đầu: In Analysis (BA đang làm rõ yêu cầu) và Ready for Dev (BA đã hoàn tất phân tích, dev có thể nhận). Đây chính là "cổng chất lượng" — dev không nên kéo việc từ To Do thẳng vào code khi yêu cầu chưa rõ.
Confluence — bộ nhớ dài hạn của dự án
Nếu Jira là dòng chảy công việc (động), thì Confluence là kho kiến thức (tĩnh). Confluence là wiki nội bộ, nơi BA lưu những tài liệu cần tồn tại lâu và được nhiều người tham chiếu:
- BRD, PRD, đặc tả tính năng chi tiết
- Process Flow, sơ đồ, mockup
- Biên bản họp (meeting notes), quyết định (decision log)
- Danh sách thuật ngữ nghiệp vụ (glossary)
Mối liên kết Jira–Confluence — điểm vàng của BA giỏi
Sức mạnh thật sự nằm ở chỗ hai công cụ này link được với nhau. Trong một trang Confluence (ví dụ trang PRD), bạn có thể nhúng một bộ lọc Jira để hiển thị tất cả Story thuộc Epic này kèm trạng thái cập nhật theo thời gian thực. Ngược lại, trong một Story trên Jira, bạn dán link tới trang Confluence chứa đặc tả đầy đủ. Nhờ vậy, dev đọc Story ngắn gọn nhưng vẫn truy được tài liệu sâu, và sếp đọc PRD vẫn thấy tiến độ thật. Đây là cách BA tạo ra traceability (khả năng truy vết) mà không phải copy-paste thủ công.
Tình huống thực tế
Tình huống 1: Startup fintech TP.HCM dựng Jira từ con số 0
Một startup ví điện tử ở quận 1 (gọi là PayZ) có 12 người, mới thuê BA đầu tiên là chị Lan. Trước đó, yêu cầu được trao đổi qua nhóm Telegram và vài file Google Sheets. Kết quả: dev làm sai tính năng "hoàn tiền" hai lần vì mỗi người nhớ một kiểu, mất gần 3 tuần làm lại.
Chị Lan dựng lại workflow trong Jira như sau. Chị tạo Epic "Hoàn tiền giao dịch lỗi", chia thành 4 Story. Mỗi Story chị thêm custom field Acceptance Criteria. Ví dụ Story "Người dùng yêu cầu hoàn tiền": Acceptance Criteria ghi rõ "Chỉ cho phép yêu cầu trong vòng 7 ngày kể từ giao dịch; số tiền hoàn = số tiền gốc; gửi thông báo qua app và SMS". Chị thêm trạng thái In Analysis và Ready for Dev vào workflow, đặt quy tắc: dev chỉ pick việc khi đã ở Ready for Dev.
Sau một Sprint, số lần "dev làm sai vì hiểu nhầm" giảm từ trung bình 4 xuống còn 1. Bài học: công cụ không sửa được vấn đề con người, nhưng một workflow rõ ràng với cổng "Ready for Dev" buộc mọi người dừng lại làm rõ trước khi code — đó là giá trị lớn nhất Jira mang lại cho một team non trẻ.
Tình huống 2: Team outsourcing FPT và bài toán "tài liệu lạc trôi"
Một team 30 người tại FPT Software làm dự án cho khách Nhật. Họ dùng cả Jira lẫn Confluence nhưng theo kiểu "ai thích để đâu thì để". Đặc tả nằm rải rác: một phần trong Description của Jira, một phần trong file Excel đính kèm, một phần trong Confluence cũ không ai cập nhật. Khi khách Nhật hỏi "quy tắc tính ngày giao hàng phiên bản mới nhất ở đâu?", cả team mất nửa ngày tìm và đưa ra ba câu trả lời khác nhau.
Anh Tuấn — BA Lead — đặt lại nguyên tắc "single source of truth" (một nguồn sự thật duy nhất). Mọi logic nghiệp vụ ổn định đưa vào Confluence theo cây thư mục chuẩn: mỗi module một space con, mỗi tính năng một trang. Trên Jira, phần Description của mỗi Story chỉ tóm tắt và bắt buộc dán link tới trang Confluence tương ứng. Anh dùng macro "Jira Issues" nhúng vào trang PRD trên Confluence để hiển thị trạng thái Story live. Anh cũng lập một trang Decision Log: mỗi khi khách chốt thay đổi, ghi lại ngày, lý do, người quyết định.
Sau hai tháng, thời gian trả lời câu hỏi của khách giảm rõ rệt, và quan trọng hơn, không còn cảnh "ba câu trả lời khác nhau". Bài học: vấn đề không phải thiếu công cụ, mà thiếu kỷ luật về nơi lưu. BA giỏi là người định nghĩa và bảo vệ "single source of truth".
Tình huống 3: BA mới đi làm và cái bẫy "Jira là cây checklist cá nhân"
Bạn Minh, BA fresher tại một công ty thương mại điện tử ở Hà Nội, dùng Jira rất chăm — nhưng sai cách. Cậu tạo Story cho mọi thứ cậu phải làm: "Họp với khách", "Đọc tài liệu", "Gọi điện cho dev". Backlog phình to với hàng trăm việc cá nhân lẫn lộn với yêu cầu sản phẩm. PO không phân biệt được đâu là requirement cần ưu tiên, đâu là việc vặt của Minh. Sprint planning trở nên hỗn loạn.
Mentor hướng dẫn Minh tách bạch: việc cá nhân (chuẩn bị họp, nghiên cứu) thì để vào công cụ cá nhân hoặc Sub-task, còn Story trên backlog chỉ dành cho yêu cầu mang giá trị cho người dùng cuối. Mỗi Story phải trả lời được "ai dùng và được gì". Minh dọn lại backlog, gộp việc vặt, và backlog từ 180 issue còn 60 Story thật sự có nghĩa. Bài học: Jira backlog không phải to-do list cá nhân. Nó là danh mục giá trị sản phẩm. Hiểu sai điều này khiến cả team mất phương hướng.
Hướng dẫn từng bước
Đây là quy trình BA Workflow chuẩn trên Jira–Confluence, từ lúc có yêu cầu đến lúc bàn giao cho dev.
Bước 1 — Tạo cấu trúc Epic. Khi nhận một mảng yêu cầu lớn (ví dụ từ PRD), tạo Epic tương ứng. Đặt tên Epic theo mục tiêu nghiệp vụ, không theo giải pháp kỹ thuật. Tốt: "Tăng tỷ lệ hoàn tất thanh toán". Kém: "Sửa nút thanh toán".
Bước 2 — Lập trang đặc tả trên Confluence. Với mỗi Epic, tạo một trang Confluence chứa bối cảnh, mục tiêu, Process Flow, business rules. Đây là "nhà" của yêu cầu. Dùng template "Product Requirements" có sẵn của Confluence để không phải dựng từ đầu.
Bước 3 — Chia Epic thành Story. Mỗi Story là một lát cắt giá trị, viết theo format đã học ở Bài 6. Đặt Story dưới đúng Epic (gán trường Epic Link).
Bước 4 — Điền Acceptance Criteria cho từng Story. Dùng custom field Acceptance Criteria. Viết rõ ràng, kiểm chứng được. Đây là trường dev và QA đọc kỹ nhất.
Bước 5 — Liên kết hai chiều. Trong Description của Story, dán link tới trang Confluence. Trong trang Confluence, nhúng macro Jira để hiển thị danh sách Story của Epic. Giờ ai đứng ở đâu cũng đi sang được phía kia.
Bước 6 — Đẩy Story qua workflow. Khi BA phân tích xong, kéo Story từ "In Analysis" sang "Ready for Dev". Đây là tín hiệu chính thức: yêu cầu đã sẵn sàng. Đặt quy tắc team rằng đây là điều kiện bắt buộc để dev nhận việc.
Bước 7 — Theo dõi và cập nhật khi có thay đổi. Khi yêu cầu đổi, cập nhật cả Confluence (logic) lẫn Jira (Story và Acceptance Criteria), và ghi vào Decision Log. Đừng bao giờ chỉ sửa một bên.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi cả đặc tả dài vào Description của Jira. Jira tốt cho việc ngắn, sống động; tài liệu dài thuộc về Confluence. Description nhồi 2000 từ sẽ không ai đọc và rất khó cập nhật. Mẹo: Description tóm tắt + link Confluence.
Lỗi 2 — Workflow quá nhiều trạng thái. Một số team tạo 12-15 trạng thái cho "đầy đủ". Kết quả là không ai nhớ nổi và việc bị kẹt ở trạng thái mơ hồ. Mẹo: bắt đầu với 5-7 trạng thái, chỉ thêm khi thật sự đau.
Lỗi 3 — Story không có Acceptance Criteria. Đây là lỗi chết người của BA. Story không tiêu chí chấp nhận = mời gọi hiểu nhầm. Mẹo: đặt quy tắc "no AC, no Ready for Dev".
Lỗi 4 — Confluence thành nghĩa trang tài liệu. Trang được tạo rồi không ai động tới, thông tin lỗi thời. Mẹo: gắn nhãn phiên bản và ngày cập nhật; định kỳ rà soát; xóa hoặc archive trang chết.
Lỗi 5 — Dùng Jira như công cụ giám sát con người. Nếu sếp dùng Jira để soi ai chậm, team sẽ "làm đẹp Jira" thay vì làm thật. Mẹo: BA nên giữ Jira là công cụ minh bạch tiến độ, không phải công cụ trừng phạt.
Mẹo nâng cao: học dùng JQL (Jira Query Language) để lọc nhanh. Ví dụ project = PAY AND status = "Ready for Dev" AND labels = payment cho bạn ngay danh sách việc sẵn sàng của mảng thanh toán. JQL là kỹ năng khiến BA trông "pro" trong mắt team. Ngoài ra, với team Agile, làm quen với Board (Scrum/Kanban) để nhìn luồng việc trực quan.
Bài tập thực hành
Đề bài: Bạn là BA của một app đặt đồ ăn (giả định tên FoodGo). Khách hàng phàn nàn không hủy được đơn sau khi đặt nhầm. PO giao bạn xử lý yêu cầu "Cho phép hủy đơn hàng".
- Tạo Epic: đặt tên Epic theo mục tiêu nghiệp vụ (gợi ý: liên quan đến trải nghiệm và niềm tin khách hàng), không theo giải pháp.
- Phác trang Confluence: liệt kê 4 mục bạn sẽ đưa vào trang đặc tả Epic này (bối cảnh, business rules, Process Flow, glossary...).
- Chia 3 Story dưới Epic, mỗi Story viết đúng format và viết Acceptance Criteria gồm tối thiểu 3 điều kiện kiểm chứng được. Gợi ý suy nghĩ về các business rule: hủy trong vòng bao lâu? Đã giao cho shipper thì sao? Hoàn tiền thế nào?
- Thiết kế workflow: vẽ chuỗi trạng thái bạn muốn áp dụng và giải thích vì sao có "In Analysis" và "Ready for Dev".
- Viết một câu JQL để lọc tất cả Story của Epic này đang ở trạng thái Ready for Dev.
Tóm tắt
- Jira quản lý công việc và requirements động, theo cấu trúc Epic → Story → Sub-task, với custom field quan trọng nhất là Acceptance Criteria, và một workflow có cổng "In Analysis" và "Ready for Dev" để đảm bảo chất lượng trước khi dev nhận việc.
- Confluence là kho kiến thức tĩnh: BRD/PRD, business rules, biên bản họp, decision log. Nguyên tắc phân chia: cái gì cần làm vào Jira, cái gì cần biết vào Confluence.
- Sức mạnh thật sự là liên kết hai chiều giữa Jira và Confluence, tạo traceability mà không phải copy-paste.
- BA giỏi không chạy theo công cụ xịn, mà thiết lập và bảo vệ kỷ luật: một nguồn sự thật duy nhất, workflow gọn, và "no AC, no Ready for Dev".
- Học thêm JQL và Board để vận hành nhanh và chuyên nghiệp.