Priority
Thứ tự cần xử lý một defect, quyết định bởi tác động kinh doanh và lịch phát hành chứ không chỉ bởi mức hỏng. Một lỗi nhỏ vẫn có thể ưu tiên cao nếu khách nhìn thấy mỗi ngày.
Định nghĩa
Cùng một danh sách 40 defect, ai cũng muốn cái của mình được sửa trước. Priority là cách trả lời câu hỏi đó bằng lý lẽ thay vì bằng giọng nói to. Nó dựa trên tác động kinh doanh, số người bị ảnh hưởng, và thời điểm — chứ không dựa trên việc lỗi trông ghê tới đâu.
Priority là thứ tự xếp hàng để sửa; nó do phía nghiệp vụ quyết định, không phải do người phát hiện lỗi.
Các mức và thời hạn tương ứng
Nhiều dự án gắn thẳng priority với cam kết thời gian, đặc biệt sau khi go-live và có hợp đồng bảo trì.
| Mức | Ý nghĩa | Thời hạn hay cam kết |
|---|---|---|
| P1 – Urgent | Chặn nghiệp vụ đang diễn ra | Bắt tay xử lý trong 1 giờ, fix trong ngày |
| P2 – High | Ảnh hưởng nhiều người dùng, có cách đi vòng | Trong bản phát hành gần nhất |
| P3 – Medium | Gây khó chịu, chưa cản trở | Sprint kế tiếp |
| P4 – Low | Có thì tốt | Khi nào rảnh, hoặc gộp vào đợt dọn dẹp |
Con số cụ thể tùy hợp đồng. Điều cần tránh là để mức priority thành lời hứa suông: ghi P1 fix trong 4 giờ mà đội trực chỉ có một người và người đó đang nghỉ phép thì cam kết đó vô nghĩa.
Ai đặt và ai được đổi
QC đề xuất, nhưng người chốt nên là PO, BA hoặc business owner. Lý do đơn giản: chỉ họ biết tuần sau có chương trình khuyến mãi lớn hay không, biết phòng kế toán đang chốt sổ, biết khách hàng nào vừa dọa hủy hợp đồng.
Buổi triage defect nên gọn: đi qua danh sách mới, thống nhất severity và priority, gán người, xong trong 20 phút. Hễ nó biến thành buổi phân tích kỹ thuật là mất tiếng rưỡi, mà phần phân tích đó dev vẫn phải làm lại lúc ngồi vào code.
Ví dụ thực tế
Hai defect rơi vào cùng một ngày, và đội trực chỉ đủ người cầm một cái trước. Nền tảng học trực tuyến, cao điểm khoảng 2.700 học viên vào lớp cùng lúc buổi tối.
Cái thứ nhất: video bài giảng không tua được ở trình duyệt Safari trên máy Mac. Severity đặt Medium, nhưng khi kiểm số liệu thì 18% học viên dùng đúng cấu hình đó. Priority lên P1.
Cái thứ hai: trang quản trị hiển thị sai tổng số học viên đã hoàn thành khóa, lệch vài đơn vị. Severity High vì số liệu sai, nhưng báo cáo này chỉ dùng cho cuộc họp cuối tháng, còn 12 ngày nữa. Priority P3.
Hai defect, hai hướng ngược nhau so với severity. Đó là lý do phải có cả hai trường, không gộp làm một.
Lỗi hay gặp
- Gộp severity và priority thành một trường cho gọn, rồi cãi nhau kiểu "sao lỗi Critical mà chưa sửa" ngay từ buổi triage thứ hai.
- Mọi defect của khách đều thành P1. Danh sách 30 cái P1 thì thực chất không có cái nào là P1.
- Đặt priority rồi không bao giờ xem lại. Sát ngày go-live, bối cảnh đã đổi, danh sách ưu tiên cũng phải đổi theo.
- Để dev tự chọn cái nào sửa trước theo mức độ dễ. Sửa được nhiều ticket nhưng toàn ticket không ai cần.
Cách BA bảo vệ quyết định ưu tiên
Khi phải nói với khách rằng lỗi của họ xếp P3, đừng nói khơi khơi là chưa quan trọng. Đưa ba dữ kiện: bao nhiêu người bị ảnh hưởng, có cách làm tạm nào không, và cái đang chen lên trước là gì. Khách phản ứng với việc bị gạt ra ngoài, chứ ít khi phản ứng với một lập luận có số.
Và ghi lại quyết định đó vào ticket, kèm ngày. Sáu tuần sau khi có người hỏi "ai bảo để lại", bạn có câu trả lời mà không cần dựa vào trí nhớ.
