Mở đầu — vì sao bài này quan trọng
Nếu bạn từng mở một issue trong Jira và tự hỏi "làm sao để biết feature này thuộc khách hàng nào?", "team nào đang chịu trách nhiệm?", hay "chi phí ước tính bao nhiêu?" — thì bạn đang chạm đúng vào lý do tồn tại của Custom Fields. Jira mặc định chỉ cho bạn một bộ trường cơ bản: tiêu đề, mô tả, độ ưu tiên, nhãn... Nhưng mỗi tổ chức lại có ngôn ngữ riêng, quy trình riêng, dữ liệu riêng cần theo dõi. Custom Fields chính là cách bạn dạy cho Jira "nói tiếng nói của công ty mình".
Với vai trò PM, việc thiết kế trường dữ liệu không chỉ là chuyện kỹ thuật của admin. Nó quyết định trực tiếp đến chất lượng báo cáo, khả năng lọc dữ liệu bằng JQL, và cả trải nghiệm của kỹ sư khi tạo issue. Một hệ thống trường được thiết kế tốt giúp bạn trả lời câu hỏi của sếp trong 30 giây. Một hệ thống trường lộn xộn — với 400 trường trùng lặp, không ai nhớ trường nào để làm gì — sẽ biến Jira của bạn thành một bãi rác dữ liệu, chậm chạp và không đáng tin.
Bài này tập trung vào hai thứ: Custom Fields (tạo và quản lý các trường tùy chỉnh) và Field Configuration (cấu hình cách các trường đó hiển thị, bắt buộc hay ẩn theo từng ngữ cảnh). Đây là nền tảng để bạn kiểm soát dữ liệu — thứ mà các bài sau về Dashboard, Report hay Automation đều phải dựa vào.
Khái niệm cốt lõi
Built-in fields — bộ trường mặc định bạn cần thuộc lòng
Trước khi tạo trường mới, hãy hiểu rõ những gì Jira đã cho sẵn. Rất nhiều PM tạo trường trùng lặp chỉ vì không biết Jira đã có sẵn trường đó:
- Summary — tiêu đề issue, bắt buộc, ngắn gọn. Đây là trường xuất hiện ở mọi nơi (board, backlog, report), nên hãy dạy team viết summary có cấu trúc.
- Description — mô tả chi tiết, hỗ trợ rich text, bảng, ảnh, checklist.
- Priority — độ ưu tiên (Highest, High, Medium, Low, Lowest). Có thể tùy biến danh sách này.
- Labels — nhãn tự do, không phân cấp. Ai cũng gõ được, nên dễ loạn (ví dụ vừa
mobilevừaMobilevừamobile-app). - Components — thành phần của dự án (ví dụ: Payment, Notification, Auth). Admin định nghĩa sẵn, có thể gán component lead tự động.
- Fix Version — phiên bản mà issue này sẽ được vá/phát hành trong đó.
- Affects Version — phiên bản đang bị lỗi (dùng nhiều cho bug).
- Story Points — điểm ước lượng nỗ lực, dùng cho velocity (sẽ học sâu ở Bài 14).
- Sprint — sprint mà issue thuộc về, gắn với board Scrum.
Custom Fields — khi trường mặc định không đủ
Custom Field là trường bạn tự tạo để lưu dữ liệu đặc thù. Jira Cloud hỗ trợ nhiều kiểu trường (field type), mỗi kiểu phục vụ mục đích khác nhau:
- Text (single-line / paragraph) — nhập tự do. Linh hoạt nhưng khó thống kê. Ví dụ: "Ghi chú khách hàng".
- Select List (single choice) — chọn 1 trong danh sách định sẵn. Cực tốt để báo cáo. Ví dụ: "Loại yêu cầu" = Feature / Bug / Improvement.
- Select List (multiple choice) / Checkboxes — chọn nhiều giá trị. Ví dụ: "Nền tảng bị ảnh hưởng" = iOS, Android, Web.
- Radio Buttons — chọn 1, hiển thị dạng nút tròn. Hợp với 2–4 lựa chọn.
- Number — số. Ví dụ: "Chi phí ước tính (triệu VND)", "Số khách hàng bị ảnh hưởng".
- Date / Date Time Picker — ngày/giờ. Ví dụ: "Ngày cam kết với khách hàng".
- User Picker — chọn người dùng. Ví dụ: "Business Owner", "QA phụ trách".
- Cascading Select — chọn phân cấp cha–con. Ví dụ: Khu vực → Tỉnh/thành.
- Labels — kiểu nhãn tự do (giống built-in nhưng bạn tạo trường riêng).
Field Configuration — cấu hình hành vi của trường
Tạo được trường mới chỉ là một nửa. Nửa còn lại là Field Configuration — nơi bạn quyết định với mỗi trường:
- Required hay Optional — trường có bắt buộc điền không? Ví dụ: bug thì "Steps to Reproduce" nên bắt buộc.
- Hidden hay Visible — trường có hiển thị không? Bạn có thể ẩn trường không dùng để màn hình đỡ rối.
- Description / Help text — dòng gợi ý dưới trường để hướng dẫn người điền.
- Renderer — cách hiển thị (ví dụ trường mô tả dùng wiki-style renderer).
- Custom Field (trường) tồn tại toàn hệ thống.
- Trường được đưa lên Screen (màn hình tạo/sửa/xem) thông qua Screen Scheme và Issue Type Screen Scheme.
- Field Configuration quyết định trường đó bắt buộc/ẩn ra sao.
- Field Configuration Scheme ánh xạ Field Configuration nào áp dụng cho issue type nào, trong project nào.
Custom vs Global — bài học đắt giá về hiệu năng
Có một sự thật ít người nói với PM mới: mỗi Custom Field bạn tạo ra đều làm Jira chậm đi một chút. Jira lập chỉ mục (index) tất cả các trường. Khi một instance có 600–800 custom field (chuyện rất thường gặp ở công ty lớn), việc tìm kiếm và render màn hình chậm thấy rõ. Đây là lý do vì sao quản trị trường (field governance) là một kỹ năng thật sự, không phải chuyện "cứ thích thì tạo".
Tình huống thực tế
Tình huống 1 — Tiki và trường "Loại yêu cầu" cứu vãn báo cáo
Một team Product tại một sàn TMĐT lớn ở Việt Nam (bối cảnh giả định dựa trên mô hình Tiki) gặp vấn đề: Ban lãnh đạo hỏi "quý này chúng ta làm bao nhiêu % feature mới so với sửa lỗi kỹ thuật (tech debt)?". PM không trả lời được, vì team dùng Labels để phân loại — người thì gõ feature, người gõ new-feature, người gõ FEATURE. Xuất báo cáo ra thì rời rạc, không cộng được.
Giải pháp: PM tạo một Custom Field kiểu Select List (single choice) tên "Work Category" với đúng 4 giá trị: New Feature, Improvement, Tech Debt, Bug Fix. Đặt trường này Required cho mọi Story và Task thông qua Field Configuration. Sau 2 sprint, dữ liệu đã đủ sạch để dựng biểu đồ: 55% New Feature, 20% Improvement, 15% Tech Debt, 10% Bug Fix.
Bài học: Khi cần báo cáo theo phân loại, đừng bao giờ tin vào Labels tự do. Một trường Select List bắt buộc, với danh sách được kiểm soát, giá trị hơn hàng chục nhãn hỗn loạn.
Tình huống 2 — Startup fintech và cái bẫy 3 trường "Customer"
Một startup fintech ở Singapore mở rộng nhanh, mỗi squad tự tạo trường của mình. Sau một năm, khi PM Lead làm audit, họ phát hiện có ba trường khác nhau cùng lưu tên khách hàng: "Customer", "Client Name", và "Account". Ba team dùng ba trường khác nhau, nên không thể làm một dashboard tổng "tất cả issue của khách hàng ABC". JQL phải viết Customer ~ "ABC" OR "Client Name" ~ "ABC" OR Account ~ "ABC" — vừa dài vừa dễ sót.
Giải pháp: PM Lead hợp nhất về một trường duy nhất tên "Customer" kiểu Select List, migrate dữ liệu cũ sang, rồi xóa hai trường thừa. Sau đó ban hành quy tắc: mọi trường mới phải qua duyệt của một người quản trị trường (field steward).
Bài học: Không có quản trị, số lượng trường bùng nổ và trùng lặp là điều gần như chắc chắn. Một trường được dùng chung tốt hơn ba trường "gần giống nhau". Trước khi tạo trường mới, luôn tìm xem trường tương tự đã tồn tại chưa.
Tình huống 3 — Team Bug Triage và Field Configuration theo issue type
Một công ty gia công phần mềm ở TP.HCM có quy trình bug rất nghiêm. Họ cần bug phải có "Steps to Reproduce", "Environment" (Production/Staging/Dev), và "Severity" — nhưng những trường này hoàn toàn vô nghĩa với Story hay Epic. Nếu bắt mọi issue type đều điền, kỹ sư sẽ bực bội và điền bừa.
Giải pháp: Họ tạo một Field Configuration riêng cho issue type Bug, trong đó ba trường trên là Required; và một Field Configuration khác cho Story/Epic, trong đó ba trường này Hidden. Hai config được gộp vào một Field Configuration Scheme gán cho project. Kết quả: form tạo Bug gọn, đúng trọng tâm; form tạo Story không bị nhiễu.
Bài học: Field Configuration cho phép cùng một trường hành xử khác nhau theo loại issue. Đây là chìa khóa để form vừa nghiêm ngặt khi cần, vừa nhẹ nhàng khi không cần.
Hướng dẫn từng bước
Giả sử bạn muốn tạo trường "Work Category" bắt buộc cho Story (giống Tình huống 1). Với Jira Cloud, quyền admin dự án hoặc admin instance:
- Kiểm tra trước khi tạo. Vào Settings → Issues → Custom fields, dùng ô search gõ "category", "type", "work"... để chắc chắn chưa có trường tương tự. Đây là bước quan trọng nhất mà ai cũng bỏ qua.
- Tạo Custom Field. Nhấn Create custom field → chọn kiểu Select List (single choice) → đặt tên rõ ràng "Work Category" → thêm description "Phân loại công việc để báo cáo tỉ trọng feature/tech debt".
- Nhập các giá trị (options). New Feature, Improvement, Tech Debt, Bug Fix. Sắp xếp thứ tự hợp lý. Tránh để giá trị mơ hồ như "Other".
- Gắn trường lên Screen. Trong bước tạo, Jira hỏi bạn muốn hiện trường này trên màn hình nào — chọn Create screen và Edit screen của project liên quan. Nếu bỏ qua, trường tồn tại nhưng không ai thấy để điền.
- Cấu hình Field Configuration. Vào Settings → Issues → Field configurations, mở configuration đang áp dụng cho project → tìm "Work Category" → nhấn Required để bắt buộc. Nếu muốn bắt buộc chỉ với Story, hãy dùng một Field Configuration riêng và ánh xạ qua Field Configuration Scheme.
- Kiểm tra bằng JQL. Sau vài issue, mở JQL gõ
"Work Category" = "Tech Debt"để xác nhận trường lọc được. Nếu tên trường có dấu cách, nhớ đặt trong ngoặc kép.
- Dựng nhanh một report/dashboard. Dùng gadget "Pie Chart" nhóm theo "Work Category" để nhìn ngay tỉ trọng — bằng chứng cho thấy trường đã phát huy tác dụng.
Lỗi thường gặp & mẹo
- Dùng Text cho dữ liệu cần báo cáo. Đây là lỗi số một. "Team" hay "Loại yêu cầu" mà để Text tự do thì không bao giờ thống kê nổi. Luôn dùng Select List cho dữ liệu phân loại.
- Tạo trường trùng lặp. Trước khi tạo, hãy search. "Customer" đã có rồi thì đừng tạo "Client". Đặt ra một người duyệt trường (field steward) nếu công ty đủ lớn.
- Bắt buộc quá nhiều trường. Mỗi trường Required là một rào cản. Kỹ sư sẽ điền bừa để cho qua, làm dữ liệu bẩn hơn cả khi để trống. Chỉ bắt buộc thứ thật sự cần cho quy trình.
- Quên gắn trường lên Screen. Trường tạo xong nhưng không hiện — dấu hiệu là "trường tồn tại trong JQL nhưng không thấy khi tạo issue". Kiểm tra Screen Scheme.
- Nhầm giữa Field Configuration và Screen. Screen quyết định trường có xuất hiện trên form không. Field Configuration quyết định trường đó bắt buộc/ẩn ra sao. Ẩn ở Field Configuration mạnh hơn — trường sẽ biến mất kể cả khi có trên Screen.
- Lạm dụng, gây phình instance. Vài trăm trường sẽ làm Jira chậm. Định kỳ (6 tháng/lần) dùng công cụ như "Field usage" hoặc plugin để tìm trường không dùng và lưu trữ/xóa.
- Mẹo đặt tên: đặt tên trường theo chuẩn nhất quán, có thể thêm tiền tố nếu là trường riêng của một team (ví dụ
[Growth] Experiment ID) để dễ tìm và biết chủ sở hữu.
Bài tập thực hành
- Audit hiện trạng. Vào instance Jira của bạn (hoặc tạo tài khoản Jira Cloud free), mở danh sách Custom fields. Đếm xem có bao nhiêu trường, và tìm ít nhất 2 cặp trường có vẻ trùng lặp về mục đích. Ghi lại phương án hợp nhất.
- Thiết kế trường báo cáo. Tạo một Custom Field kiểu Select List tên "Work Category" với 4 giá trị như trong bài. Gắn nó lên màn hình tạo issue, tạo thử 5 issue với các phân loại khác nhau.
- Cấu hình theo issue type. Tạo (hoặc dùng có sẵn) một trường "Steps to Reproduce". Cấu hình sao cho nó Required với Bug nhưng Hidden với Story. Tạo thử một Bug và một Story để xác nhận hành vi khác nhau.
- Kiểm chứng bằng JQL và biểu đồ. Viết một câu JQL lọc theo "Work Category", rồi dựng một Pie Chart gadget nhóm theo trường này. Chụp lại kết quả — đây chính là "giá trị đầu ra" mà một trường được thiết kế tốt mang lại.
Tóm tắt
Custom Fields và Field Configuration là công cụ để bạn biến Jira thành hệ thống nói đúng ngôn ngữ của tổ chức mình. Hãy nhớ ba điều cốt lõi. Thứ nhất, hiểu built-in fields trước để không tạo trùng — đặc biệt phân biệt Components (do admin kiểm soát, tốt cho báo cáo) với Labels (tự do, dễ loạn). Thứ hai, chọn đúng field type: mọi dữ liệu cần lọc hay báo cáo phải là Select List chứ không phải Text tự do. Thứ ba, Field Configuration cho phép một trường hành xử khác nhau theo issue type và project — bắt buộc chỗ này, ẩn chỗ kia — giúp form vừa nghiêm ngặt vừa gọn gàng.
Trên hết, hãy coi trường dữ liệu như một tài nguyên chung cần được quản trị. Tạo trường thì dễ, nhưng một instance với hàng trăm trường trùng lặp sẽ chậm, khó dùng và không đáng tin. Ít trường nhưng sạch và có chủ đích luôn thắng nhiều trường lộn xộn. Khi bạn kiểm soát tốt tầng dữ liệu này, mọi Dashboard, Report và Automation ở các bài sau sẽ tự nhiên trở nên mạnh mẽ và chính xác.