Mở đầu — vì sao bài này quan trọng
Khi mới làm BA, bạn thường chỉ lo cho một dự án, một project trong JIRA, một space trong Confluence. Mọi thứ gọn gàng: issue nằm đúng chỗ, team biết nhau, bạn theo dõi tiến độ bằng một board duy nhất. Nhưng đến một lúc, công việc của bạn sẽ vượt ra ngoài bốn bức tường đó. Một tính năng bạn đặc tả cần platform team xây API. Một yêu cầu compliance bắt buộc tất cả sản phẩm phải đổi luồng lưu trữ dữ liệu. Một dự án lớn cần năm team cùng chạy song song, mỗi team một JIRA project riêng nhưng phải về đích chung một ngày.
Đây chính là lúc kỹ năng phối hợp đa dự án (cross-team coordination) trở thành ranh giới phân biệt một BA giỏi với một BA chỉ biết viết user story. Bởi vì khi nhiều team cùng làm việc, vấn đề không còn là "việc này làm thế nào" mà là "ai phụ thuộc vào ai", "việc của tôi bị kẹt vì team kia chưa xong", "tôi không nhìn thấy bức tranh toàn cảnh". Trong JIRA và Confluence, mặc định mỗi project là một ốc đảo — và nếu bạn không chủ động kết nối chúng, thông tin sẽ rơi rụng ở các khe hở giữa các team.
Bài này dạy bạn cách dùng JIRA và Confluence để điều phối công việc xuyên nhiều project: làm sao nhìn thấy dependency giữa các team, làm sao tổng hợp tiến độ từ nhiều board về một chỗ, và làm sao tổ chức tài liệu để mọi team đều tìm được "nguồn sự thật duy nhất". Đây là kỹ năng đặc biệt cần thiết khi công ty bạn lớn lên — và nó là phần mà công cụ không tự làm thay bạn được; nó cần một BA biết thiết kế cách phối hợp.
Khái niệm cốt lõi
Multi-project là gì và khác gì single-project
Trong JIRA, mỗi project có key riêng (ví dụ PAY, MOBILE, PLAT), backlog riêng, board riêng và thường gắn với một team riêng. Khi một sáng kiến (initiative) trải dài qua nhiều project, bạn không thể quản lý nó từ bên trong một project đơn lẻ. Bạn cần các cơ chế "xuyên project":
- Cross-project issue links: liên kết issue ở project này với issue ở project khác (kiểu "blocks", "is blocked by", "relates to").
- Cross-project filters và boards: dùng JQL để gom issue từ nhiều project về một danh sách hoặc một board duy nhất.
- Hierarchy cao hơn Epic: trong Jira Premium có cấp Initiative (và cao hơn nữa) để gộp nhiều Epic nằm rải rác ở các project khác nhau dưới một mục tiêu chung. Nếu không có Premium, người ta dùng label, component hoặc một custom field chung để "buộc" các Epic lại.
Ba mô hình phối hợp thường gặp
Đúng như ý định gốc của bài, có ba kịch bản phối hợp mà BA hay đụng phải, mỗi kịch bản đòi hỏi một cách tổ chức khác nhau:
1. Dự án lớn trải qua 5+ team. Một sản phẩm mới, ví dụ một ví điện tử, cần team Backend, team Mobile, team Web, team QA, team Data cùng làm. Mỗi team chạy project JIRA riêng theo nhịp Sprint riêng, nhưng phải tích hợp với nhau theo từng milestone. Thách thức lớn nhất ở đây là dependency theo chiều ngang: Mobile không build được màn hình nạp tiền nếu Backend chưa xong API.
2. Platform team phục vụ nhiều product team. Một team nền tảng (authentication, payment gateway, notification service) bị nhiều team sản phẩm "đặt hàng" cùng lúc. Thách thức ở đây là quản lý hàng đợi yêu cầu (intake) và ưu tiên: platform team không thể làm hết mọi yêu cầu, cần một cơ chế rõ ràng để các product team gửi request và theo dõi.
3. Dự án compliance chạm vào mọi sản phẩm. Một quy định mới — ví dụ Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân ở Việt Nam — buộc mọi sản phẩm phải bổ sung tính năng đồng ý (consent), nhật ký truy cập, quyền xóa dữ liệu. Thách thức ở đây là độ phủ (coverage): làm sao biết chắc rằng tất cả các team đều đã làm phần của mình, không sót sản phẩm nào.
Hai trụ cột: JIRA để theo dõi, Confluence để đồng bộ hiểu biết
Quy tắc tinh thần đơn giản: JIRA trả lời "ai đang làm gì, kẹt ở đâu", còn Confluence trả lời "vì sao, theo phạm vi nào, ai chịu trách nhiệm phần nào". Một initiative đa team luôn cần một trang Confluence "trục chính" (coordination hub) làm điểm hẹn, rồi từ đó link xuống các filter, board, Epic của từng team. Nếu bạn chỉ dùng JIRA, mọi người sẽ chìm trong hàng trăm issue mà không thấy ngữ cảnh; nếu chỉ dùng Confluence, tài liệu sẽ nhanh chóng lỗi thời so với tiến độ thực.
Tình huống thực tế
Tình huống 1 — MoMo-style: ví điện tử với 5 team chạy song song
Giả định một công ty fintech tại TP.HCM, gọi là "VietPay", triển khai tính năng "Quét QR thanh toán liên ngân hàng". Tính năng này cần 5 team: Backend (project BE), Mobile (MOB), Web Merchant Portal (WEB), QA (QA), và Data/Reconciliation (DATA). Deadline chung: ra mắt trong 3 sprint (6 tuần).
BA phụ trách initiative tạo một Epic ở mỗi project, đặt cùng một label qr-interbank cho cả 5 Epic. Sau đó cô lập một cross-project board bằng JQL:
labels = qr-interbank ORDER BY project
Vấn đề lộ ra ngay tuần đầu: Mobile có 8 story phụ thuộc vào 3 API của Backend, nhưng Backend lại đang dồn sức cho dự án khác. BA dùng issue link kiểu "is blocked by" để nối từng story Mobile với API tương ứng bên Backend, rồi tạo một filter:
labels = qr-interbank AND issueFunction in linkedIssuesOf("project = MOB", "is blocked by")
(hoặc đơn giản hơn nếu không có ScriptRunner: dùng board hiển thị các issue có liên kết "blocks").
Nhờ thấy rõ chuỗi blocker, BA mang con số cụ thể vào buổi Scrum of Scrums: "3 API này đang chặn 8 story, tương đương 21 story point của Mobile — nếu Backend không ưu tiên trong sprint này, Mobile sẽ trễ một sprint." Kết quả: Backend đẩy 3 API đó lên đầu sprint, và toàn bộ initiative về đích đúng hạn.
Bài học rút ra: Dependency vô hình là kẻ giết deadline thầm lặng. Khi bạn biến nó thành issue link tường minh và quy đổi ra con số (bao nhiêu story, bao nhiêu point bị chặn), bạn cho lãnh đạo một lý do định lượng để sắp xếp ưu tiên — thay vì chỉ "cảm thấy" team kia chậm.
Tình huống 2 — Platform team của một sàn TMĐT bị quá tải yêu cầu
Một sàn thương mại điện tử ở Hà Nội, gọi là "ChợViet", có một Platform team quản lý dịch vụ Notification (đẩy thông báo, email, SMS). Có 6 product team thường xuyên cần Platform team mở thêm loại thông báo mới. Trước đây mỗi team nhắn Slack trực tiếp, dẫn đến platform lead phải tự nhớ ai yêu cầu gì, và thường xuyên có chuyện "tôi gửi yêu cầu hai tuần trước rồi mà".
BA của Platform team thiết kế lại quy trình intake. Cô tạo một project JIRA riêng tên NOTIF-INTAKE với một issue type "Service Request". Mọi product team muốn gì đều phải tạo issue tại đây, điền các field bắt buộc: sản phẩm yêu cầu, mức độ ưu tiên đề xuất, deadline mong muốn, mục đích nghiệp vụ. Trên Confluence, cô viết một trang "Cách đặt hàng Notification team" giải thích quy trình, kèm macro hiển thị filter các request đang chờ.
Để điều phối, BA dùng một board Kanban cho project intake với các cột: Mới gửi → Đang đánh giá → Đã chấp nhận (trong backlog) → Đang làm → Xong. Mỗi thứ Hai, platform lead và các đại diện product team họp 30 phút nhìn vào board này để chốt ưu tiên tuần. Sau 2 tháng, thời gian phản hồi trung bình một yêu cầu giảm từ 9 ngày xuống 3 ngày, và quan trọng hơn, không còn yêu cầu nào "bốc hơi".
Bài học rút ra: Với platform team, vấn đề không phải năng lực mà là quản lý hàng đợi. Một project intake riêng + một quy trình đặt hàng minh bạch trên Confluence biến những lời nhắn rời rạc thành một backlog có thể ưu tiên và đo lường. Ai cũng thấy yêu cầu của mình đang ở đâu, và platform team có cơ sở để nói "không" hoặc "chưa" một cách công bằng.
Tình huống 3 — Dự án compliance Nghị định 13 chạm vào toàn bộ sản phẩm
Một ngân hàng số tại Việt Nam phải tuân thủ Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân, hạn hoàn thành trong 4 tháng. Quy định này chạm vào 7 sản phẩm khác nhau, mỗi sản phẩm là một JIRA project riêng. Rủi ro lớn nhất: sót một sản phẩm nào đó thì cả ngân hàng vẫn bị coi là chưa tuân thủ.
BA compliance không tạo issue rải rác. Thay vào đó, cô lập một Epic compliance trong mỗi project, tất cả gắn label nd13-2023 và một component data-privacy. Trên Confluence, cô dựng một trang "Bảng theo dõi tuân thủ ND13" dùng macro JIRA Issues nhúng kết quả của JQL:
labels = nd13-2023 ORDER BY project, status
Cạnh đó là một bảng coverage thủ công liệt kê đủ 7 sản phẩm × 4 hạng mục bắt buộc (consent, access log, quyền xóa, mã hóa), với màu trạng thái cho từng ô. Mỗi tuần BA cập nhật và bất kỳ ai mở trang đều thấy ngay ô nào còn đỏ. Đến tuần thứ 9, bảng coverage phát hiện sản phẩm "Thẻ tín dụng" chưa có Epic nào cho hạng mục "quyền xóa dữ liệu" — một lỗ hổng suýt bị bỏ sót vì team đó nghĩ phần này thuộc team khác. Phát hiện sớm giúp họ kịp bổ sung, dự án tuân thủ đúng hạn.
Bài học rút ra: Với dự án compliance, độ phủ quan trọng hơn tốc độ. Một label/component thống nhất cho phép gom mọi việc liên quan từ mọi project, còn một bảng coverage trên Confluence biến câu hỏi mơ hồ "chúng ta đã làm hết chưa" thành một ma trận có thể kiểm đếm từng ô.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho hầu hết initiative đa team:
Bước 1 — Xác định mô hình phối hợp. Trước tiên hỏi: đây là dự án lớn 5+ team, platform phục vụ nhiều team, hay compliance phủ mọi sản phẩm? Câu trả lời quyết định bạn nhấn mạnh điều gì — dependency, intake queue, hay coverage.
Bước 2 — Chọn cơ chế "buộc" việc lại với nhau. Nếu có Jira Premium, dùng cấp Initiative để gộp các Epic. Nếu không, chọn một label thống nhất (ví dụ qr-interbank) hoặc một component chung. Quan trọng là tất cả các team dùng đúng cùng một quy ước — bạn phải công bố và viết nó xuống Confluence.
Bước 3 — Tạo Epic của initiative trong từng project liên quan. Mỗi team sở hữu Epic của mình trong project của họ, nhưng tất cả mang nhãn thống nhất ở Bước 2. Điều này tôn trọng quyền tự chủ của từng team trong khi vẫn cho phép nhìn xuyên ngang.
Bước 4 — Khai báo dependency bằng issue link. Với từng việc phụ thuộc, dùng link "is blocked by" / "blocks". Đừng để dependency chỉ tồn tại trong đầu hay trong Slack — phải nằm trong JIRA thì mới truy vấn và báo cáo được.
Bước 5 — Dựng cross-project filter và board. Tạo một saved filter với JQL gom theo label (ví dụ labels = qr-interbank), rồi tạo một board từ filter đó để nhìn toàn cảnh. Cấu hình swimlane theo project hoặc theo team để dễ đọc.
Bước 6 — Lập trang Confluence trục chính (coordination hub). Trang này gồm: mục tiêu và phạm vi, danh sách team và người chịu trách nhiệm, link tới filter/board ở Bước 5, macro JIRA Issues nhúng tiến độ trực tiếp, và bảng coverage hoặc bảng dependency. Đây là điểm hẹn duy nhất mọi người mở mỗi tuần.
Bước 7 — Thiết lập nhịp đồng bộ. Đặt một buổi định kỳ (Scrum of Scrums hoặc sync 30 phút/tuần) nơi đại diện mỗi team nhìn vào board và hub, báo cáo blocker liên team. JIRA cho dữ liệu, buổi họp cho quyết định.
Bước 8 — Cập nhật và rà soát. Mỗi tuần kiểm tra: còn dependency nào mới phát sinh không, ô coverage nào còn đỏ, request nào quá hạn SLA. Hub phải sống cùng tiến độ, không được để mốc meo.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi mọi team vào một JIRA project khổng lồ. Nhiều người tưởng "cùng dự án thì cho chung một project cho dễ". Sai. Mỗi team có workflow, board, nhịp sprint khác nhau; gộp chung sẽ làm board rối và phá vỡ quyền tự chủ. Hãy giữ project riêng cho từng team, dùng label/component và filter để nhìn xuyên ngang.
Lỗi 2 — Để dependency sống trong Slack hoặc trong đầu. Một blocker chỉ được nhắc miệng sẽ biến mất sau ba ngày. Mẹo: mọi phụ thuộc liên team đều phải thành một issue link trong JIRA. "Nếu nó không có trong JIRA, nó không tồn tại."
Lỗi 3 — Label đặt lung tung mỗi team một kiểu. qr-interbank, QR_Interbank, qrib — ba team ba cách viết là filter của bạn vỡ trận. Mẹo: công bố quy ước label/component trên Confluence, viết hoa thường rõ ràng, và lý tưởng là dùng một custom field dạng select thay vì label tự do để tránh gõ sai.
Lỗi 4 — Trang Confluence hub bị lỗi thời. Một hub mà số liệu sai còn tệ hơn không có. Mẹo: thay vì gõ tay con số tiến độ, hãy dùng macro JIRA Issues nhúng JQL trực tiếp — số liệu tự cập nhật từ JIRA mỗi lần mở trang. Phần thủ công chỉ giữ cho những thứ JIRA không tự biết, như ma trận coverage.
Lỗi 5 — Không có người chủ trì rõ ràng cho initiative. Khi 5 team cùng làm, nếu không ai sở hữu bức tranh toàn cảnh thì mỗi team chỉ lo phần mình và các khe hở không ai vá. Mẹo: chỉ định một người (thường là BA hoặc một coordinator) sở hữu hub, chủ trì buổi sync và rà soát dependency hằng tuần.
Mẹo nâng cao: Dùng một Confluence space riêng cho cross-team program thay vì nhét trang hub vào space của một team nào đó — điều này tránh chuyện trang trục chính bị "thuộc về" một team và các team khác ngại đụng vào. Đặt space trung lập để tất cả cảm thấy đây là sân chung.
Bài tập thực hành
- Vẽ bản đồ dependency. Chọn một initiative thật (hoặc giả định) có ít nhất 3 team. Liệt kê 5 dependency liên team, ghi rõ "issue A của team X bị chặn bởi issue B của team Y". Sau đó trong JIRA, tạo các issue link tương ứng và viết JQL liệt kê tất cả issue đang bị chặn.
- Dựng cross-project filter. Tạo một label thống nhất cho 2 project bất kỳ trong sandbox JIRA của bạn, gắn nhãn cho vài issue, rồi viết một saved filter gom chúng lại và tạo board từ filter đó. Cấu hình swimlane theo project.
- Xây trang coordination hub. Trên Confluence, tạo một trang trục chính cho initiative ở bài 1. Trang phải có: mục tiêu, bảng team + người chịu trách nhiệm, macro JIRA Issues nhúng filter ở bài 2, và một bảng coverage hoặc bảng dependency thủ công.
- Thiết kế quy trình intake. Giả sử bạn là BA của một platform team. Phác thảo (trên Confluence) quy trình đặt hàng: issue type nào, field bắt buộc gì, các cột Kanban nào, SLA phản hồi bao lâu. Viết một đoạn hướng dẫn ngắn để product team biết cách gửi yêu cầu.
Tóm tắt
Phối hợp đa dự án là kỹ năng phân biệt BA cấp độ cao. Ba mô hình điển hình — dự án lớn nhiều team, platform phục vụ nhiều team, và compliance phủ mọi sản phẩm — mỗi mô hình có một thách thức cốt lõi: dependency, intake queue, và coverage. Công cụ thì giống nhau nhưng cách nhấn mạnh khác nhau.
Nguyên tắc vận hành xuyên suốt: giữ project riêng cho từng team để tôn trọng quyền tự chủ, dùng label/component thống nhất hoặc cấp Initiative để buộc việc lại, biến mọi dependency thành issue link tường minh trong JIRA, gom tiến độ về một cross-project filter/board, và dựng một trang Confluence trục chính làm nguồn sự thật duy nhất với số liệu nhúng tự cập nhật. Cuối cùng, đừng quên yếu tố con người: một initiative đa team luôn cần một người chủ trì sở hữu bức tranh toàn cảnh và một nhịp đồng bộ định kỳ — bởi vì JIRA và Confluence cho bạn dữ liệu, nhưng chính bạn, người BA, mới là người biến dữ liệu đó thành sự phối hợp thực sự.