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: "Mình cần ghi lại số PO của khách hàng này ở đâu? Trường nào để chọn quốc gia? Làm sao gắn tên người duyệt yêu cầu?" — thì bạn đang chạm đúng vào lý do tồn tại của Custom Fields (trường tùy chỉnh).
JIRA mặc định cho bạn vài trường có sẵn như Summary, Description, Assignee, Priority. Nhưng mỗi doanh nghiệp, mỗi quy trình nghiệp vụ lại có những thông tin riêng cần theo dõi mà JIRA không thể đoán trước được: mã hợp đồng, phòng ban yêu cầu, mức độ ưu tiên theo OKR, môi trường triển khai, người phê duyệt cấp hai... Custom Fields chính là công cụ để bạn "may đo" JIRA cho đúng với ngôn ngữ nghiệp vụ của tổ chức mình.
Với một BA (Business Analyst), đây là kỹ năng cực kỳ thực dụng. Trường tùy chỉnh được thiết kế tốt sẽ giúp dữ liệu sạch, dễ lọc, dễ báo cáo. Ngược lại, một dự án nhồi nhét hàng trăm trường lộn xộn sẽ biến JIRA thành mớ bòng bong khiến cả team chán nản. Bài này tập trung vào bốn loại trường nền tảng mà BA dùng nhiều nhất: Text (ngắn và dài), Select (chọn một), Multi-select (chọn nhiều), và User Picker (chọn người dùng). Hiểu rõ bốn loại này, bạn đã đủ vũ khí để mô hình hóa phần lớn nhu cầu nghiệp vụ thực tế.
Khái niệm cốt lõi
Custom Field là một trường dữ liệu do bạn (hoặc JIRA admin) tạo thêm, gắn vào issue để lưu thông tin ngoài các trường mặc định. Mỗi trường có một loại (field type) quyết định cách người dùng nhập liệu và cách JIRA lưu trữ, lọc, báo cáo dữ liệu đó.
Điểm mấu chốt mà nhiều người mới bỏ qua: chọn đúng loại trường quan trọng hơn bạn nghĩ. Loại trường quyết định dữ liệu của bạn có thể truy vấn được hay không. Ví dụ, nếu bạn lưu "quốc gia" bằng một text field, mỗi người sẽ gõ một kiểu — "Vietnam", "Việt Nam", "VN", "vietnam" — và bạn vĩnh viễn không lọc gọn được. Nếu dùng Select, dữ liệu chuẩn hóa ngay từ đầu.
Text field (short) — ô nhập một dòng
Đây là trường nhập tự do, ngắn gọn, một dòng. Dùng cho những giá trị duy nhất, không lặp lại theo danh sách cố định, ví dụ: số PO (Purchase Order), mã ticket bên thứ ba, link tài liệu, mã hợp đồng. Ưu điểm là linh hoạt; nhược điểm là không kiểm soát được định dạng, nên chỉ dùng khi giá trị thực sự là tự do.
Text field (multi-line / paragraph) — ô nhập nhiều dòng
Giống text ngắn nhưng cho phép nhập đoạn văn dài, xuống dòng, đôi khi hỗ trợ định dạng văn bản. Phù hợp với ghi chú dài, mô tả acceptance criteria bổ sung, lý do từ chối, bối cảnh nghiệp vụ. Lưu ý: vì nội dung dài và tự do, trường này gần như không dùng để lọc hay báo cáo định lượng — nó để đọc, không để phân tích.
Select list (single choice) — chọn một trong danh sách
Người dùng chọn đúng một giá trị từ một danh sách cố định do bạn định nghĩa. Đây là loại trường "vàng" cho BA vì nó vừa chuẩn hóa dữ liệu vừa dễ truy vấn. Ví dụ điển hình: Phòng ban yêu cầu (Sales / Marketing / Finance), Môi trường (Dev / Staging / Production), Mức độ rủi ro (Cao / Trung bình / Thấp). Khi một thuộc tính chỉ có thể nhận một giá trị tại một thời điểm, hãy dùng Select.
Multi-select list — chọn nhiều giá trị
Tương tự Select nhưng cho phép chọn nhiều giá trị cùng lúc. Dùng khi một issue có thể liên quan đến nhiều phân loại song song. Ví dụ: một yêu cầu thay đổi có thể ảnh hưởng đến nhiều module (Đăng nhập, Thanh toán, Báo cáo), hoặc một story phục vụ nhiều nhóm khách hàng (B2B, B2C, Đối tác). Đừng nhầm: nếu thực tế chỉ được phép một giá trị, dùng Multi-select sẽ tạo lỗ hổng dữ liệu vì người dùng có thể chọn lung tung nhiều mục.
User Picker — chọn người dùng
Trường này cho phép gắn một (hoặc nhiều, với biến thể Multi-user Picker) tài khoản người dùng JIRA vào issue. Khác hoàn toàn với việc gõ tên vào text field: User Picker liên kết tới đúng tài khoản thật, nên bạn có thể lọc theo người đó, gửi thông báo cho họ, dùng trong automation. Ví dụ: Người phê duyệt nghiệp vụ (Business Approver), Stakeholder chính, Người kiểm thử UAT. Nhờ liên kết tài khoản thật, bạn có thể viết JQL kiểu "Business Approver" = currentUser() để mỗi người tự thấy việc cần duyệt của mình.
Bảng tổng hợp nhanh
| Loại trường | Trường hợp dùng tiêu biểu | Có lọc/báo cáo tốt? |
|---|---|---|
| Text (short) | Số PO, mã hợp đồng, link ngoài | Hạn chế |
| Text (multi-line) | Ghi chú dài, lý do, bối cảnh | Gần như không |
| Select (single) | Phòng ban, môi trường, mức rủi ro | Rất tốt |
| Multi-select | Module ảnh hưởng, nhóm khách hàng | Rất tốt |
| User Picker | Người duyệt, stakeholder, tester UAT | Rất tốt |
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán số PO lẫn lộn
Một team vận hành tại Tiki (giả định dựa trên bối cảnh thương mại điện tử Việt Nam) dùng JIRA để theo dõi yêu cầu tích hợp từ các nhà cung cấp. Ban đầu, BA cho cả team ghi "số PO" vào ngay phần Description. Sau ba tháng, có hơn 400 issue, và khi kế toán cần đối soát một PO cụ thể, không ai tìm ra nổi vì mỗi người ghi một chỗ, một định dạng: "PO: 12345", "Purchase order 12345", "po-12345".
BA quyết định tạo một Text field (short) tên "PO Number" và gắn vào màn hình tạo issue. Từ đó, số PO luôn ở đúng một chỗ, ai cũng biết nhập vào đâu. Họ còn dùng nó trong JQL: "PO Number" ~ "12345" để tra cứu tức thì.
Bài học: Ngay cả một text field đơn giản cũng tạo ra giá trị lớn khi nó buộc dữ liệu nằm đúng chỗ, thay vì trôi nổi trong mô tả. Tuy nhiên BA cũng nhận ra giới hạn: vì là text tự do, vẫn có người gõ thừa khoảng trắng. Bài học sâu hơn là phải kèm hướng dẫn nhập liệu rõ ràng.
Ví dụ 2 — Ngân hàng VPBank và quy trình phê duyệt thay đổi
Tại một dự án core banking ở VPBank (giả định), mỗi Change Request bắt buộc phải có người phê duyệt nghiệp vụ và ghi rõ môi trường triển khai cùng các module bị ảnh hưởng — vì lý do tuân thủ. BA thiết kế ba trường:
- User Picker "Business Approver": gắn đúng tài khoản trưởng phòng nghiệp vụ. Nhờ vậy, automation có thể tự gửi thông báo và trường này lọc được bằng
"Business Approver" = currentUser()để mỗi sếp thấy danh sách cần duyệt của mình. - Select (single) "Target Environment": Dev / UAT / Production. Chỉ một giá trị vì một change không thể vừa Dev vừa Production tại cùng một bước.
- Multi-select "Affected Modules": Khoản vay / Thẻ / Tài khoản / Báo cáo. Một thay đổi có thể đụng nhiều module nên phải cho chọn nhiều.
Bài học: Việc phân biệt rạch ròi đâu là "chọn một" (môi trường) và đâu là "chọn nhiều" (module) phản ánh đúng bản chất nghiệp vụ. Chọn sai loại trường ở đây sẽ phá vỡ khả năng tuân thủ và báo cáo.
Ví dụ 3 — Startup Grab Kitchen và trường multi-select bị lạm dụng
Một team sản phẩm (giả định theo mô hình Grab) tạo trường Multi-select "Customer Segment" với cả chục giá trị, rồi để mặc cho ai cũng tích chọn thoải mái. Sau một quý, gần như mọi issue đều chọn 5–6 segment, khiến báo cáo "story nào phục vụ segment B2B" trả về... gần hết backlog, vô nghĩa.
BA vào cuộc, rà soát lại: rút danh sách xuống còn 4 segment thật sự khác biệt, và đặt quy ước "chỉ chọn segment chính, tối đa 2". Dữ liệu sạch trở lại, báo cáo có ý nghĩa.
Bài học: Multi-select rất mạnh nhưng cũng dễ bị lạm dụng. Quyền chọn nhiều không có nghĩa là khuyến khích chọn nhiều. Quy ước sử dụng quan trọng ngang với việc tạo trường.
Hướng dẫn từng bước
Dưới đây là quy trình tạo và áp dụng một Custom Field (thao tác trên JIRA Cloud, giao diện admin; bạn cần quyền JIRA Administrator).
- Xác định nhu cầu trước khi tạo. Tự hỏi: thông tin này có thực sự cần tách riêng không? Giá trị tự do hay danh sách cố định? Một hay nhiều? Là người dùng hay văn bản? Câu trả lời sẽ chỉ thẳng loại trường cần dùng.
- Vào phần quản trị trường. Chọn biểu tượng bánh răng Settings → Issues → Custom fields, rồi bấm Create custom field.
- Chọn đúng loại trường. Chọn Text Field (single line) / Text Field (multi-line) / Select List (single choice) / Select List (multiple choices) / User Picker (single hoặc multiple user) tùy nhu cầu đã xác định ở bước 1.
- Đặt tên rõ ràng và mô tả. Tên trường nên dễ hiểu, nhất quán với ngôn ngữ team (ví dụ "PO Number", "Business Approver"). Phần Description nên ghi rõ cách nhập để hướng dẫn người dùng — đây là chi tiết hay bị bỏ qua nhưng cực kỳ giá trị.
- Định nghĩa các giá trị (với Select / Multi-select). Nhập danh sách lựa chọn. Hãy giữ danh sách gọn, không trùng nghĩa, không quá dài. Ít mà rõ luôn tốt hơn nhiều mà mơ hồ.
- Gắn trường vào Screen. Đây là bước người mới hay quên: tạo trường xong mà chưa gắn vào màn hình (screen) thì người dùng sẽ không nhìn thấy nó. Chọn các screen phù hợp (Create / Edit / View) cho đúng dự án và issue type.
- Cân nhắc Context và phạm vi. JIRA cho phép giới hạn trường chỉ áp dụng cho một số project hoặc issue type nhất định (field context). Dùng tính năng này để tránh trường xuất hiện tràn lan ở nơi không cần.
- Kiểm thử trên một issue thật. Tạo thử một issue, nhập dữ liệu, rồi chạy một câu JQL đơn giản (ví dụ
"Target Environment" = Production) để chắc chắn trường hoạt động và truy vấn được như mong đợi.
Lỗi thường gặp & mẹo
- Lạm dụng Text field cho dữ liệu lẽ ra phải chuẩn hóa. Nếu bạn thấy mình đang gõ đi gõ lại cùng vài giá trị (tên phòng ban, môi trường, trạng thái rủi ro), đó là tín hiệu nên chuyển sang Select. Text chỉ dành cho giá trị thật sự tự do, duy nhất.
- Tạo trùng trường. Trong tổ chức lớn, rất dễ có "Approver", "Người duyệt", "Reviewer" cùng tồn tại do nhiều người tạo. Trước khi tạo mới, hãy tìm xem đã có trường tương tự chưa. Trùng trường làm báo cáo phân mảnh và rối JIRA.
- Quên gắn vào Screen. Tạo trường nhưng không thấy nó hiển thị là tình huống kinh điển. Luôn nhớ bước gắn screen sau khi tạo.
- Dùng tên người trong Text thay vì User Picker. Gõ tên vào text khiến bạn mất khả năng lọc theo người, gửi thông báo, và dễ sai chính tả. Khi cần gắn một con người, gần như luôn dùng User Picker.
- Danh sách Select quá dài. Một dropdown 30 mục khiến người dùng chọn đại cho xong. Hãy giữ danh sách đủ ngắn để mọi lựa chọn đều có ý nghĩa rõ ràng.
- Mẹo dùng field context để dọn dẹp. Nếu một trường chỉ cần cho một dự án, dùng context giới hạn nó lại thay vì để toàn hệ thống. JIRA càng gọn, dữ liệu càng sạch.
- Mẹo đặt tên có tiền tố. Trong môi trường nhiều team, đặt tiền tố như "[BA] Business Approver" giúp dễ nhận diện và tránh trùng.
Bài tập thực hành
Hãy hình dung bạn là BA cho một dự án triển khai phần mềm quản lý kho cho một chuỗi bán lẻ tại TP.HCM. Yêu cầu: thiết kế bộ Custom Fields phục vụ theo dõi các yêu cầu thay đổi (Change Request).
- Liệt kê ít nhất năm thông tin nghiệp vụ cần theo dõi ngoài trường mặc định (gợi ý: mã hợp đồng nhà cung cấp, môi trường triển khai, module ảnh hưởng, người phê duyệt, ghi chú rủi ro).
- Với mỗi thông tin, chỉ định loại trường phù hợp trong bốn loại đã học (Text ngắn/dài, Select, Multi-select, User Picker) và giải thích lý do chọn loại đó — đặc biệt nêu rõ tại sao "chọn một" hay "chọn nhiều".
- Với hai trường Select/Multi-select, hãy viết ra danh sách giá trị cụ thể (giữ gọn, không trùng nghĩa).
- Viết một câu JQL đơn giản sử dụng một trong các trường bạn vừa thiết kế (ví dụ lọc tất cả change ở môi trường Production do bạn phụ trách duyệt).
- Nâng cao: chỉ ra một rủi ro lạm dụng có thể xảy ra với bộ trường của bạn (như ví dụ Multi-select bị tích chọn tràn lan) và đề xuất một quy ước sử dụng để phòng tránh.
Tóm tắt
Custom Fields là cách bạn "may đo" JIRA theo đúng ngôn ngữ nghiệp vụ của tổ chức, và với BA, kỹ năng quan trọng nhất là chọn đúng loại trường. Bốn loại nền tảng cần nắm vững:
- Text (short) cho giá trị tự do, duy nhất như số PO, mã hợp đồng.
- Text (multi-line) cho ghi chú dài để đọc, không để phân tích.
- Select (single) cho thuộc tính chỉ nhận một giá trị từ danh sách cố định — chuẩn hóa và dễ báo cáo.
- Multi-select cho thuộc tính nhận nhiều giá trị song song, nhưng cần quy ước để tránh lạm dụng.
- User Picker cho việc gắn người dùng thật, mở ra khả năng lọc, thông báo và automation.