Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng mỗi buổi sáng bạn mở JIRA lên và phải gõ lại cùng một câu lệnh JQL: "tìm tất cả Story thuộc dự án thanh toán, đang ở trạng thái In Progress, gán cho team của tôi, sắp đến hạn trong tuần này". Gõ một lần đã mệt. Gõ mỗi ngày, suốt ba tháng của một sprint dài, thì đó là một sự lãng phí thời gian khủng khiếp — và còn rủi ro gõ sai cú pháp, ra kết quả lệch.
Đây chính là lý do Filter (bộ lọc đã lưu) tồn tại. Nếu ở các bài trước bạn đã học cách viết JQL để tìm issue, thì bài này dạy bạn cách biến một câu JQL thành tài sản dùng lại được, chia sẻ được, và làm nền tảng cho gần như mọi thứ khác trong JIRA: dashboard, board, report, subscription email, thậm chí cả automation. Một BA giỏi không phải là người gõ JQL nhanh nhất, mà là người xây được một thư viện filter gọn gàng để cả team cùng dùng, để không ai phải đoán "issue của tôi đâu rồi".
Trong bài này, chúng ta tập trung hẹp vào đúng một thứ: Filter và Saved Searches — cách lưu, cách quản lý quyền sở hữu, cách chia sẻ, đăng ký nhận email, và các bẫy thường gặp. Chúng ta sẽ không đi sâu vào cú pháp JQL (đã có bài 7, 8, 38) hay cách dựng dashboard (bài 10), mà chỉ chạm tới chúng đủ để bạn hiểu filter ngồi ở đâu trong bức tranh lớn.
Khái niệm cốt lõi
Filter là gì — một câu JQL được đặt tên và lưu lại
Bản chất rất đơn giản: Filter = một câu truy vấn JQL đã được lưu kèm một cái tên. Khi bạn vào màn hình tìm kiếm issue (Issues → Search for issues), gõ một câu JQL, rồi bấm nút Save as, JIRA sẽ hỏi bạn đặt tên cho nó. Từ đó trở đi, thay vì gõ lại câu lệnh, bạn chỉ cần chọn filter từ danh sách.
Điểm mấu chốt mà nhiều người mới bỏ qua: filter lưu câu truy vấn, không lưu kết quả. Nghĩa là mỗi lần bạn mở filter, JIRA chạy lại câu JQL đó trên dữ liệu hiện tại. Nếu hôm nay có 12 bug, ngày mai có 15 bug, filter "Open Bugs" sẽ trả về số khác nhau — vì nó là một câu hỏi sống, không phải một ảnh chụp tĩnh. Điều này nghe hiển nhiên nhưng lại là nền tảng cho mọi báo cáo tự cập nhật mà bạn sẽ xây sau này.
Vì sao filter quan trọng hơn vẻ ngoài của nó
Filter không chỉ để bạn tìm issue cho nhanh. Nó là viên gạch nền của hệ sinh thái JIRA:
- Board (Scrum/Kanban) thực ra được điều khiển bởi một filter ẩn phía sau — board chỉ hiển thị những issue mà filter của nó trả về.
- Dashboard gadget như Filter Results, Pie Chart, Created vs Resolved... đều cần bạn trỏ chúng tới một filter.
- Subscription (đăng ký nhận email định kỳ) gắn trực tiếp vào filter.
- Nhiều report và cả automation rule cũng tham chiếu filter.
Quyền sở hữu và chia sẻ filter
Đây là phần trọng tâm của bài. Mỗi filter có một owner (chủ sở hữu) — mặc định là người tạo ra nó — và một tập permission quy định ai được xem, ai được sửa.
Về mức độ chia sẻ (sharing), bạn cần nắm ba cấp:
- Private / Personal — chỉ mình bạn thấy. Đây là mặc định khi bạn vừa lưu một filter mới. Dùng cho những truy vấn cá nhân kiểu "việc tôi đang làm".
- Shared — chia sẻ có giới hạn. Bạn có thể chia sẻ theo Project (ai có quyền vào dự án đó đều thấy), theo Group (một nhóm người dùng cụ thể như
ba-team,qa-team), hoặc theo Project Role (ví dụ chỉ những người giữ vai trò Developer trong dự án). Đây là lựa chọn nên dùng nhất trong môi trường công ty, vì nó đúng nguyên tắc "vừa đủ quyền". - Public — bất kỳ ai đăng nhập vào hệ thống JIRA đều thấy (và với một số cấu hình, cả người dùng ẩn danh nếu hệ thống cho phép). Nghe tiện nhưng dễ gây rối: ai cũng thấy filter của bạn, danh sách filter chung phình to.
ba-team sửa nó. Nguyên tắc vàng: mở rộng quyền xem khi cần cộng tác, nhưng siết chặt quyền sửa để tránh người khác vô tình đổi câu JQL làm hỏng dashboard phụ thuộc.Một điểm quản trị quan trọng: khi một nhân viên nghỉ việc, các filter họ sở hữu vẫn còn đó nhưng "mồ côi". Admin có quyền đổi owner (change owner) để chuyển quyền sở hữu sang người khác, tránh tình trạng filter quan trọng bị khóa không ai sửa được.
Saved Searches và "Find filters"
"Saved Search" thực chất là cách Atlassian gọi chung cho filter trong một số phiên bản giao diện. Khi bạn vào Filters → View all filters (hoặc Find filters), bạn sẽ thấy ba nhóm quen thuộc: My filters (filter bạn tạo), Popular (được nhiều người đánh dấu sao), và một ô tìm kiếm để lọc theo tên, theo owner. Bạn có thể đánh dấu sao (star) một filter để nó hiện lên thanh điều hướng nhanh — rất tiện cho những filter dùng hàng ngày.
Tình huống thực tế
Tình huống 1 — Tiki: BA chuẩn hóa filter cho team thanh toán
Tại một team phụ trách mảng thanh toán của Tiki, có 4 BA, 9 dev và 3 QA cùng làm trên một dự án JIRA tên PAY. Trước đây, mỗi BA tự gõ JQL riêng để theo dõi việc của mình, dẫn đến cảnh mỗi người báo cáo một con số khác nhau trong daily meeting.
Chị Hương, BA lead, quyết định dựng một bộ filter chuẩn. Chị tạo filter [PAY] Story chờ làm rõ với câu lệnh project = PAY AND issuetype = Story AND status = "Needs Clarification" ORDER BY priority DESC, rồi chia sẻ ở mức Project PAY (view) và giới hạn edit cho group pay-ba. Tiếp theo là [PAY] Bug tồn đọng > 7 ngày và [PAY] Sprint hiện tại của tôi. Tất cả đều đặt tên theo quy ước [Mã dự án] Mô tả.
Kết quả: trong daily, mọi người mở cùng một filter, nhìn cùng một con số. Khi một dev mới vào team, anh ta chỉ cần đánh dấu sao bộ filter [PAY] là có ngay góc nhìn chuẩn, không phải hỏi "anh gõ JQL gì để xem bug vậy?".
Bài học: Filter chỉ phát huy giá trị khi được đặt tên theo quy ước và chia sẻ ở đúng phạm vi. Một bộ filter chuẩn của team đáng giá hơn hàng chục filter cá nhân rời rạc.
Tình huống 2 — Một startup fintech ở TP.HCM: thảm họa "Public mọi thứ"
Một startup fintech khoảng 40 người gặp rắc rối khi danh sách filter chung phình lên tới hơn 300 cái. Lý do: ai cũng có thói quen lưu filter ở mức Public cho "tiện". Hậu quả là khi một BA mới muốn tìm filter "open bugs", anh ta gõ vào ô tìm kiếm và nhận về 14 filter trùng tên gần giống nhau, không biết cái nào đang được dashboard của sếp dùng.
Tệ hơn, một bạn dev vô tình sửa câu JQL trong một filter public tên Open Bugs — đổi status = Open thành status = "In Progress" cho mục đích riêng. Cái filter đó hóa ra đang nằm dưới một board Kanban của cả team QA. Sáng hôm sau, board QA trống trơn, mọi người hoảng loạn tưởng mất dữ liệu.
Sau sự cố, admin áp dụng ba quy tắc: (1) cấm Public trừ khi có lý do chính đáng, mặc định dùng Project/Group; (2) filter nào gắn với board hoặc dashboard quan trọng thì chỉ owner và admin được edit; (3) rà soát hàng quý, đổi owner các filter mồ côi và xóa filter trùng.
Bài học: Public không phải là "tiện", mà là "rủi ro". Và quyền edit trên một filter dùng chung phải được siết, vì sửa câu JQL có thể làm sập board hoặc dashboard mà người sửa không hề hay biết.
Tình huống 3 — Shopee: subscription thay cho việc "F5 cả ngày"
Anh Tuấn, BA tại một team logistics của Shopee, có nhiệm vụ canh các issue bị escalate (đẩy lên mức ưu tiên cao). Trước đây anh mở filter [LOG] Escalated chưa xử lý mỗi giờ một lần để xem có gì mới không — mất tập trung kinh khủng.
Anh phát hiện ra tính năng Subscription: trên màn hình filter, vào Details → New subscription, đặt lịch chạy mỗi sáng 8h và mỗi chiều 14h (chỉ ngày làm việc), và chọn gửi cho group log-leads. Từ đó, mỗi mốc giờ, JIRA tự chạy filter và gửi email liệt kê các issue khớp — kèm cả tùy chọn "email even if there are no issues" mà anh tắt đi để khỏi nhận thư rỗng.
Kết quả: anh không còn phải F5, mà vẫn nắm được danh sách escalate hai lần mỗi ngày. Khi đi công tác, cả team vẫn nhận thông tin vì subscription gửi cho cả group chứ không chỉ riêng anh.
Bài học: Filter cộng với subscription biến một câu truy vấn tĩnh thành một kênh thông báo định kỳ — đây là cách BA tự động hóa việc theo dõi mà không cần đụng tới automation phức tạp.
Hướng dẫn từng bước
Bước 1 — Tạo và lưu một filter. Vào Issues → Search for issues. Gõ câu JQL của bạn, ví dụ project = PAY AND issuetype = Bug AND status != Done ORDER BY created DESC. Bấm Search để kiểm tra kết quả đúng ý chưa, rồi bấm Save as (góc trên). Đặt tên theo quy ước rõ ràng, ví dụ [PAY] Bug chưa đóng.
Bước 2 — Đặt mô tả. Vào Details của filter, thêm phần Description giải thích filter dùng để làm gì, ai nên dùng. Một dòng mô tả tốt giúp người sau (và chính bạn sáu tháng nữa) hiểu ngay mục đích mà không phải đọc câu JQL.
Bước 3 — Cấu hình chia sẻ. Trong Details → Edit permissions (hoặc phần Share), chọn phạm vi: thêm Project: PAY với quyền Viewers, và Group: pay-ba với quyền Editors. Tránh chọn Public trừ khi thực sự cần cả tổ chức nhìn thấy.
Bước 4 — Đánh dấu sao. Nếu là filter bạn dùng hàng ngày, bấm biểu tượng ngôi sao để nó xuất hiện trong menu Filters → Starred trên thanh điều hướng, truy cập một cú click.
Bước 5 — Tạo subscription (nếu cần). Vào Details → Subscriptions → New subscription. Chọn người/nhóm nhận, đặt lịch (ví dụ "Days per week" → chọn các ngày làm việc, giờ 08:00), và cân nhắc bỏ tick ô "Email this filter, even if there are no issues found" để tránh email rỗng.
Bước 6 — Quản lý và bảo trì. Định kỳ vào Filters → View all filters, sắp xếp theo owner, rà soát các filter trùng hoặc không dùng. Nếu bạn là admin, dùng chức năng change owner để xử lý filter của người đã nghỉ việc.
Lỗi thường gặp & mẹo
- Đặt tên mơ hồ. "My bugs", "abc", "test 2" — vài tuần sau chính bạn cũng không nhớ. Mẹo: dùng quy ước
[Mã dự án] Mô tả ngắn, ví dụ[PAY] Sprint hiện tại. Tên là tài liệu rẻ nhất bạn có.
- Lạm dụng Public. Đây là lỗi phổ biến nhất. Public làm phình danh sách chung và lộ filter cho người không liên quan. Mẹo: mặc định dùng Project hoặc Group; chỉ Public khi filter thực sự mang tính toàn tổ chức.
- Mở quyền edit quá rộng. Cho phép nhiều người sửa một filter dùng chung là công thức gây sập board/dashboard. Mẹo: tách rõ viewer rộng, editor hẹp. Filter nào đang đỡ một board hay dashboard thì khóa edit lại.
- Nhầm filter lưu kết quả. Filter lưu câu hỏi, không lưu ảnh chụp. Nếu bạn cần một ảnh chụp cố định tại một thời điểm (ví dụ danh sách bug lúc release), hãy export ra file, đừng kỳ vọng filter "đóng băng" dữ liệu.
- ORDER BY bị bỏ quên. Khi filter dùng cho board hoặc dashboard, thứ tự sắp xếp ảnh hưởng trực tiếp tới cách hiển thị. Mẹo: luôn cân nhắc mệnh đề
ORDER BY(ví dụORDER BY priority DESC, created ASC) thay vì để JIRA tự sắp.
- Subscription gửi email rỗng. Nếu không tắt tùy chọn gửi-cả-khi-rỗng, hộp thư mọi người sẽ đầy thư "0 issues". Mẹo: chỉ bật gửi khi có issue, trừ trường hợp bạn cố ý muốn xác nhận "không có gì bất thường".
- Quên dọn filter mồ côi. Khi người tạo nghỉ việc, filter của họ vẫn chạy nhưng không ai sửa được. Mẹo: đưa việc rà soát và đổi owner vào quy trình offboarding của team.
Bài tập thực hành
- Tạo filter cá nhân. Viết câu JQL tìm tất cả issue đang gán cho bạn và chưa Done (
assignee = currentUser() AND status != Done), lưu với tên[Tên bạn] Việc đang làm. Đánh dấu sao và kiểm tra nó xuất hiện trong menu Starred.
- Tạo filter team và chia sẻ đúng phạm vi. Viết filter
[DỰ ÁN] Bug chưa đóngcho một dự án bạn có quyền. Chia sẻ view cho Project, edit chỉ cho một group. Đăng nhập (hoặc nhờ đồng nghiệp) bằng tài khoản khác để xác nhận họ thấy được nhưng không sửa được.
- Thiết lập subscription. Trên filter ở bài 2, tạo một subscription gửi cho chính bạn vào một mốc giờ gần (ví dụ 5 phút sau) để thấy email mẫu. Nhớ tắt tùy chọn gửi khi không có issue, rồi quan sát khác biệt.
- Tình huống dọn dẹp. Giả sử team bạn có 50 filter, 12 cái trùng tên gần giống nhau. Hãy viết ra một bộ quy ước đặt tên và một checklist rà soát hàng quý (đổi owner, gộp filter trùng, hạ Public xuống Project). Đây là kỹ năng quản trị mà BA lead rất cần.
Tóm tắt
Filter chính là một câu JQL được đặt tên và lưu lại — nền tảng âm thầm phía sau board, dashboard, report và subscription. Giá trị thật của filter không nằm ở việc tiết kiệm vài giây gõ phím, mà ở chỗ nó cho phép cả team dùng chung một góc nhìn chuẩn.
Ba điều cần khắc cốt ghi tâm: (1) Filter lưu câu hỏi sống, không lưu kết quả tĩnh, nên nó luôn phản ánh dữ liệu hiện tại. (2) Quyền sở hữu và chia sẻ là chuyện sống còn — mặc định Private, nâng lên Project/Group khi cần cộng tác, và cực kỳ dè dặt với Public; luôn tách viewer-rộng khỏi editor-hẹp. (3) Đặt tên theo quy ước, thêm mô tả, và bảo trì định kỳ để thư viện filter không biến thành bãi rác.
Khi bạn đã làm chủ filter, bạn sẽ thấy mọi thứ phía sau — dashboard, board, automation — trở nên dễ dựng hơn rất nhiều, vì tất cả đều bắt đầu từ một câu truy vấn được lưu đúng cách.