Mở đầu — vì sao bài này quan trọng
Có một sự thật mà ít ai nói thẳng với các Product Manager: bạn sẽ không bao giờ được cấp quyền admin đầy đủ của Jira, và điều đó hoàn toàn bình thường. Quản trị Jira (Jira Administration) là công việc của một Jira Admin chuyên trách — thường là một người trong đội IT, DevOps, hoặc một Agile Coach được ủy quyền. PM không cần, và cũng không nên, ôm vai trò đó.
Nhưng đây mới là phần quan trọng: PM không admin Jira, không có nghĩa là PM không cần hiểu Jira admin làm gì. Ranh giới này rất tinh tế. Nếu bạn hoàn toàn mù tịt về cách Jira được cấu hình bên dưới, bạn sẽ liên tục rơi vào ba tình huống tệ hại: (1) yêu cầu những thứ bất khả thi hoặc tốn kém một cách phi lý, (2) đợi hàng tuần cho một thay đổi mà lẽ ra bạn tự làm được trong 5 phút, và (3) không hiểu tại sao workflow, field, hay board của mình lại hoạt động theo cách "kỳ lạ" như vậy.
Trong thực tế làm việc, tôi từng chứng kiến một PM ở một công ty fintech tại TP.HCM gửi ticket cho IT yêu cầu "thêm một cột mới vào board" — và đợi 3 ngày. Trong khi đó, việc thêm cột trên Scrum/Kanban board là quyền của Board Admin, không cần đụng đến System Admin. Chỉ vì không phân biệt được đâu là "cấu hình cấp project/board mà PM tự làm được" và đâu là "cấu hình cấp hệ thống cần admin", cô ấy đã lãng phí 3 ngày và làm chậm cả sprint.
Bài học này sẽ vẽ cho bạn tấm bản đồ ranh giới đó. Sau bài này, bạn sẽ biết chính xác: cái gì tự làm được, cái gì phải nhờ admin, và khi nhờ admin thì phải nói gì để họ hiểu ngay và làm đúng.
Khái niệm cốt lõi
Ba tầng quyền trong Jira
Jira (đặc biệt là Jira Cloud) tổ chức quyền quản trị theo nhiều tầng. Với vai trò PM, bạn chỉ cần nắm rõ ba tầng sau:
1. System Administrator / Jira Administrator (tầng cao nhất) — Đây là người có quyền toàn cục trên toàn bộ instance Jira của công ty. Họ quản lý: user và group, application access, global permission, các "scheme" dùng chung, cài đặt app/marketplace, cấu hình email, migration. PM gần như không bao giờ có quyền này, và cũng không nên đòi.
2. Project Administrator (tầng dự án) — Đây là tầng PM rất thường được cấp và nên chủ động xin. Với vai trò Project Admin, bạn có thể quản lý trong phạm vi một project cụ thể: thêm/xóa thành viên vào project, gán role, chỉnh sửa một số cấu hình project (tùy cách Jira thiết lập — với "Team-managed project" bạn được nhiều quyền hơn "Company-managed project").
3. Board Administrator (tầng board) — Người quản lý một board Scrum/Kanban cụ thể: cấu hình cột, quick filter, swimlane, card layout, working days của sprint. Đây là những thứ PM đụng vào hằng ngày.
Hiểu ba tầng này giúp bạn trả lời câu hỏi quan trọng nhất: "Việc này tôi tự làm được không, hay phải nhờ ai?"
Company-managed vs Team-managed project
Một điểm cực kỳ then chốt trong Jira Cloud mà PM hay bỏ qua. Jira Cloud có hai loại project:
- Team-managed project (trước đây gọi là Next-gen): Do chính đội tự quản lý. Người tạo project được quyền tự cấu hình issue type, workflow, field, board... trong phạm vi project đó mà không cần System Admin. Rất phù hợp cho đội nhỏ, PM tự chủ cao. Nhưng đổi lại, cấu hình không chia sẻ được sang project khác và thiếu một số tính năng nâng cao.
- Company-managed project (trước đây gọi là Classic): Cấu hình tập trung, dùng chung các "scheme" (workflow scheme, permission scheme, field configuration scheme...) do System Admin quản lý. Mạnh mẽ, nhất quán toàn công ty, nhưng mọi thay đổi cấu trúc phải qua Jira Admin.
Cái gì "adminable" — và ai làm
Hãy phân loại rõ ràng các hạng mục cấu hình phổ biến theo cấp độ:
PM/Board Admin tự làm được (thường xuyên):
- Cấu hình cột board, WIP limit, quick filter, swimlane.
- Tạo/sửa filter và JQL, chia sẻ dashboard.
- Thêm/xóa thành viên trong project (nếu là Project Admin).
- Chỉnh card layout, thứ tự backlog, cấu hình sprint (ngày làm việc).
- Trong Team-managed project: tạo issue type mới, chỉnh workflow đơn giản, thêm custom field cấp project.
- Tạo/sửa custom field dùng chung toàn hệ thống.
- Sửa workflow scheme, thêm status/transition dùng chung.
- Tạo permission scheme, notification scheme mới.
- Cài app từ Marketplace, cấu hình automation cấp global.
- Tạo project mới loại Company-managed, thiết lập integration (Slack, GitHub) cấp hệ thống.
- Thêm/xóa license user, đổi group membership.
Tình huống thực tế
Tình huống 1: PM đợi 3 ngày cho một việc 5 phút
Bối cảnh: Chị Hương là PM tại một startup thương mại điện tử ở Hà Nội, quy mô khoảng 40 người, dùng Jira Cloud Company-managed. Đội dev phàn nàn rằng board Kanban thiếu một cột "Code Review" giữa "In Progress" và "Done", khiến các ticket đang chờ review bị lẫn lộn.
Chị Hương lập tức mở ticket gửi cho anh admin IT: "Nhờ em thêm cột Code Review vào board team Payment." Anh admin đang bận migration, để ticket 3 ngày mới xử lý. Trong 3 ngày đó, đội dev vẫn phải đoán mò ticket nào đang chờ review.
Diễn giải: Vấn đề là chị Hương không biết mình chính là Board Admin của board đó. Việc thêm một cột vào board (Board settings → Columns) là quyền cấp board, chị hoàn toàn tự làm trong 2 phút mà không cần đụng System Admin. Lưu ý nhỏ: thêm cột board khác với thêm status vào workflow — cột chỉ là cách nhóm hiển thị các status sẵn có; nếu status "Code Review" chưa tồn tại trong workflow thì mới cần nhờ admin. May mắn là status đã có sẵn, chỉ chưa được ánh xạ vào cột.
Bài học: Trước khi gửi ticket cho admin, hãy tự hỏi "đây có phải cấu hình cấp board không?" Rất nhiều thứ tưởng cần admin thực ra nằm ngay trong Board settings mà PM có toàn quyền.
Tình huống 2: Yêu cầu bất khả thi vì không hiểu scheme
Bối cảnh: Anh Tuấn, PM tại một công ty outsourcing phần mềm ở Đà Nẵng (~200 nhân sự, Jira Cloud Company-managed, quản lý 15 project khách hàng), muốn đổi tên field "Story Points" thành "Điểm nỗ lực" chỉ riêng cho project của khách hàng Nhật Bản, vì họ yêu cầu giao diện thuần bản địa.
Anh gửi yêu cầu, và admin trả lời: "Không làm riêng được." Anh Tuấn khó chịu, nghĩ admin lười.
Diễn giải: Trong Company-managed, "Story Points" là một custom field toàn cục dùng chung cho cả 15 project. Đổi tên field là đổi cho tất cả — không thể đổi riêng một project. Admin không lười, mà kiến trúc scheme của Jira đúng là như vậy. Giải pháp thực tế: (1) tạo một custom field mới riêng, hoặc (2) chuyển project khách hàng Nhật sang Team-managed để tự chủ đặt tên field, hoặc (3) dùng field context để cấu hình hiển thị theo project — nhưng tên hiển thị của field vẫn là toàn cục.
Bài học: Hiểu khái niệm "field dùng chung qua scheme" giúp PM đưa ra yêu cầu khả thi ngay từ đầu, thay vì đổ lỗi cho admin và mất thiện cảm với người mà mình cần hợp tác lâu dài.
Tình huống 3: Tận dụng Team-managed để tự chủ
Bối cảnh: Đội Growth của một công ty SaaS Việt Nam (thuộc nhóm sản phẩm B2B, đội 8 người) mới thành lập, cần Jira gấp để chạy sprint. Nếu chờ IT tạo Company-managed project với đầy đủ workflow scheme, permission scheme, phải mất 2 tuần vì hàng đợi IT dài.
PM của đội — anh Nam — quyết định tự tạo một Team-managed project. Trong vòng một buổi chiều, anh tự thiết lập được issue type (Story, Bug, Task, Spike), một workflow đơn giản (To Do → In Progress → Review → Done), thêm vài custom field như "Growth Channel", và bật board Scrum. Đội bắt đầu chạy sprint ngay tuần sau.
Diễn giải: Team-managed project trao cho PM quyền tự cấu hình gần như toàn bộ trong phạm vi project mà không cần System Admin. Đánh đổi là các cấu hình này không tái sử dụng cho project khác, và một số report nâng cao (như Advanced Roadmaps đa đội) bị hạn chế. Với một đội nhỏ, độc lập, mới thành lập — đây là lựa chọn tối ưu.
Bài học: Biết được "mình có thể tự chủ ở mức nào" giúp PM chủ động và nhanh nhẹn, thay vì mặc định mọi thứ đều phải qua IT. Nhưng phải cân nhắc đánh đổi dài hạn: nếu đội sẽ mở rộng và cần liên kết nhiều project, Company-managed lại tốt hơn.
Hướng dẫn từng bước
Đây là quy trình tư duy tôi khuyên bạn áp dụng mỗi khi cần một thay đổi trong Jira.
Bước 1 — Xác định loại project của bạn. Vào project → xem góc dưới cùng của sidebar hoặc phần Project settings. Jira sẽ ghi rõ "You're in a team-managed project" hoặc "company-managed project". Đây là điều đầu tiên phải biết, vì nó quyết định phạm vi quyền tự chủ của bạn.
Bước 2 — Kiểm tra xem thay đổi thuộc tầng nào. Hỏi bản thân: thay đổi này ảnh hưởng (a) chỉ một board, (b) một project, hay (c) nhiều project/toàn hệ thống? Nếu (a) hoặc (b) và bạn là Board/Project Admin, khả năng cao bạn tự làm được.
Bước 3 — Thử tự làm trước ở đúng nơi. Với board: mở Board settings (biểu tượng ba chấm ở góc board) → tìm mục Columns, Swimlanes, Quick Filters, Card Layout. Với project: mở Project settings → xem Access/People, Details, và (nếu Team-managed) Issue types, Workflows, Fields, Features. Rất nhiều nhu cầu được giải quyết ngay tại đây.
Bước 4 — Nếu bị chặn, xác định chính xác cái bạn cần. Đừng gửi yêu cầu mơ hồ. Ghi rõ: tên project, tên board, tên field/status/workflow cụ thể, và kết quả mong muốn (không phải giải pháp bạn nghĩ). Ví dụ nói "Tôi cần phân biệt ticket đang chờ QA test" tốt hơn là "Thêm status QA" — vì admin có thể có cách giải quyết tốt hơn ý bạn.
Bước 5 — Viết yêu cầu cho admin theo cấu trúc. Một request tốt gồm: Bối cảnh (tại sao cần), Thay đổi cụ thể (cái gì), Phạm vi (project nào, có ảnh hưởng project khác không), Độ khẩn (deadline sprint). Điều này giúp admin đánh giá tác động và làm đúng ngay lần đầu.
Bước 6 — Ghi lại và theo dõi. Với cấu hình dùng chung (scheme, field toàn cục), hãy ghi vào một trang tài liệu chung để lần sau bạn và đồng nghiệp không lặp lại yêu cầu trùng. Điều này cực kỳ giá trị khi đội đông và nhiều project.
Lỗi thường gặp & mẹo
Lỗi 1: Mặc định mọi thứ phải nhờ IT. Đây là lỗi phổ biến nhất và tốn kém nhất về thời gian. Rất nhiều PM không biết mình là Board Admin. Mẹo: mỗi khi định gửi ticket cho admin, dành 60 giây mở Board settings và Project settings để kiểm tra xem tùy chọn đó có nằm ngay trước mắt bạn không.
Lỗi 2: Nhầm "cột board" với "status workflow". Thêm/xóa/đổi thứ tự cột trên board là quyền Board Admin. Nhưng thêm một status hoàn toàn mới hay sửa transition (luồng chuyển trạng thái) trong Company-managed lại cần Jira Admin sửa workflow scheme. Mẹo: cột chỉ là "cách nhóm hiển thị" các status đã tồn tại; status là "thực thể" trong workflow. Phân biệt hai khái niệm này giúp bạn biết khi nào tự làm được.
Lỗi 3: Yêu cầu đổi field/scheme dùng chung cho riêng mình. Như tình huống anh Tuấn — trong Company-managed, field và scheme thường dùng chung. Mẹo: nếu cần cấu hình thật sự riêng biệt, cân nhắc Team-managed project hoặc yêu cầu admin tạo field context riêng theo project.
Lỗi 4: Không xin quyền Project Admin từ đầu. Nhiều PM chỉ là "Member" bình thường của project và không biết mình có thể xin nâng lên role Administrator của project đó. Mẹo: ngay khi nhận một project, hãy đề nghị admin cấp cho bạn Project Admin role — nó mở ra rất nhiều quyền tự chủ hợp lý.
Lỗi 5: Nghịch cấu hình khi không hiểu tác động. Ngược lại với lỗi 1 — nếu tình cờ được cấp quyền System Admin, đừng vọc lung tung. Sửa một workflow scheme dùng chung có thể phá vỡ board của 10 đội khác. Mẹo: với cấu hình dùng chung, luôn hỏi admin trước và ưu tiên thử trên một project sandbox.
Mẹo vàng — xây quan hệ với Jira Admin. Admin là đồng minh chiến lược của PM. Hãy hiểu họ đang bận gì, gửi yêu cầu rõ ràng, gom nhóm các yêu cầu nhỏ thay vì bắn lẻ tẻ, và cảm ơn khi họ hỗ trợ nhanh. Một PM được admin quý sẽ được xử lý ưu tiên — điều này ảnh hưởng trực tiếp đến tốc độ đội bạn.
Bài tập thực hành
- Xác định loại project của bạn. Mở project Jira bạn đang dùng (hoặc tạo một project miễn phí trên Jira Cloud để thử). Tìm và ghi lại: đây là Team-managed hay Company-managed? Bạn đang có role gì trong project (Member hay Administrator)?
- Lập bản đồ quyền của chính bạn. Mở Board settings và Project settings, liệt kê ra 5 thứ bạn tự cấu hình được và 5 thứ bạn không thấy tùy chọn (tức phải nhờ admin). So sánh với danh sách phân loại trong bài.
- Thực hành một thay đổi cấp board. Vào Board settings, thêm một Quick Filter mới (ví dụ filter "Của tôi" với JQL
assignee = currentUser()), rồi thêm một cột mới nếu workflow có status trống chưa được ánh xạ. Quan sát bạn làm được đến đâu mà không cần admin.
- Viết một request chuẩn cho admin. Giả định bạn cần thêm một status "Waiting for Customer" vào workflow của một Company-managed project. Soạn một yêu cầu đầy đủ theo cấu trúc ở Bước 5: Bối cảnh, Thay đổi cụ thể, Phạm vi, Độ khẩn. Mục tiêu là admin đọc xong hiểu ngay, không cần hỏi lại.
- Tự đánh giá tình huống. Đọc lại 3 tình huống trong bài. Với mỗi tình huống, viết một câu trả lời: nếu là bạn, bạn sẽ tự làm gì và nhờ admin phần gì?
Tóm tắt
Vai trò của PM không phải là quản trị Jira, mà là hiểu đủ về Jira admin để tự phục vụ những gì trong tầm tay và giao tiếp hiệu quả cho phần còn lại. Ba ý cốt lõi cần mang theo:
- Nắm ba tầng quyền: System Admin (toàn cục, không phải việc của PM), Project Admin (nên chủ động xin), Board Admin (đụng hằng ngày). Nguyên tắc phân định: thay đổi chỉ ảnh hưởng board/project của bạn thì nhiều khả năng tự làm được; ảnh hưởng nhiều project/hệ thống thì phải nhờ admin.
- Phân biệt Team-managed và Company-managed project. Team-managed cho PM quyền tự chủ cao trong phạm vi project mà không cần admin; Company-managed dùng scheme chung, mọi thay đổi cấu trúc phải qua Jira Admin. Biết mình đang ở loại nào là bước đầu tiên trước mọi hành động.
- Giao tiếp với admin như một đồng minh. Trước khi gửi ticket, tự kiểm tra Board/Project settings. Khi cần nhờ, viết yêu cầu rõ ràng: bối cảnh, thay đổi cụ thể, phạm vi, độ khẩn — và mô tả kết quả mong muốn thay vì áp đặt giải pháp.