Mở đầu — vì sao bài này quan trọng
Trong suốt khoá học, bạn đã quen với việc dùng Confluence để viết tài liệu dưới dạng page — những trang văn bản dài, có heading, bảng tĩnh, hình ảnh. Cách làm này tuyệt vời cho BRD, biên bản họp hay tài liệu mô tả nghiệp vụ. Nhưng có một loại thông tin mà page truyền thống xử lý rất tệ: dữ liệu có cấu trúc và thường xuyên thay đổi.
Hãy thử nghĩ về một danh sách yêu cầu (requirements) với 80 dòng, mỗi dòng có trạng thái, người phụ trách, độ ưu tiên, link sang JIRA. Nếu bạn để nó trong một bảng Confluence thường (table macro), bạn sẽ nhanh chóng đau đầu: không lọc được, không sắp xếp được theo cột, mỗi lần sửa một ô là phải vào edit cả trang, và khi sếp hỏi "cho tôi xem những requirement nào đang Pending và do chị Lan phụ trách" thì bạn chỉ biết... cuộn chuột tìm bằng mắt.
Đây chính là khoảng trống mà Confluence Databases ra đời để lấp. Đây là một tính năng tương đối mới trên Confluence Cloud (Atlassian giới thiệu và mở rộng dần từ năm 2023–2024), cho phép bạn tạo những bảng dữ liệu có cấu trúc thực sự — giống như Notion Databases hay Airtable thu nhỏ — ngay bên trong Confluence. Là một BA, bạn sẽ dùng nó để quản lý requirement, theo dõi quyết định dự án, lập danh mục stakeholder, hay làm bảng tra cứu (lookup table) mà toàn team cùng cập nhật.
Bài này sẽ giúp bạn hiểu Confluence Databases là gì, khác bảng thường ra sao, và quan trọng nhất: khi nào nên dùng và khi nào không.
Khái niệm cốt lõi
Database không phải là page, cũng không phải table macro
Điểm dễ nhầm đầu tiên: trong Confluence Cloud hiện có ba thứ trông giống bảng nhưng bản chất khác nhau hoàn toàn.
- Table thường (table macro): bảng tĩnh nằm trong một page. Bạn gõ tay từng ô. Không có kiểu dữ liệu (mọi ô đều là text). Không lọc, không sort động được.
- Database: một loại content riêng, đứng độc lập như một page. Mỗi cột có một kiểu dữ liệu (data type) rõ ràng. Có thể lọc, sắp xếp, nhóm dữ liệu động.
- Database được nhúng (embed) vào page: bạn tạo database một lần, rồi chèn nó (hoặc một "view" đã lọc của nó) vào nhiều page khác nhau. Sửa ở nguồn, mọi nơi nhúng đều cập nhật theo.
Các kiểu cột (field types) bạn cần biết
Mỗi cột trong Confluence Database mang một data type. Những kiểu thường dùng nhất cho công việc BA:
- Text — văn bản tự do (tên requirement, mô tả ngắn).
- Number — số (story point, effort ước lượng, số tiền).
- Date — ngày tháng, sort được theo thời gian.
- Label / Select — chọn từ danh sách định sẵn (Priority: High/Medium/Low; Status: Draft/Reviewing/Approved).
- User — gắn với một người dùng thật trong Atlassian, hiển thị avatar, có thể mention.
- Checkbox — đúng/sai (đã review chưa, đã ký duyệt chưa).
- Link / URL — đường dẫn ra ngoài.
- Jira issue / Confluence page — đây là điểm mạnh đặc biệt: một ô có thể liên kết trực tiếp tới một issue JIRA hoặc một page Confluence, kéo theo thông tin sống (live) như trạng thái issue.
Lọc, sắp xếp, nhóm (Filter, Sort, Group)
Đây là lý do tồn tại của database. Trên thanh công cụ phía trên bảng, bạn có thể:
- Filter: "chỉ hiện dòng nào Status = Pending AND Owner = Lan".
- Sort: sắp xếp theo Priority giảm dần, rồi theo Due date tăng dần.
- Group: gom các dòng theo cột — ví dụ nhóm theo Status để thấy ngay bao nhiêu requirement đang ở mỗi giai đoạn.
Database sống ở đâu
Database là một content nằm trong Space, giống page. Nó tuân theo phân quyền của Space đó (kiến thức bạn đã học ở bài Permissions). Bạn có thể đặt nó trong cây trang, đặt làm con của một page dự án, và nhúng nó vào bất kỳ page nào trong cùng instance.
Tình huống thực tế
Ví dụ 1 — Requirements Traceability tại một fintech ở TP.HCM
Công ty giả định MoMoPay Lab (đội sản phẩm ví điện tử, khoảng 12 người) đang làm tính năng "Chuyển tiền theo lịch". BA tên Trang phụ trách 64 requirement. Trước đây chị để tất cả trong một bảng table macro dài 64 dòng. Vấn đề xuất hiện khi PM hỏi mỗi sáng: "Hôm nay còn bao nhiêu requirement chưa được dev xác nhận?"
Trang chuyển bảng đó sang một Confluence Database với các cột: Req ID (Text), Mô tả (Text), Priority (Select: P0/P1/P2), Owner (User), Status (Select: Draft/Confirmed/Built/Tested), và Jira Story (kiểu Jira issue).
Bài học rút ra: chỉ riêng việc đổi cột Jira Story sang kiểu liên kết JIRA đã loại bỏ thao tác copy trạng thái thủ công. Khi dev đổi Story sang "In Progress" trong JIRA, database tự phản ánh. Mỗi sáng, Trang chỉ cần một view đã lọc Status = Draft và Priority = P0 để trả lời PM trong 5 giây thay vì cuộn 64 dòng. Sau hai sprint, chị ước tính tiết kiệm khoảng 30 phút mỗi ngày cho việc cập nhật và tra cứu.
Ví dụ 2 — Decision Log dùng chung tại một công ty outsourcing ở Đà Nẵng
Axon Software (công ty gia công cho khách Nhật, đội dự án 25 người) có thói quen xấu: các quyết định kiến trúc và nghiệp vụ rải rác trong hàng chục biên bản họp. Khi khách hỏi "vì sao tháng trước chốt dùng OTP qua SMS thay vì email?", không ai tìm lại được.
BA lead lập một Decision Log database đặt ở Space chung của dự án, với cột: Quyết định (Text), Ngày (Date), Người quyết định (User), Lĩnh vực (Select: Tech/Business/UX/Compliance), Trạng thái (Select: Proposed/Approved/Superseded), và Trang họp liên quan (kiểu Confluence page).
Mỗi page biên bản họp nhúng một view của database này — view đã lọc Lĩnh vực tương ứng với cuộc họp — nên mỗi nhóm chỉ thấy phần liên quan. Còn BA lead xem toàn bộ.
Bài học rút ra: vì database là một nguồn dữ liệu duy nhất được nhúng nhiều nơi, không còn chuyện mỗi biên bản giữ một bản sao quyết định rồi lệch nhau. Khi một quyết định bị thay thế, chỉ cần đổi Trạng thái sang Superseded ở một chỗ, mọi nơi nhúng cập nhật theo. Sáu tháng sau, khi audit từ phía khách Nhật yêu cầu lịch sử quyết định, BA lead xuất một view sort theo Ngày và bàn giao trong vòng một buổi chiều.
Ví dụ 3 — Stakeholder & Vendor registry tại một startup logistics ở Jakarta
KirimCepat (startup giao vận Indonesia, mở rộng sang thị trường Việt Nam) cần một danh bạ stakeholder và nhà cung cấp tích hợp API (hãng vận chuyển, cổng thanh toán). BA dùng một database với cột: Tên đối tác (Text), Loại (Select: Carrier/Payment/Maps), Người liên hệ chính (User hoặc Text), SLA cam kết (Number — giờ), Trạng thái tích hợp (Select), và Tài liệu API (Link).
Bài học rút ra: đây là dạng lookup table — bảng tra cứu mà nhiều người cùng đọc, ít người sửa. Database giúp lọc nhanh "carrier nào có SLA dưới 24 giờ và đã tích hợp xong". Tuy nhiên BA của KirimCepat cũng nhận ra một giới hạn quan trọng: khi danh sách vượt vài trăm dòng và cần các báo cáo tính toán phức tạp (tổng chi phí theo quý, biểu đồ xu hướng), Confluence Database bắt đầu đuối — đó là lúc cần cân nhắc công cụ chuyên về dữ liệu, chứ đừng ép Confluence làm thay.
Hướng dẫn từng bước
Dưới đây là quy trình tạo và dùng một Confluence Database cho mục đích quản lý requirement. Giao diện Confluence Cloud thay đổi theo thời gian, nhưng luồng tổng thể ổn định.
- Tạo database mới. Trong Space của bạn, chọn Create và tìm loại nội dung Database (thay vì Page hay Whiteboard). Đặt tên rõ ràng, ví dụ "Requirements – Chuyển tiền theo lịch".
- Định nghĩa cột và kiểu dữ liệu. Đừng vội nhập dữ liệu. Trước tiên thiết kế cột: bấm thêm cột, đặt tên, rồi chọn đúng data type. Với cột Status hãy chọn Select và khai báo sẵn các giá trị (Draft, Confirmed, Built, Tested). Với cột người phụ trách chọn User. Với cột link sang JIRA chọn kiểu Jira issue.
- Nhập hoặc dán dữ liệu. Bạn có thể gõ từng dòng, hoặc dán từ một bảng có sẵn. Khi dán, kiểm tra lại các ô Select và User đã ánh xạ đúng — đây là chỗ hay lỗi.
- Tạo view và áp filter/sort/group. Tạo một view tên "P0 chưa confirmed", đặt filter
Priority = P0 AND Status = Draft. Tạo thêm view "Theo người phụ trách" group theo Owner. Mỗi view lưu lại độc lập.
- Nhúng database vào page. Mở page BRD hoặc trang tổng quan dự án, gõ
/để mở menu chèn, tìm Database và chọn database vừa tạo. Bạn có thể chọn nhúng nguyên bảng hay chỉ một view cụ thể. Sửa dữ liệu ở nguồn, page nhúng tự cập nhật.
- Kiểm tra phân quyền. Vì database tuân theo quyền của Space, hãy chắc rằng những người cần đọc/sửa có quyền tương ứng. Nếu nhúng vào page mà người xem không có quyền với database, họ sẽ không thấy dữ liệu.
- Bảo trì định kỳ. Mỗi cuối sprint, rà lại các giá trị Select có còn hợp lý không, dọn dòng đã đóng, và kiểm tra các link JIRA còn sống.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng database cho mọi thứ. Database hấp dẫn đến mức nhiều BA muốn biến cả BRD thành bảng. Đừng. Database tốt cho dữ liệu có cấu trúc, nhiều dòng, hay thay đổi, cần lọc. Văn bản giải thích nghiệp vụ, sơ đồ, ngữ cảnh — vẫn nên là page bình thường. Quy tắc đơn giản: nếu bạn thấy mình muốn "lọc" hay "sắp xếp" nội dung, hãy dùng database; nếu bạn muốn "đọc từ trên xuống dưới", hãy dùng page.
Lỗi 2 — Để cột quan trọng là Text thay vì Select/User/Date. Đây là lỗi phá hỏng toàn bộ giá trị của database. Nếu Status là Text, mỗi người gõ một kiểu ("Done", "done", "Hoàn thành") và filter trở nên vô dụng. Luôn dùng Select cho trạng thái/độ ưu tiên, User cho người, Date cho ngày.
Lỗi 3 — Nhầm database (Cloud) với Confluence Data Center. Tính năng Databases hiện là của Confluence Cloud. Nếu công ty bạn chạy Data Center (bản tự host), tính năng này có thể chưa có; khi đó người ta thường thay thế bằng plugin Marketplace như Table Filter and Charts. Hãy xác nhận bạn đang dùng bản nào trước khi hứa hẹn với team.
Lỗi 4 — Ép database làm việc của một database thật. Confluence Database không phải Airtable hay SQL. Nó không làm được công thức tính toán liên cột phức tạp, không xử lý mượt hàng nghìn dòng, không vẽ biểu đồ nâng cao. Đến ngưỡng đó, hãy chuyển dữ liệu sang công cụ phù hợp.
Mẹo 1 — Bắt đầu từ cột, không phải dữ liệu. Dành 10 phút thiết kế schema (tên cột + kiểu) trước khi nhập, sẽ tiết kiệm hàng giờ sửa lại.
Mẹo 2 — Tận dụng cột Jira issue. Với BA, đây là vũ khí mạnh nhất: một bảng requirement liên kết sống với JIRA, xoá bỏ việc đồng bộ trạng thái thủ công.
Mẹo 3 — Một nguồn, nhiều view. Đừng tạo nhiều bản sao database cho mỗi nhóm. Tạo một database, rồi tạo nhiều view đã lọc và nhúng đúng view vào đúng trang.
Bài tập thực hành
Hãy thực hiện trên một Space thử nghiệm (sandbox) để không ảnh hưởng dữ liệu thật.
- Tạo một Requirements database với tối thiểu 6 cột, trong đó bắt buộc có: một cột Select (Status, ít nhất 4 giá trị), một cột User (Owner), một cột Date (Due date), và một cột kiểu Jira issue. Nhập 10 dòng dữ liệu mẫu.
- Tạo 3 view khác nhau trên cùng database: (a) view "Quá hạn" lọc Due date trước hôm nay và Status chưa Done; (b) view "Theo người" group theo Owner; (c) view "P0 ưu tiên" lọc Priority cao nhất và sort theo Due date.
- Nhúng view (a) vào một page "Dashboard dự án" và viết một đoạn ngắn giải thích bảng đó cho người đọc.
- Câu hỏi suy ngẫm (viết ra giấy): Trong dự án thật của bạn, đâu là một danh sách hiện đang nằm trong table macro hoặc Excel mà sẽ hưởng lợi khi chuyển sang database? Liệt kê các cột và kiểu dữ liệu bạn sẽ dùng, và nêu một lý do tại sao nó không nên là database (nếu có).
Tóm tắt
Confluence Databases là tính năng của Confluence Cloud cho phép tạo bảng dữ liệu có cấu trúc thực sự — mỗi cột có kiểu dữ liệu, hỗ trợ lọc, sắp xếp, nhóm, và nhúng nhiều view từ một nguồn duy nhất. Với BA, nó đặc biệt mạnh khi quản lý requirement, decision log, hay danh bạ stakeholder, nhất là nhờ cột kiểu Jira issue liên kết sống với JIRA.
Ba điều cần nhớ: (1) Database khác hẳn table macro nhờ kiểu dữ liệu và khả năng lọc/sort/group; (2) Chọn đúng data type cho cột (Select, User, Date) là yếu tố quyết định giá trị; (3) Database tốt cho dữ liệu có cấu trúc, hay thay đổi, cần truy vấn — không phải để thay thế văn bản, cũng không phải để thay một database/Airtable thật. Dùng đúng chỗ, nó sẽ tiết kiệm cho bạn rất nhiều thời gian cập nhật và tra cứu mỗi ngày.