Dưới đây là tổng quan toàn diện về bảy mô hình ưu tiên hoá phát triển sản phẩm được sử dụng rộng rãi, bao gồm nguồn gốc, phạm vi áp dụng, phương pháp từng bước, ví dụ minh hoạ và các lưu ý quan trọng.

Chấm điểm RICE (Phạm vi tiếp cận, Tác động, Độ tin cậy, Nỗ lực)

Nguồn gốc và phạm vi áp dụng

Mô hình RICE do Sean McBride tại Intercom phát triển nhằm đưa tính chặt chẽ dựa trên dữ liệu vào việc ưu tiên hoá tính năng trong quản lý sản phẩm. Mô hình này được dùng rộng rãi tại các đội ngũ SaaS và công nghệ, nơi có thể ước lượng định lượng tác động đến người dùng và mức độ nỗ lực.

Phương pháp

1. Phạm vi tiếp cận: Ước tính số người dùng bị ảnh hưởng trong một khoảng thời gian xác định (ví dụ: “5.000 người dùng/tháng”).
2. Tác động: Đánh giá ảnh hưởng lên một người dùng hoặc chỉ số kinh doanh theo thang điểm (ví dụ: 3 = rất lớn, 1 = trung bình, 0,5 = thấp).
3. Độ tin cậy: Gán tỷ lệ phần trăm thể hiện độ chính xác của ước tính (ví dụ: độ tin cậy 80%).
4. Nỗ lực: Ước lượng số tháng công hoặc điểm câu chuyện cần thiết (ví dụ: 2 tháng làm việc).
5. Tính toán:
   Điểm RICE = Phạm vi tiếp cận × Tác động × Độ tin cậy / Nỗ lực

Ví dụ

Một tính năng ước tính tiếp cận 1.500 người dùng, có Tác động = 2, Độ tin cậy = 50% và Nỗ lực = 2 sẽ cho:
1.500 × 2 × 0,5 / 2 = 750

Lưu ý

• Cần có dữ liệu phân tích đáng tin cậy cho Phạm vi tiếp cận và tiêu chí rõ ràng cho Tác động.
• Độ tin cậy giúp điều chỉnh điểm số khi dữ liệu còn ít.
• Phù hợp nhất với các sáng kiến có thể định lượng và lấy người dùng làm trung tâm.

Ưu tiên hoá MoSCoW

Nguồn gốc và phạm vi áp dụng

Phương pháp MoSCoW được Dai Clegg tại Oracle tạo ra vào năm 1994, là một phần của phương pháp Phát triển Ứng dụng Nhanh (RAD), và sau đó được chuẩn hoá trong Phương pháp Phát triển Hệ thống Động (DSDM). Phương pháp này phổ biến trong Agile, Scrum và các dự án có khung thời gian cố định thuộc lĩnh vực phần mềm và phân tích kinh doanh.

Phương pháp

1. Phải có (M): Các yêu cầu thiết yếu — dự án sẽ thất bại nếu thiếu chúng.
2. Nên có (S): Quan trọng nhưng chưa thiết yếu trong khung thời gian hiện tại.
3. Có thể có (C): Các cải tiến mong muốn nếu thời gian cho phép.
4. Không có (W): Những hạng mục đã thống nhất loại trừ trong bản phát hành này.

Tổ chức các buổi làm việc với bên liên quan để phân loại từng hạng mục backlog vào M/S/C/W.

Ví dụ

Đối với một bản phát hành thương mại điện tử:

• M: Xác thực người dùng, luồng thanh toán
• S: Tính năng danh sách yêu thích
• C: Chia sẻ trên mạng xã hội
• W: Xem trước sản phẩm bằng thực tế tăng cường.

Lưu ý

• Dễ hiểu và dễ truyền đạt.
• Thiếu mức độ chi tiết trong từng nhóm — nhiều hạng mục “Phải có” vẫn cần được sắp xếp thêm.
• Mơ hồ về thời điểm: “Không có ở lần này” so với “không bao giờ”.

Mô hình Kano

Nguồn gốc và phạm vi áp dụng

Tiến sĩ Noriaki Kano giới thiệu Mô hình Kano vào năm 1984 khi nghiên cứu các yếu tố ảnh hưởng đến sự hài lòng của khách hàng tại Đại học Khoa học Tokyo. Mô hình này được dùng rộng rãi trong phát triển sản phẩm và Triển khai Chức năng Chất lượng (QFD) để liên kết tính năng với sự hài lòng của khách hàng.

