Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm PM cho một sản phẩm số, bạn sẽ nhanh chóng nhận ra rằng bug không bao giờ đến từng cái một cách lịch sự. Chúng ập đến theo từng đợt: sau mỗi lần release, sau mỗi chiến dịch marketing kéo lượng người dùng tăng vọt, hoặc đơn giản là vào 3 giờ chiều thứ Sáu khi cả team đang mệt. Và câu hỏi đau đầu nhất không phải là "làm sao sửa bug này", mà là "trong 40 bug đang nằm chờ, cái nào phải sửa trước, cái nào để tuần sau, cái nào có thể bỏ luôn?".
Đó chính là bản chất của bug triage — quy trình phân loại và quyết định thứ tự xử lý bug. Từ "triage" mượn từ y khoa: khi có quá nhiều bệnh nhân và quá ít bác sĩ, người ta phải quyết định ai được cấp cứu trước. Trong phần mềm cũng vậy. Bạn không bao giờ có đủ thời gian và người để sửa hết mọi bug ngay lập tức, nên năng lực triage tốt là thứ phân biệt một PM chuyên nghiệp với một PM bị bug "dắt mũi".
Bài học này tập trung vào hai trụ cột: (1) cách phân biệt và sử dụng đúng Severity và Priority — hai khái niệm mà rất nhiều PM Việt Nam nhầm lẫn, và (2) cách vận hành một quy trình triage thực tế trong Jira. Đây là kỹ năng nền tảng mà bạn sẽ dùng gần như mỗi ngày trong sự nghiệp PM.
Khái niệm cốt lõi
Bug là gì và một bug report tốt trông ra sao
Trước khi phân loại, bạn cần một bug report đủ chất lượng để phân loại. Một bug report tệ ("app bị lỗi rồi anh ơi") khiến cả team tốn hàng giờ chỉ để hiểu chuyện gì đang xảy ra. Một bug report tốt luôn có ba thành phần: Steps to reproduce (các bước tái hiện), Expected result (kết quả mong đợi) và Actual result (kết quả thực tế). Kèm theo đó là môi trường (thiết bị, trình duyệt, phiên bản app), ảnh chụp màn hình hoặc video, và log nếu có.
Trong Jira, bug thường là một Issue Type riêng. Bạn sẽ dùng các trường như Environment, Affects Version/s để ghi rõ bối cảnh. Một mẹo nhỏ: hãy tạo sẵn một bug report template trong phần Description để bất kỳ ai — kể cả nhân viên chăm sóc khách hàng không rành kỹ thuật — cũng điền được đầy đủ thông tin.
Severity — mức độ nghiêm trọng về kỹ thuật
Severity trả lời câu hỏi: "Bug này gây hại đến mức nào?" Đây là góc nhìn kỹ thuật, đo lường tác động thực tế của lỗi lên hệ thống, bất kể ai là người dùng. Một thang Severity phổ biến gồm bốn bậc:
- S1 — Critical (Blocker): Hệ thống sập, mất dữ liệu, hoặc chức năng cốt lõi hoàn toàn không dùng được. Không có cách nào lách (workaround).
- S2 — Major: Chức năng quan trọng hỏng nhưng có cách lách tạm thời, hoặc chỉ ảnh hưởng một phần người dùng.
- S3 — Minor: Lỗi gây khó chịu nhưng không cản trở luồng chính. Ví dụ: một nút bị lệch, thông báo lỗi hiển thị sai.
- S4 — Trivial (Cosmetic): Lỗi thẩm mỹ nhỏ, sai chính tả, khoảng cách lệch vài pixel.
Priority — mức độ ưu tiên về nghiệp vụ
Priority trả lời câu hỏi khác hẳn: "Bug này cần được sửa sớm đến mức nào?" Đây là góc nhìn kinh doanh/nghiệp vụ, và đây chính là địa hạt của PM. Thang Priority mặc định trong Jira thường là: Highest, High, Medium, Low, Lowest — nhưng nhiều team dùng ký hiệu P1–P4:
- P1: Sửa ngay lập tức, có thể phải hotfix ngoài sprint.
- P2: Đưa vào sprint hiện tại hoặc sprint kế tiếp.
- P3: Xếp vào backlog, sửa khi có thời gian.
- P4: Sửa nếu tiện, hoặc chấp nhận sống chung.
Vì sao Severity ≠ Priority — và ma trận kết hợp
Đây là phần quan trọng nhất của bài. Nhiều người nghĩ bug nghiêm trọng thì đương nhiên phải sửa gấp — nhưng thực tế không phải lúc nào cũng vậy. Severity nói về mức độ hư hại, Priority nói về tính cấp bách kinh doanh. Hai chiều này độc lập với nhau.
Hãy hình dung ma trận:
- S1 + P1: Trang thanh toán sập, không ai mua được hàng. Vừa nghiêm trọng, vừa cấp bách. Đây là ship-stopper — dừng mọi thứ lại và sửa ngay.
- S1 + P3: Tính năng xuất báo cáo sang định dạng cổ mà chỉ 2 khách hàng dùng bị crash hoàn toàn. Nghiêm trọng về kỹ thuật (S1), nhưng vì ít người dùng và có thể xuất tay tạm thời nên không cấp bách (P3).
- S3 + P1: Logo công ty hiển thị sai màu ngay trên trang chủ đúng ngày ra mắt trước báo chí. Về kỹ thuật chỉ là lỗi thẩm mỹ (S3), nhưng vì lý do thương hiệu và thời điểm nên cực kỳ cấp bách (P1).
- S4 + P4: Sai chính tả ở trang footer ít người ghé. Vừa nhẹ, vừa không gấp — để dành khi rảnh.
Tình huống thực tế
Tình huống 1 — Tiki và cú "ship-stopper" mùa sale 11/11
Giả định một sàn thương mại điện tử lớn ở Việt Nam (lấy cảm hứng từ mô hình như Tiki) chuẩn bị cho đợt sale 11/11. Đúng 0h khi flash sale mở, team nhận báo cáo: khoảng 8% người dùng trên Android bấm "Đặt hàng" thì app văng ra, đơn không được ghi nhận. QA đánh giá S1 — mất chức năng cốt lõi, mất dữ liệu đơn hàng. PM lập tức gắn P1: mỗi phút trôi qua là hàng chục triệu đồng doanh thu bốc hơi trong khoảnh khắc lưu lượng cao nhất năm.
Team kích hoạt quy trình khẩn: một engineer dựng workaround (tự động retry đơn ở phía server), song song một người khác tìm nguyên nhân gốc (một thư viện thanh toán không xử lý được timeout khi tải cao). Trong 40 phút, hotfix được đẩy ra ngoài sprint. Trong Jira, bug này được đặt là P1/S1, gắn nhãn hotfix, và liên kết (link "is blocked by") tới ticket release khẩn.
Bài học: Khi S1 gặp P1, quy trình bình thường bị gác lại. Điều quan trọng là team đã thống nhất trước ngưỡng nào kích hoạt chế độ khẩn, nên không mất thời gian tranh luận lúc dầu sôi lửa bỏng.
Tình huống 2 — Startup fintech Singapore và cái bẫy "bug to nhưng không gấp"
Một startup fintech ở Singapore (khoảng 25 người) có tính năng xuất sao kê ra định dạng OFX để nạp vào phần mềm kế toán đời cũ. Một hôm QA phát hiện chức năng này crash hoàn toàn — đúng nghĩa S1 về kỹ thuật. Engineer trẻ trong team hoảng lên, đòi drop mọi thứ đang làm để sửa.
PM bình tĩnh kiểm tra dữ liệu analytics: trong 90 ngày, chỉ có 3 người dùng động đến tính năng này, và cả ba đều là khách đang dùng thử miễn phí. Có workaround: xuất ra CSV rồi convert. PM gắn P3, ghi rõ lý do trong comment Jira, và giữ nguyên sprint đang chạy (đang hoàn thiện tính năng onboarding mà 80% người dùng mới sẽ chạm vào). Bug OFX được đưa vào backlog và sửa hai tuần sau.
Bài học: Severity cao không tự động kéo Priority cao. Quyết định Priority phải dựa trên dữ liệu người dùng và giá trị kinh doanh, không dựa trên cảm giác hoảng loạn. Vai trò của PM là làm điểm tựa lý trí cho team.
Tình huống 3 — Agency phần mềm Đà Nẵng và buổi triage định kỳ
Một agency ở Đà Nẵng làm outsourcing, cùng lúc chạy 4 dự án. Trước đây bug từ khách hàng đổ thẳng vào Slack, ai rảnh thì nhặt, dẫn đến tình trạng bug dễ thì được sửa nhanh còn bug khó thì bị né suốt hàng tuần. PM quyết định lập buổi bug triage định kỳ: 30 phút mỗi sáng thứ Ba và thứ Năm, với sự tham gia của PM, tech lead và một QA.
Họ tạo một filter Jira: status = "Triage" AND type = Bug ORDER BY created DESC, hiển thị trên một board riêng. Mỗi bug được duyệt qua ba câu hỏi: (1) Đã đủ thông tin tái hiện chưa? (2) Severity là bao nhiêu? (3) Priority là bao nhiêu và assign cho ai? Sau ba tuần, thời gian trung bình để một bug rời khỏi trạng thái "Triage" giảm từ 6 ngày xuống còn 1,5 ngày, và không còn bug nào "mồ côi" quá một tuần.
Bài học: Triage không phải việc làm ngẫu hứng. Biến nó thành một nghi thức định kỳ với người tham gia cố định và tiêu chí rõ ràng sẽ xóa bỏ tình trạng bug bị bỏ rơi.
Hướng dẫn từng bước
Dưới đây là quy trình triage bạn có thể áp dụng ngay trong Jira:
Bước 1 — Thiết lập trạng thái "Triage" trong workflow bug. Tạo một status riêng (ví dụ: Open → Triage → To Do → In Progress → Done). Mọi bug mới rơi vào Triage và chưa được ai bắt tay làm cho đến khi được phân loại xong. Điều này ngăn bug "nhảy cóc" thẳng vào sprint mà chưa qua đánh giá.
Bước 2 — Chuẩn hóa hai trường Severity và Priority. Priority là trường có sẵn. Severity thì thường phải tạo custom field (một Select List với các giá trị S1–S4). Ghi rõ định nghĩa từng bậc vào một trang Confluence để cả team hiểu thống nhất — tránh chuyện mỗi người hiểu "Major" một kiểu.
Bước 3 — Kiểm tra chất lượng report. Bug thiếu bước tái hiện thì chưa thể phân loại. Trả nó về người báo cáo (status "Needs Info") thay vì đoán mò.
Bước 4 — Gán Severity trước (kỹ thuật), rồi Priority sau (nghiệp vụ). QA/engineer đề xuất Severity dựa trên tác động kỹ thuật. PM quyết định Priority dựa trên số người bị ảnh hưởng, giá trị khách hàng, thời điểm, rủi ro thương hiệu và pháp lý.
Bước 5 — Quyết định điểm đến. P1 → hotfix hoặc đưa vào sprint hiện tại. P2 → sprint kế tiếp. P3/P4 → backlog. Ghi lý do vào comment để sau này ai xem lại cũng hiểu vì sao.
Bước 6 — Assign và liên kết. Gán người phụ trách, link bug tới Story/Epic liên quan bằng "relates to" hoặc "is caused by", để giữ ngữ cảnh.
Bước 7 — Theo dõi bằng dashboard. Tạo gadget đếm số bug theo Priority, số bug đang tồn (open) và tuổi trung bình. Đây là "nhiệt kế sức khỏe" của sản phẩm.
Lỗi thường gặp & mẹo
Lỗi 1 — Dồn mọi bug vào P1. Khi mọi thứ đều "khẩn cấp" thì thực chất chẳng có gì khẩn cấp. Nếu backlog của bạn có 30 bug P1, đó là dấu hiệu Priority đã mất ý nghĩa. Mẹo: đặt quy tắc "chỉ được tối đa 3–5 bug P1 cùng lúc" để buộc team ra quyết định thật.
Lỗi 2 — Lẫn lộn Severity và Priority. Đây là lỗi kinh điển. Hãy nhắc bản thân: Severity do tác động kỹ thuật quyết định, Priority do giá trị kinh doanh và thời điểm quyết định. Đừng để một engineer tự nâng Priority chỉ vì bug "nhìn có vẻ to".
Lỗi 3 — Không có workaround trong đánh giá. Một bug S1 nhưng có cách lách dễ dàng thường được hạ Priority. Luôn hỏi: "Người dùng có thể tạm thời làm gì khác không?"
Lỗi 4 — Bug "mồ côi". Bug không ai được assign sẽ chết dần trong backlog. Buổi triage định kỳ và filter "bug chưa assign" là thuốc giải.
Lỗi 5 — Không phân biệt bug với change request. Rất nhiều "bug" báo lên thực ra là yêu cầu tính năng mới hoặc hiểu nhầm cách dùng. Lọc chúng ra khỏi luồng bug để số liệu bug không bị nhiễu.
Mẹo vàng: Định nghĩa trước "ngưỡng kích hoạt chế độ khẩn cấp" (ví dụ: bất kỳ bug nào chặn thanh toán hoặc ảnh hưởng >5% người dùng). Khi khủng hoảng xảy ra, không ai còn tỉnh táo để tranh luận — quy tắc đặt sẵn cứu bạn.
Bài tập thực hành
- Xây thang phân loại của riêng bạn. Viết định nghĩa cụ thể cho 4 bậc Severity (S1–S4) và 4 bậc Priority (P1–P4) áp dụng cho một sản phẩm bạn biết rõ (app đặt đồ ăn, ví điện tử, website bán hàng...). Với mỗi bậc, cho một ví dụ bug thật.
- Chơi trò ma trận. Lấy 6 bug sau và gán cặp Severity/Priority cho từng cái, kèm một câu giải thích: (a) trang chủ tải chậm 8 giây trên 3G; (b) sai chính tả tên công ty ở email hóa đơn; (c) người dùng không đăng nhập được bằng Google trên iOS 17; (d) nút "Chia sẻ" không hoạt động ở một màn hình ít người vào; (e) hệ thống tính sai thuế VAT trên hóa đơn xuất khách; (f) animation loading bị giật nhẹ.
- Thiết kế workflow. Vẽ ra luồng trạng thái bug trong Jira cho team của bạn, bao gồm status "Triage" và "Needs Info". Xác định ai được phép chuyển bug sang trạng thái nào.
- Tạo bug report template. Soạn một mẫu Description gồm Steps to reproduce, Expected, Actual, Environment và mức Severity đề xuất — đủ đơn giản để nhân viên CSKH không rành kỹ thuật cũng điền được.
Tóm tắt
Bug triage là kỹ năng sống còn của PM vì bạn sẽ luôn có nhiều bug hơn khả năng sửa. Trái tim của triage là phân biệt rạch ròi hai khái niệm: Severity đo mức độ hư hại về kỹ thuật (do QA/engineer đánh giá), còn Priority đo tính cấp bách về nghiệp vụ (do PM quyết định dựa trên dữ liệu người dùng và giá trị kinh doanh). Hai chiều này độc lập — một bug S1 vẫn có thể là P3, và một bug S3 vẫn có thể là P1 tùy bối cảnh.
Để triage hiệu quả, hãy: chuẩn hóa bug report, tạo status "Triage" trong workflow, gán Severity trước rồi Priority sau, biến triage thành nghi thức định kỳ với người tham gia cố định, và theo dõi sức khỏe bằng dashboard. Tránh các bẫy phổ biến như dồn mọi thứ vào P1, lẫn lộn hai chiều severity/priority, và để bug "mồ côi". Khi làm tốt, bạn không chỉ sửa bug nhanh hơn mà còn trở thành điểm tựa lý trí giúp cả team ra quyết định đúng giữa lúc áp lực nhất.