Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa gia nhập một công ty fintech 200 người ở TP.HCM với tư cách Business Analyst. Ngày đầu tiên, sếp gửi bạn một link Confluence và nói: "Tài liệu BRD của dự án thanh toán nằm đâu đó trong này, em tự tìm nhé." Bạn mở ra và choáng váng: 47 space khác nhau, tên kiểu "Tài liệu Anh Hùng", "Project ABC (cũ)", "Test space — đừng xóa", "Backup BA team v2 final". Không có quy tắc nào, không biết bắt đầu từ đâu. Sau 40 phút mò mẫm, bạn vẫn không tìm thấy tài liệu cần.
Đây là cái giá của một kiến trúc Space tồi. Confluence không chỉ là nơi "viết tài liệu" — nó là bộ não tổ chức của cả công ty. Và bộ não đó được phân vùng bằng các Space. Nếu bạn — với vai trò BA — không hiểu cách thiết kế kiến trúc Space, bạn sẽ tạo ra một mớ hỗn loạn mà chính bạn và đồng nghiệp phải trả giá hằng ngày bằng thời gian tìm kiếm, tài liệu trùng lặp và thông tin lỗi thời không ai dám xóa.
Bài này tập trung duy nhất vào kiến trúc Space — cách phân loại, tổ chức và bố trí các Space ở cấp độ toàn tổ chức. Chúng ta sẽ không đi sâu vào cách tạo Page hay Macro (đó là việc của các bài khác), mà nhìn ở tầm "quy hoạch đô thị": làm sao để cả hệ thống Confluence của công ty bạn có cấu trúc rõ ràng, dễ điều hướng và bền vững theo thời gian.
Khái niệm cốt lõi
Space là gì và tại sao nó là đơn vị kiến trúc
Trong Confluence, Space là một vùng chứa độc lập, có ranh giới riêng về phân quyền, điều hướng và nhận diện. Mỗi Space có:
- Space Key — mã định danh ngắn, duy nhất (ví dụ
PAY,BAKB,HRKB). Đây là thứ xuất hiện trong URL và bạn nên đặt thật cẩn thận vì khó đổi về sau. - Homepage — trang chủ, là điểm hạ cánh khi ai đó mở Space.
- Cây trang (Page tree) — cấu trúc phân cấp các trang bên trong.
- Quyền (Space permissions) — ai được xem, sửa, quản trị riêng cho Space đó.
Ba loại Space trong thực tế
Atlassian gợi ý nhiều template, nhưng trong thực tế làm việc, bạn chỉ cần nắm vững ba loại Space cốt lõi. Mỗi loại trả lời một câu hỏi khác nhau về "thông tin này thuộc về ai".
1. Team Space — không gian của một đội/phòng ban. Đây là nơi chứa kiến thức gắn với một nhóm người cố định: phòng BA, đội Marketing, team QA, phòng Nhân sự. Nội dung mang tính lâu dài và xoay quanh cách đội đó vận hành: quy trình nội bộ, onboarding nhân viên mới, biên bản họp định kỳ, chuẩn làm việc (working agreement), danh bạ liên hệ. Đặc trưng: tồn tại bao lâu đội còn tồn tại, không gắn với một dự án cụ thể nào.
2. Project Space — không gian của một dự án. Đây là nơi chứa toàn bộ tài liệu (artifact) của một dự án có điểm bắt đầu và kết thúc: BRD, SRS, user story, sơ đồ luồng nghiệp vụ, ghi chú quyết định, kế hoạch UAT. Đặc trưng quan trọng: Project Space có vòng đời — khi dự án kết thúc, Space này sẽ được archive (lưu trữ) chứ không xóa, để còn truy vết về sau. Một dự án = một Space, đó là nguyên tắc vàng giúp tránh tình trạng tài liệu của 5 dự án trộn lẫn trong một chỗ.
3. Knowledge Base Space — không gian kiến thức dùng chung. Đây là nơi chứa kiến thức ổn định, được nhiều người tra cứu và sống lâu hơn bất kỳ dự án nào: từ điển thuật ngữ nghiệp vụ (glossary), tài liệu mô tả hệ thống hiện hữu (as-is documentation), quy chuẩn viết user story của công ty, các quyết định kiến trúc, FAQ cho khách hàng nội bộ. Knowledge Base hướng tới tra cứu chứ không phải cộng tác đang diễn ra. Đây thường là Space có giá trị bền vững nhất nhưng cũng bị bỏ bê nhiều nhất nếu không có người chịu trách nhiệm.
Personal Space — và lý do bạn nên cẩn thận với nó
Confluence còn có Personal Space — không gian cá nhân, tạo tự động cho mỗi user. Nó hữu ích cho nháp, ghi chú riêng, thử nghiệm. Nhưng đây là cái bẫy kiến trúc: nhiều BA viết BRD hoàn chỉnh trong Personal Space của mình rồi quên chuyển sang Project Space. Khi người đó nghỉ việc hoặc bị khóa tài khoản, tài liệu quan trọng "biến mất" cùng họ. Nguyên tắc: Personal Space chỉ để nháp; mọi tài liệu chính thức phải sống trong Team, Project hoặc Knowledge Base Space.
Nguyên tắc quyết định: thông tin này thuộc loại Space nào?
Khi bạn không chắc một tài liệu nên đặt ở đâu, hãy hỏi ba câu:
- Nó gắn với một nhóm người hay một mục tiêu có hạn? Gắn nhóm người → Team. Gắn mục tiêu có hạn → Project.
- Nó sẽ chết khi dự án kết thúc, hay sống mãi để tra cứu? Chết theo dự án → Project. Sống lâu → Knowledge Base.
- Ai sẽ tìm nó sau 1 năm nữa, và họ tìm bằng từ khóa gì? Câu này giúp bạn đặt tên Space và Space Key sao cho dễ tìm.
Tình huống thực tế
Tình huống 1 — Công ty fintech Việt Nam tái cấu trúc 47 Space hỗn loạn
Một công ty ví điện tử ở Hà Nội (gọi là MoMoney, khoảng 250 nhân sự) tích lũy 47 Space sau 3 năm, không theo quy tắc nào. Tỷ lệ "tìm thấy tài liệu trong lần đầu" theo khảo sát nội bộ chỉ đạt 31%. Đội BA được giao chủ trì dọn dẹp.
Cách họ làm: trước hết, đội lập một bảng kiểm kê (audit) tất cả 47 Space, phân loại từng cái vào một trong ba nhóm Team / Project / Knowledge Base, kèm cột "ngày cập nhật cuối". Kết quả lộ ra: 18 Space không có hoạt động nào trong hơn 12 tháng. Họ thống nhất một mô hình chuẩn mới:
- 5 Team Space cho 5 phòng ban (BA, Dev, QA, Product, Ops), Space Key dạng
TEAM-BA,TEAM-QA... - Project Space theo từng dự án, Space Key có tiền tố
PRJ-(ví dụPRJ-QRPAYcho dự án thanh toán QR). - 3 Knowledge Base dùng chung:
KB-GLOSSARY(từ điển nghiệp vụ),KB-SYSTEMS(mô tả hệ thống),KB-PROCESS(quy trình chuẩn công ty).
Bài học: Đừng cố thiết kế kiến trúc hoàn hảo ngay từ đầu cho một hệ thống đã hỗn loạn. Hãy kiểm kê — phân loại — chuẩn hóa Space Key — archive cái chết. Và đặc biệt: archive chứ không xóa, vì fintech cần truy vết tài liệu cũ cho mục đích kiểm toán.
Tình huống 2 — Agency nhỏ và sai lầm "mỗi khách một Project Space" thiếu lớp dùng chung
Một agency phần mềm 30 người ở Đà Nẵng làm outsourcing cho khách Nhật và Singapore. Họ tổ chức Confluence rất gọn: mỗi khách hàng có một Project Space riêng (CLIENT-A, CLIENT-B...). Nghe có vẻ sạch sẽ. Nhưng sau một năm, BA team phát hiện mình viết đi viết lại cùng một thứ trong từng Space: chuẩn template user story, quy trình review tài liệu, checklist bàn giao. Mỗi khi cải tiến quy trình, họ phải sửa ở 12 Space khác nhau — và thường quên vài chỗ, dẫn đến mỗi dự án làm một kiểu.
Giải pháp: họ tách ra một Knowledge Base Space duy nhất tên KB-PLAYBOOK chứa toàn bộ chuẩn làm việc dùng chung, rồi từ các Project Space chỉ cần link sang. Project Space giờ chỉ chứa thứ riêng của khách đó; thứ chung sống một chỗ duy nhất.
Bài học: Phân chia theo Project Space là đúng, nhưng nếu thiếu một lớp Knowledge Base dùng chung, bạn sẽ rơi vào bẫy sao chép (copy-paste) tài liệu. Quy tắc: nội dung lặp lại ở từ 3 Space trở lên là tín hiệu nó nên được nâng lên thành Knowledge Base.
Tình huống 3 — Doanh nghiệp lớn và quyết định "một Space lớn hay nhiều Space nhỏ"
Một ngân hàng tại TP.HCM có chương trình chuyển đổi số gồm 8 dự án con chạy song song (core banking, mobile app, KYC, báo cáo...). Đội BA tranh luận: nên gom cả chương trình vào một Space lớn với 8 nhánh trang, hay tách thành 8 Project Space riêng?
Họ chọn 8 Space riêng, vì ba lý do liên quan trực tiếp đến kiến trúc: (1) phân quyền — đối tác bên ngoài tham gia dự án KYC không được phép thấy tài liệu core banking; nếu chung một Space, quyền chỉ kiểm soát được đến cấp Space chứ không tách bạch gọn được giữa các nhánh; (2) archive độc lập — khi dự án mobile app kết thúc trước, họ archive riêng Space đó mà không ảnh hưởng dự án khác; (3) điều hướng — mỗi Space có homepage và cây trang riêng, gọn gàng hơn một Space khổng lồ 600 trang. Họ thêm một Space "mẹ" tên PROG-DX chỉ chứa trang tổng quan chương trình và link tới 8 Space con.
Bài học: Ranh giới phân quyền và vòng đời archive là hai yếu tố quyết định việc gom hay tách Space. Khi các phần có đối tượng truy cập khác nhau hoặc kết thúc vào thời điểm khác nhau, hãy tách Space riêng.
Hướng dẫn từng bước
Đây là quy trình bạn — với vai trò BA — có thể áp dụng để thiết kế hoặc dọn dẹp kiến trúc Space cho team mình.
Bước 1 — Kiểm kê hiện trạng. Liệt kê tất cả Space đang có (Space Directory cho bạn danh sách đầy đủ). Với mỗi Space, ghi: tên, Space Key, loại (Team/Project/KB/Personal/chưa rõ), ngày cập nhật cuối, người chịu trách nhiệm. Nếu đang xây mới từ đầu, bỏ qua bước này và sang bước 2.
Bước 2 — Định nghĩa mô hình chuẩn ba loại. Quyết định công ty/team bạn sẽ có những Team Space nào, quy ước đặt Project Space ra sao, và những Knowledge Base nào là dùng chung. Viết quy ước này ra một trang (chính nó nên nằm trong một Knowledge Base về cách dùng Confluence).
Bước 3 — Chuẩn hóa quy ước đặt tên và Space Key. Đây là bước hay bị xem nhẹ nhất nhưng quan trọng nhất cho khả năng điều hướng. Đặt tiền tố nhất quán: TEAM-, PRJ-, KB-. Space Key nên ngắn, viết hoa, không dấu, dễ đoán. Nhớ rằng Space Key xuất hiện trong URL và rất khó đổi sau này, nên quyết một lần cho đúng.
Bước 4 — Tạo Space với template phù hợp. Khi tạo Space mới, Confluence cho chọn template (Team space, Software project, Knowledge base...). Chọn đúng loại để có sẵn cấu trúc khởi đầu hợp lý, nhưng đừng phụ thuộc — bạn vẫn nên tùy chỉnh cây trang theo nhu cầu thật.
Bước 5 — Thiết lập homepage làm điểm điều hướng. Mỗi Space cần một homepage rõ ràng: Space này phục vụ ai, chứa gì, ai phụ trách, và các link nhanh tới những trang quan trọng nhất. Một homepage tốt giúp người mới định hướng trong 10 giây thay vì 10 phút.
Bước 6 — Gán người phụ trách (Space owner) cho từng Space. Space không có chủ là Space sẽ chết. Mỗi Space cần một người chịu trách nhiệm về việc nội dung còn cập nhật và đúng quyền.
Bước 7 — Liên kết các Space với nhau. Tạo một trang "bản đồ" tổng (thường nằm trong một Knowledge Base hoặc Team Space của bộ phận quản trị) liệt kê tất cả Space chính và mục đích của chúng. Đây là tấm bản đồ giúp người mới như bạn ở đầu bài không phải lạc lối giữa 47 Space.
Bước 8 — Archive định kỳ. Đặt lịch rà soát (ví dụ mỗi quý): Space nào đã hết vòng đời thì archive. Archive ẩn Space khỏi điều hướng và tìm kiếm thường ngày nhưng vẫn giữ nội dung để truy xuất khi cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn lẫn nhiều dự án trong một Space. Vì lười tạo Space mới, BA nhét tài liệu của dự án B vào Space của dự án A. Hậu quả: không archive riêng được, phân quyền rối, tìm kiếm nhiễu. Mẹo: một dự án = một Project Space, luôn luôn.
Lỗi 2 — Đặt Space Key tùy hứng, không quy ước. abc, test2, khang_space. Sau này nhìn URL không ai đoán được Space đó là gì. Mẹo: thống nhất tiền tố và quy tắc đặt tên trước khi tạo Space đầu tiên.
Lỗi 3 — Viết tài liệu chính thức trong Personal Space. Tài liệu "biến mất" khi người đó rời công ty. Mẹo: Personal Space chỉ để nháp; định kỳ chuyển nội dung chính thức sang Space chung.
Lỗi 4 — Không có Knowledge Base, sao chép quy trình khắp nơi. Cải tiến một chỗ, 11 chỗ khác vẫn cũ. Mẹo: nội dung lặp ở từ 3 Space trở lên thì nâng lên Knowledge Base và dùng link.
Lỗi 5 — Xóa thay vì archive. Đặc biệt nguy hiểm với ngành tài chính, ngân hàng cần truy vết kiểm toán. Mẹo: mặc định là archive; chỉ xóa khi chắc chắn không còn giá trị truy xuất.
Lỗi 6 — Tạo quá nhiều Space nhỏ vụn. Mỗi cuộc họp một Space, mỗi tuần một Space. Ngược với việc gom quá mức, vụn quá cũng làm khó điều hướng. Mẹo: một Space nên tương ứng một đơn vị có ý nghĩa lâu dài (một đội, một dự án, một mảng kiến thức), không phải một sự kiện nhất thời.
Mẹo tổng quát: Hãy nghĩ về kiến trúc Space như quy hoạch một thành phố. Team Space là các khu dân cư (ổn định, có người ở lâu dài). Project Space là các công trường (có ngày khởi công, ngày hoàn thành rồi nghiệm thu lưu trữ). Knowledge Base là thư viện và bảng chỉ dẫn công cộng (ai cũng tra cứu, sống mãi). Một thành phố tốt cần cả ba, được nối với nhau bằng đường rõ ràng — chính là các liên kết và bản đồ Space.
Bài tập thực hành
Bài 1 — Phân loại. Cho danh sách sau, hãy gán mỗi mục vào loại Space phù hợp (Team / Project / Knowledge Base): (a) biên bản họp hằng tuần của phòng BA; (b) BRD dự án thanh toán QR; (c) từ điển thuật ngữ nghiệp vụ toàn công ty; (d) quy trình onboarding nhân viên BA mới; (e) kế hoạch UAT cho dự án mobile app; (f) tài liệu mô tả hệ thống core banking hiện tại. (Gợi ý đáp án: a-Team, b-Project, c-KB, d-Team, e-Project, f-KB.)
Bài 2 — Thiết kế. Giả sử bạn là BA tại một công ty thương mại điện tử 80 người với 3 phòng (BA, Dev, Marketing) và đang chạy 4 dự án. Hãy phác thảo danh sách Space cần có, kèm Space Key và tiền tố theo quy ước. Đếm xem bạn cần bao nhiêu Space và giải thích vì sao chọn con số đó.
Bài 3 — Quyết định gom hay tách. Công ty bạn có một chương trình lớn gồm 5 dự án con, trong đó 2 dự án có đối tác bên ngoài tham gia. Bạn nên gom tất cả vào một Space hay tách riêng? Viết 3 lý do dựa trên phân quyền, vòng đời archive và điều hướng.
Bài 4 — Audit thực tế. Nếu bạn đang đi làm và có quyền truy cập Confluence công ty, mở Space Directory và đếm: có bao nhiêu Space, bao nhiêu cái bạn không đoán được mục đích chỉ qua tên? Tỷ lệ đó nói lên điều gì về chất lượng kiến trúc Space hiện tại?
Tóm tắt
Kiến trúc Space là tầng quy hoạch cao nhất trong Confluence, quyết định mọi thứ bên dưới có dễ tìm và bền vững hay không. Hãy ghi nhớ những điểm cốt lõi:
- Space là đơn vị kiến trúc, Page là đơn vị nội dung. Luôn quyết định Space trước, nội dung sau.
- Ba loại Space cốt lõi: Team Space (gắn với một đội, sống lâu dài), Project Space (gắn với một dự án có vòng đời, archive khi kết thúc), Knowledge Base Space (kiến thức dùng chung, tra cứu, sống mãi).
- Một dự án = một Project Space. Đừng trộn lẫn.
- Personal Space chỉ để nháp. Tài liệu chính thức phải nằm trong Space chung.
- Phân quyền và vòng đời archive là hai yếu tố quyết định gom hay tách Space.
- Chuẩn hóa Space Key và đặt tên ngay từ đầu, vì rất khó sửa về sau.
- Archive chứ không xóa, đặc biệt trong ngành cần truy vết kiểm toán.