Phương pháp

1. Nhóm tính năng:
   • Thiết yếu: Những kỳ vọng cơ bản (ví dụ: chức năng đăng nhập).
   • Một chiều (Hiệu năng): Mức hài lòng tăng tuyến tính (ví dụ: tốc độ tải).
   • Yếu tố tạo thích thú (Hấp dẫn): Các tính năng bất ngờ tạo ra sự thích thú vượt trội (ví dụ: mẹo được cá nhân hoá).
   • Trung lập: Các tính năng không ảnh hưởng đến sự hài lòng.
   • Ngược chiều: Các tính năng mà một số người dùng không thích.
2. Khảo sát khách hàng: Với mỗi tính năng, hỏi người dùng cảm nhận thế nào khi tính năng có mặt và khi vắng mặt.
3. Phân tích: Ánh xạ câu trả lời vào các nhóm, rồi ưu tiên Thiết yếu trước, Hiệu năng tiếp theo và sau đó là Yếu tố tạo thích thú.

Ví dụ

Chỉ báo pin của ứng dụng di động:

• Ban đầu là yếu tố tạo thích thú nếu thời lượng pin trên 12 giờ (ở các điện thoại thông minh đời đầu), rồi dần trở thành tính năng thiết yếu khi tiêu chuẩn của đối thủ tăng lên.

Lưu ý

• Các thuộc tính thay đổi theo thời gian khi kỳ vọng ngày càng cao.
• Cần nghiên cứu người dùng và thiết kế khảo sát cẩn thận.
• Cân bằng đầu tư giữa các nhu cầu nền tảng và đổi mới.

Chấm điểm theo chủ đề

Nguồn gốc và phạm vi áp dụng

Chấm điểm theo chủ đề gom các epic hoặc tính năng liên quan thành những chủ đề chiến lược, rồi đánh giá từng chủ đề theo các tiêu chí xác định trước. Dù không gắn với một tác giả duy nhất, phương pháp này phổ biến trong các nỗ lực lập lộ trình quy mô lớn, nơi việc nhóm lại giúp đơn giản hoá độ phức tạp.

Phương pháp

1. Xác định chủ đề: Nhóm các hạng mục backlog thành những chủ đề mạch lạc (ví dụ: “Onboarding”, “Kiếm tiền”).
2. Chọn tiêu chí: Chọn các yếu tố chấm điểm (ví dụ: tác động kinh doanh, giá trị người dùng, nỗ lực).
3. Gán trọng số: Quyết định trọng số cho từng tiêu chí (ví dụ: tác động = 40%, nỗ lực = 20%).
4. Chấm điểm chủ đề: Đánh giá từng chủ đề theo từng tiêu chí (ví dụ: thang điểm 1–5).
5. Tính điểm tổng hợp: Nhân điểm với trọng số và cộng lại để xếp hạng các chủ đề.

Ví dụ

Chủ đề “Kiếm tiền” được chấm điểm:

• Tác động kinh doanh = 5, Giá trị người dùng = 4, Nỗ lực = 3 → tổng điểm có trọng số quyết định mức độ ưu tiên.

Lưu ý

• Mang lại sự đồng thuận chiến lược ở cấp độ cao.
• Có thể che khuất sự khác biệt giữa các tác vụ riêng lẻ trong cùng chủ đề.
• Phù hợp nhất để liên kết lộ trình với mục tiêu kinh doanh.

Ma trận quyết định chấm điểm có trọng số

Nguồn gốc và phạm vi áp dụng

Bắt nguồn từ lý thuyết Ra quyết định đa tiêu chí (MCDM) và được Stanley Zionts phổ biến vào năm 1979, ma trận này là nền tảng của phân tích quyết định có cấu trúc, dùng trong quản lý sản phẩm và dự án.

Phương pháp

1. Liệt kê các phương án: Mỗi hàng đại diện cho một tính năng hoặc dự án.
2. Xác định tiêu chí: Mỗi cột là một yếu tố (ví dụ: tiềm năng doanh thu, rủi ro, chi phí).
3. Gán trọng số: Phản ánh tầm quan trọng của từng tiêu chí (tổng = 100%).
4. Chấm điểm phương án: Đánh giá từng phương án theo từng tiêu chí (ví dụ: 1–10).
5. Tính điểm có trọng số: Nhân điểm với trọng số, rồi cộng trên các tiêu chí.
6. Xếp hạng: Tổng điểm cao hơn thể hiện mức độ ưu tiên cao hơn.

