Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Sales/BD, công cụ làm việc của bạn xoay quanh CRM (HubSpot, Salesforce, hoặc một file Google Sheet pipeline tự dựng), email theo dõi deal, và những cuộc gọi. Mọi thứ đo bằng số lượng lead, tỷ lệ chốt, doanh thu. Khi bước sang BA, bạn sẽ thấy "phòng làm việc" của mình chuyển sang một bộ đôi gần như mặc định trong mọi công ty công nghệ: Jira và Confluence. Đây là hai phần mềm của Atlassian, và ở Việt Nam — từ FPT Software, MoMo, Tiki, VNG cho đến các startup SaaS nhỏ — chúng gần như là tiêu chuẩn ngành.
Vì sao bài này quan trọng đến mức xứng đáng có riêng một buổi? Bởi vì nhiều ex-Sales chuyển sang BA biết viết requirement tốt, biết phỏng vấn stakeholder, nhưng lại lúng túng khi được giao quản lý một Confluence space hoặc một board Jira. Họ tạo trang lộn xộn, đặt task không ai tìm thấy, viết spec mỗi nơi một kiểu. Hệ quả: dev hỏi "spec ở đâu?", PM hỏi "tính năng này trạng thái gì rồi?", và bạn mất uy tín dù chuyên môn phân tích vốn rất ổn.
Hãy nhớ: trong vai trò BA, một phần lớn giá trị bạn tạo ra không nằm ở việc bạn biết gì, mà ở việc thông tin bạn nắm có được tổ chức để cả team truy cập và tin tưởng hay không. Jira và Confluence chính là hệ thống lưu trữ "trí nhớ chung" của dự án. Làm chủ chúng giúp bạn từ một người "biết phân tích" trở thành một người "vận hành được luồng thông tin của cả team". Bài này tập trung riêng vào workflow — cách bạn dùng hai công cụ này hằng ngày — chứ không lan sang lý thuyết viết SRS hay user story (đã có ở các bài khác).
Khái niệm cốt lõi
Phân vai: Confluence là "thư viện", Jira là "dây chuyền"
Cách dễ nhớ nhất để không bao giờ nhầm hai công cụ:
- Confluence = nơi lưu kiến thức và tài liệu ở dạng tương đối ổn định. Đây là thư viện. BRD, SRS, sơ đồ quy trình, biên bản họp, quyết định thiết kế — tất cả nằm đây. Một trang Confluence sống lâu, được đọc đi đọc lại nhiều lần.
- Jira = nơi quản lý công việc đang chạy, có vòng đời và trạng thái. Đây là dây chuyền sản xuất. Mỗi mục công việc (issue) di chuyển từ "To Do" → "In Progress" → "Done". Một issue Jira sống ngắn, hoàn thành xong là đóng lại.
Cấu trúc Confluence cho một dự án BA
Mỗi dự án nên có một Space riêng trong Confluence. Bên trong, bạn xây một cây trang (page tree) có thứ bậc rõ ràng. Một bộ khung phổ biến mà tôi khuyên các BA mới áp dụng:
- Index page (trang chỉ mục) của dự án — trang gốc, đóng vai trò "mục lục" và "trang chủ". Người mới vào dự án mở trang này là thấy ngay: tổng quan dự án, link đến BRD, SRS, RTM, danh sách stakeholder, lịch họp.
- BRD (Business Requirements Document) — tài liệu yêu cầu nghiệp vụ cấp cao.
- SRS (Software Requirements Specification) — đặc tả chi tiết.
- RTM (Requirements Traceability Matrix) — ma trận truy vết, ánh xạ requirement sang user story sang test case.
- Một trang spec riêng cho mỗi feature — đây là điểm mấu chốt. Đừng dồn mọi tính năng vào một trang khổng lồ. Mỗi feature một trang, đặt làm trang con của một trang cha "Feature Specs".
- Meeting notes — biên bản họp, dùng template có sẵn của Confluence.
Cấu trúc Jira: hệ thống phân cấp issue
Jira tổ chức công việc theo nhiều tầng. BA cần nắm vững ba tầng chính:
- Epic — một khối công việc lớn, thường tương ứng một mục tiêu nghiệp vụ hoặc một module. Ví dụ: "Onboarding khách hàng mới", "Thanh toán qua ví điện tử". Epic là cầu nối tự nhiên giữa ngôn ngữ business (vốn quen thuộc với ex-Sales) và ngôn ngữ kỹ thuật.
- Story (User Story) — một đơn vị giá trị giao được cho người dùng, đủ nhỏ để hoàn thành trong một sprint. Ví dụ: "Là khách hàng, tôi muốn nhận OTP qua SMS để xác thực số điện thoại."
- Task / Sub-task — công việc kỹ thuật cụ thể, thường do dev tự chia.
Sợi dây liên kết: Jira ↔ Confluence
Atlassian thiết kế hai công cụ để "nói chuyện" với nhau. Trong một story Jira, bạn dán link đến trang spec Confluence; ngược lại, trên trang Confluence bạn có thể nhúng (embed) Jira issue để hiển thị trạng thái live của các story liên quan. Khi dev mở trang spec, họ thấy ngay "feature này có 8 story, 5 đã Done, 3 đang In Progress". Đây chính là "traceability" mà mọi nhà tuyển dụng BA muốn thấy ở bạn.
Tình huống thực tế
Tình huống 1: BA mới tại một startup SaaS ở TP.HCM dọn dẹp "bãi rác" Jira
Minh, một cựu BD sau 3 năm bán giải pháp ERP, gia nhập một startup SaaS nhân sự (HRtech) khoảng 25 người ở Quận 1. Tuần đầu, anh mở board Jira và choáng: 240 issue tồn đọng, hơn một nửa không có Epic, mô tả kiểu "fix màn hình lương", không ai gắn link spec. Khi dev hỏi "spec tính năng chấm công ở đâu?", câu trả lời thường là "hỏi anh A, mà anh A nghỉ rồi".
Minh dành hai tuần làm ba việc. Một, tạo 6 Epic theo module nghiệp vụ: Tuyển dụng, Chấm công, Bảng lương, Đánh giá, Báo cáo, Quản trị hệ thống. Hai, gán toàn bộ story tồn vào đúng Epic, đóng 40 issue trùng lặp hoặc lỗi thời. Ba, với mỗi feature đang phát triển, anh tạo một trang spec Confluence và dán link vào phần Description của story.
Kết quả sau một tháng: thời gian dev hỏi lại requirement trong sprint giảm rõ rệt — theo ghi nhận của PM, số câu hỏi "spec đâu?" trong kênh Slack giảm từ khoảng 15 câu/sprint xuống còn 3-4. Bài học: giá trị đầu tiên một ex-Sales mang lại không phải kỹ thuật cao siêu, mà là sự ngăn nắp và khả năng tổ chức thông tin — một kỹ năng bạn đã rèn khi quản lý pipeline hàng chục deal cùng lúc.
Tình huống 2: Confluence cứu một cuộc tranh cãi "ai nói gì" tại công ty fintech
Tại một công ty fintech ví điện tử quy mô trung bình ở Hà Nội, có một tình huống quen thuộc: 6 tuần sau khi release tính năng "chia hóa đơn" (split bill), bộ phận vận hành phàn nàn rằng logic làm tròn số tiền sai, gây lệch vài trăm đồng mỗi giao dịch. Cuộc họp căng thẳng, mọi người đổ lỗi qua lại — "BA không nói rõ", "dev tự ý làm tròn xuống".
May mắn là Lan, BA của dự án (cũng xuất thân Sales bảo hiểm), đã ghi rõ business rule làm tròn trong trang spec Confluence của feature, kèm một bảng ví dụ số liệu cụ thể. Cô mở lịch sử version, chỉ ra rằng quy tắc "làm tròn lên đến đồng gần nhất, phần dư cộng vào người tạo hóa đơn" đã được chốt từ phiên bản ngày 12/3, có comment xác nhận của trưởng nhóm vận hành. Cuộc tranh cãi kết thúc trong 10 phút. Hóa ra dev đã đọc nhầm một phiên bản nháp cũ.
Bài học: Confluence với version history và comment không chỉ là nơi lưu tài liệu — nó là "bằng chứng pháp lý nội bộ" của dự án. Là BA, bạn nên chốt mọi business rule quan trọng thành văn bản có người xác nhận, thay vì gật đầu miệng trong cuộc họp. Thói quen này, ex-Sales vốn quen làm khi soạn hợp đồng và điều khoản, chuyển sang BA cực kỳ hợp.
Tình huống 3: Dùng Epic làm cầu nối với sếp business
Tại một công ty SaaS giáo dục, Tuấn — ex-BD — nhận ra giám đốc kinh doanh không bao giờ chịu mở Jira vì "rối quá". Nhưng sếp lại liên tục hỏi "tính năng lớp học trực tuyến bao giờ xong?". Thay vì bắt sếp đọc 30 story lẻ, Tuấn dùng tính năng Roadmap (Timeline) của Jira, vốn hiển thị tiến độ ở cấp Epic dưới dạng thanh thời gian trực quan. Anh chụp màn hình roadmap mỗi thứ Sáu gửi vào nhóm lãnh đạo: "Epic Lớp học trực tuyến: 70% — dự kiến xong sprint sau."
Bài học: Epic là tầng ngôn ngữ mà người business hiểu được. Ex-Sales có lợi thế tự nhiên ở đây vì bạn quen "dịch" giữa thế giới kỹ thuật và thế giới ra quyết định mua hàng. Hãy dùng Epic và Roadmap làm cầu nối báo cáo, thay vì bắt stakeholder lội vào chi tiết.
Hướng dẫn từng bước
Đây là quy trình thiết lập và vận hành một dự án mới trên Jira + Confluence, từ con số 0:
Bước 1 — Tạo Confluence Space và Index page. Tạo một space mới cho dự án. Tạo trang gốc đặt tên đúng tên dự án, viết một đoạn tổng quan ngắn (mục tiêu, phạm vi, stakeholder chính). Đây là trang chỉ mục — mọi link quan trọng sẽ neo về đây.
Bước 2 — Dựng khung cây trang. Tạo các trang con: BRD, SRS, RTM, "Feature Specs" (trang cha), "Meeting Notes" (trang cha). Dùng template có sẵn của Confluence cho meeting notes và product requirements để tiết kiệm thời gian.
Bước 3 — Tạo Jira Project và định nghĩa Epic. Chọn template Scrum hoặc Kanban tùy team. Tạo các Epic tương ứng với từng module/mục tiêu nghiệp vụ lớn. Đặt tên Epic theo ngôn ngữ business để stakeholder hiểu.
Bước 4 — Với mỗi feature, tạo một trang spec Confluence riêng. Đặt nó làm con của "Feature Specs". Trong trang ghi: mô tả nghiệp vụ, user stories liên quan, acceptance criteria, business rules, mockup/wireframe, và các quyết định mở (open questions).
Bước 5 — Tạo Story trong Jira và liên kết. Mỗi story đặt dưới đúng Epic. Trong phần Description, viết tóm tắt ngắn và dán link đến trang spec Confluence đầy đủ — đừng copy cả spec vào đây. Điền Priority, Acceptance Criteria, gán Sprint.
Bước 6 — Nhúng Jira vào Confluence (hai chiều). Trên trang spec, dùng macro "Jira Issues/Jira Roadmap" để nhúng danh sách story của feature. Bây giờ trang spec hiển thị trạng thái live.
Bước 7 — Vận hành nhịp hằng ngày. Mỗi standup, BA kiểm tra board: story nào kẹt, story nào thiếu thông tin. Khi requirement thay đổi, sửa trên trang Confluence trước (version tự lưu), rồi comment vào story Jira báo dev "spec đã cập nhật mục X".
Bước 8 — Đóng vòng với RTM. Cập nhật ma trận truy vết: requirement → story → test case. Đây là tài liệu giúp bạn chứng minh "mọi yêu cầu đều đã được làm và kiểm thử" khi nghiệm thu.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi cả spec vào Description của Jira. Ticket phình to, không ai maintain. Mẹo: Description chỉ chứa tóm tắt 3-5 dòng + acceptance criteria + link Confluence. Spec đầy đủ luôn ở Confluence.
Lỗi 2 — Story không gắn Epic. Board trở thành mớ hỗn độn, không báo cáo được cho sếp. Mẹo: Đặt quy ước "không tạo story nào mà không có Epic". Mỗi tuần lọc các story "không Epic" để dọn.
Lỗi 3 — Confluence loạn xạ, mỗi người tạo trang một kiểu. Sáu tháng sau không ai tìm được gì. Mẹo: Chuẩn hóa cấu trúc cây trang ngay từ đầu, đặt tên trang theo quy ước nhất quán (ví dụ: "[Spec] Tên feature"), và pin trang Index lên đầu space.
Lỗi 4 — Cập nhật spec mà không báo dev. Bạn sửa trên Confluence nhưng dev vẫn làm theo bản cũ. Mẹo: Sau mỗi lần sửa spec đáng kể, comment vào story Jira hoặc @mention dev, ghi rõ phần nào thay đổi.
Lỗi 5 — Dùng comment Jira/Confluence như chat cá nhân. Thông tin quyết định trôi mất trong dòng comment dài. Mẹo: Quyết định quan trọng phải được "nâng cấp" thành nội dung chính thức trên trang spec, không để nằm trong comment.
Mẹo nâng cao — học JQL. JQL (Jira Query Language) là cách lọc issue bằng câu lệnh, ví dụ project = ABC AND status = "In Progress" AND assignee = currentUser(). Biết chút JQL giúp bạn tự tạo bộ lọc và dashboard, trông rất "pro" trong mắt team. Đây cũng là kỹ năng hay được hỏi khi phỏng vấn.
Mẹo — dùng template. Tạo sẵn một template trang spec của riêng bạn (các mục cố định: mô tả, user story, AC, business rule, mockup, open questions). Mỗi feature mới chỉ việc nhân bản, đảm bảo nhất quán và nhanh.
Bài tập thực hành
- Dựng khung dự án giả định. Tạo một Confluence Space (dùng bản miễn phí của Atlassian, miễn phí đến 10 người dùng) cho một dự án giả định: "App đặt lịch khám tại phòng khám tư". Tạo Index page, BRD, và một trang cha "Feature Specs".
- Viết một trang spec hoàn chỉnh cho một feature. Chọn feature "Đặt lịch hẹn online". Viết trang spec gồm: mô tả nghiệp vụ, 3 user story, acceptance criteria cho mỗi story, ít nhất 2 business rule (ví dụ: không cho đặt lịch trong vòng 2 giờ trước giờ khám).
- Dựng Epic và Story trong Jira. Tạo một Jira project, tạo Epic "Quản lý lịch hẹn", thêm 3 story tương ứng spec ở bài 2. Mỗi story dán link về trang Confluence.
- Liên kết hai chiều. Nhúng (embed) danh sách Jira story vào trang spec Confluence bằng macro Jira. Chụp màn hình kết quả.
- Viết một câu JQL. Viết câu JQL lọc tất cả story thuộc Epic "Quản lý lịch hẹn" đang ở trạng thái "To Do". Ghi lại câu lệnh và giải thích từng phần.
- Tự phản tư. Viết một đoạn ngắn (150 từ) đối chiếu: cách bạn từng quản lý pipeline trong CRM hồi làm Sales giống và khác gì cách quản lý board Jira? Kỹ năng tổ chức nào chuyển được sang?
Tóm tắt
Jira và Confluence là bộ đôi công cụ "trí nhớ chung" của hầu hết team công nghệ tại Việt Nam, và làm chủ chúng là kỹ năng vận hành thiết yếu của BA. Hãy ghi nhớ sự phân vai: Confluence là thư viện lưu tài liệu sống lâu (BRD, SRS, RTM, mỗi feature một trang spec, có version tự động), còn Jira là dây chuyền quản lý công việc có vòng đời (Epic → Story → Task). Nguyên tắc vàng là tài liệu ở Confluence, công việc ở Jira, và hai bên liên kết hai chiều để tạo traceability.
Ex-Sales có lợi thế tự nhiên: khả năng tổ chức thông tin (rèn từ quản lý pipeline), thói quen chốt cam kết thành văn bản (rèn từ soạn điều khoản hợp đồng), và năng lực "dịch" giữa ngôn ngữ business và kỹ thuật (qua tầng Epic và Roadmap). Tránh các lỗi phổ biến — nhồi spec vào ticket, story mồ côi Epic, cấu trúc Confluence loạn xạ, sửa spec mà quên báo dev — và bạn sẽ nhanh chóng trở thành chỗ dựa thông tin đáng tin cậy của cả team. Đó chính là lúc bạn không còn là "ex-Sales đang học BA", mà là một BA thực thụ.