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

  1. Ư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.
  2. 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ô?
  3. 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)?
  4. 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).