Ví dụ

So sánh ba ý tưởng tính năng theo các tiêu chí (doanh thu, tăng trưởng người dùng, nỗ lực phát triển) sẽ cho thứ hạng rõ ràng theo tổng điểm có trọng số.

Lưu ý

• Minh bạch và có thể tuỳ chỉnh.
• Có thể trở nên phức tạp khi có nhiều tiêu chí.
• Dễ chịu ảnh hưởng bởi thiên kiến khi gán trọng số.

Mô hình Giá trị so với Nỗ lực

Nguồn gốc và phạm vi áp dụng

Một phép ước lượng 2×2 đơn giản được dùng rộng rãi trong quản lý sản phẩm để trực quan hoá ROI bằng cách so sánh lợi ích (giá trị) với nhu cầu nguồn lực (nỗ lực).

Phương pháp

1. Liệt kê tính năng: Tổng hợp các hạng mục backlog.
2. Ước tính giá trị: Đánh giá ROI tiềm năng hoặc tác động đến người dùng (ví dụ: 1–5).
3. Ước tính nỗ lực: Đánh giá nguồn lực/thời gian cần thiết (ví dụ: 1–5).
4. Đặt lên ma trận:
   • Thắng nhanh: Giá trị cao, nỗ lực thấp
   • Dự án lớn: Giá trị cao, nỗ lực cao
   • Việc bổ sung: Giá trị thấp, nỗ lực thấp
   • Hố đen thời gian: Giá trị thấp, nỗ lực cao.

Ví dụ

Các bản sửa lỗi thường thuộc nhóm Thắng nhanh; việc đại tu nền tảng lớn có thể là Dự án lớn.

Lưu ý

• Trực quan nhanh và dễ hiểu.
• Đơn giản hoá quá mức độ phức tạp và có thể khuyến khích chấm điểm theo cảm tính.
• Nên kết hợp với thảo luận và xác thực bằng dữ liệu.

Phương pháp lập bản đồ câu chuyện

Nguồn gốc và phạm vi áp dụng

Jeff Patton giới thiệu phương pháp lập bản đồ câu chuyện người dùng vào khoảng năm 2005 để khắc phục hạn chế của backlog tuyến tính và duy trì trọng tâm lấy người dùng làm trung tâm trong các đội Agile. Phương pháp này được dùng trong Agile và Lean để cấu trúc backlog.

Phương pháp

1. Xác định trục chính: Xác định các bước hành trình cấp cao của người dùng theo chiều ngang (ví dụ: “Duyệt”, “Chọn”, “Thanh toán”).
2. Chia thành câu chuyện: Dưới mỗi bước, liệt kê các câu chuyện người dùng chi tiết theo chiều dọc, được sắp xếp theo mức độ ưu tiên.
3. Xác định khung xương tối thiểu: Hàng trên cùng gồm các câu chuyện bắt buộc tạo thành một MVP.
4. Tinh chỉnh và chia nhỏ: Thêm các hàng bên dưới cho chức năng bổ sung.
5. Cộng tác: Làm việc với các bên liên quan để xác thực luồng và mức độ ưu tiên.

Ví dụ

Bản đồ thương mại điện tử có thể bắt đầu bằng “Tìm kiếm”, “Thêm vào giỏ”, “Thanh toán”, với mỗi bước được chia thành các câu chuyện riêng như “Lọc kết quả” hoặc “Áp dụng mã giảm giá”.

Lưu ý

• Tăng cường sự hiểu biết chung và làm rõ các phụ thuộc.
• Trực quan và có tính cộng tác — cần thời gian làm việc nhóm.
• Không phù hợp với việc lập kế hoạch kỹ thuật quá chi tiết.

---

Mỗi mô hình có điểm mạnh riêng và phù hợp với các bối cảnh khác nhau — chấm điểm dựa trên dữ liệu cho tính chặt chẽ định lượng, phương pháp phân loại để đồng thuận với bên liên quan, hoặc kỹ thuật lập bản đồ để trực quan hoá lấy người dùng làm trung tâm. Việc chọn và điều chỉnh mô hình phù hợp phụ thuộc vào mức độ trưởng thành về dữ liệu của đội ngũ, độ phức tạp dự án và nhu cầu của các bên liên quan.