06TÌNH HUỐNG · Vận hành
Quá nhiều việc, không biết ưu tiên gì
Dấu hiệu bạn đang ở đây: backlog dài dằng dặc; mọi thứ đều "gấp"; sales đòi tính năng A, sếp đòi B, dev muốn trả nợ kỹ thuật; bạn chọn theo ai to tiếng nhất.
Câu hỏi cần tự hỏi
- Ưu tiên để đạt outcome nào? Không có outcome chung thì mọi framework chấm điểm chỉ là cãi nhau có cấu trúc.
- Các hạng mục có cùng đơn vị so sánh chưa — đã ước lượng impact và effort chưa, dù thô?
- Cái đang được đòi hỏi là must-have hay nice-to-have dưới góc nhìn khách hàng (không phải góc nhìn người đòi)?
- Có hạng mục nào rủi ro cao chưa kiểm chứng đang được xếp như thể chắc chắn thành công không?
Hướng đi
- Nhiều hạng mục, cần xếp hạng khách quan: dùng RICE - ICE - MoSCoW. RICE khi có dữ liệu (reach, impact); ICE khi cần nhanh; MoSCoW khi chốt scope một bản release với stakeholder.
- Phân loại theo cảm nhận khách hàng: Kano Model — cái gì là bắt buộc (thiếu là chê), cái gì tăng tuyến tính, cái gì gây "wow". Đầu tư đủ must-be trước, chọn 1–2 attractive để khác biệt.
- Ưu tiên trong backlog hàng ngày: giữ backlog đạt chuẩn DEEP — chi tiết dần theo độ ưu tiên, có ước lượng, tiến hóa, đã xếp hạng → Product Backlog & User Story.
- Ưu tiên giả định cần test (chưa phải tính năng): ma trận Quan trọng × Chưa có bằng chứng trong Kiểm chứng giả định.
- Điểm số là đầu vào cho phán đoán, không phải phán quyết — sai lệch một chút không quan trọng bằng việc buộc mọi người nói rõ vì sao họ tin impact cao.
- Nói "không" với stakeholder: đừng cãi bằng ý kiến, cho họ xem chi phí cơ hội — "làm cái này thì cái kia lùi; anh/chị chọn giúp em" → Stakeholder khó.
Công cụ
RICE - ICE - MoSCoW · Kano Model · Product Backlog & User Story · Opportunity Solution Tree · Kiểm chứng giả định
Bẫy thường gặp
- Chấm điểm RICE bằng số bịa để hợp lý hóa quyết định đã chọn sẵn.
- Ưu tiên theo người yêu cầu thay vì theo giá trị — "sếp bảo" không phải là một framework.
- Bỏ quên chi phí bảo trì và nợ kỹ thuật — mỗi tính năng ship là một cam kết vĩnh viễn.
- "Càng nhiều tính năng càng tốt" — Kano chỉ ra một số tính năng làm sản phẩm tệ đi (reverse quality).
Nguồn: Module 7 (RICE/ICE, Kano, MoSCoW), Module 10 (DEEP backlog). Đọc sâu: Lean Product Playbook (Olsen).