Khi phát triển sản phẩm, các tài nguyên như thời gian, nhân lực và tài chính luôn có giới hạn. Tôi chưa từng làm việc trong team product nào mà dư dả tài nguyên, thích làm gì cũng được. Vậy nên để phát triển một sản phẩm thành công thì việc quản lý tài nguyên có hạn là vô cùng quan trọng. Có nhiều cách để quản lý tốt tài nguyên nhưng điều cơ bản nhất cần làm là xác định mức độ quan trọng của các yêu cầu (requirement) cần giải quyết.
Có người giỏi việc xác định mức độ quan trọng và có người không, nhưng may mắn là có sẵn nhiều framework giúp xác định mức độ quan trọng mà ai cũng có thể áp dụng. Tôi muốn giới thiệu một trong số đó là MoSCoW, một framework cơ bản và dễ áp dụng.
1. MoSCoW là gì?
MoSCoW là viết tắt cho Must Have, Should Have, Could Have và Won’t Have. Về cơ bản chắc bạn cũng đã có thể bắt đầu hình dung được ý nghĩa của chúng, nhưng để giải thích rõ hơn thì:
- Must Have: Những yêu cầu cấp thiết và quan trọng, nhất định phải thực hiện
- Should Have: Những yêu cầu quan trọng nhưng không cấp thiết bằng Must Have
- Could Have: Những yêu cầu nếu có thì tốt, không có sẽ không gây ảnh hưởng lớn
- Won’t Have: Những yêu cầu không quan trọng, không cần thiết ở giai đoạn hiện tại

2. Ví dụ áp dụng MoSCoW để phân độ quan trọng công việc cần giải quyết
Vấn đề là mặc dù khái niệm thì dễ hiểu, nhưng khi thực sự phân loại thì đôi khi sẽ hơi mập mờ. Nên tôi sẽ giới thiệu một số ví dụ để bạn dễ hình dung hơn.
Must Have:
- Nếu không thực hiện yêu cầu này thì không thể phát hành
- Nếu không thực hiện yêu cầu này thì không cần phải phát hành phiên bản mới
- Yêu cầu này không thể thay thế, nhất định phải có
Ví dụ: Khi phát triển tính năng cho phép người dùng gửi file trong ứng dụng nhắn tin thì bạn nhất định phải tạo ra nút gửi. (Ví dụ hơi kỳ quặc nhưng dễ hiểu).
Should Have:
- Tính năng này mang lại giá trị nhưng sẽ không ảnh hưởng đến phát hành (phiên bản này)
Ví dụ: Hiện tại file gửi qua ứng dụng nhắn tin của bạn hoàn tất gửi đi trong 10 giây, nếu giảm còn 3 giây thì tốt. Cải thiện tốc độ gửi đi xuống còn 3 giây chỉ là một yêu cầu Should Have nếu bạn chỉ mới phát hành tính năng gửi file.
Could Have
- Có thể hiểu những tính năng nice-to-have, có thì hay
Ví dụ: Hiện tại bạn không thể gửi file lớn hơn 1GB, nếu có thể thì cũng tốt nhưng cũng không ảnh hưởng gì nhiều vì nhu cầu gửi file lớn hơn 1GB qua ứng dụng nhắn tin là không lớn.
Won’t Have (ở thời điểm này):
- Lợi ích mang lại ở giai đoạn hiện tại không đáng so với công sức bỏ ra
Ví dụ: Nếu sản phẩm của bạn chỉ mới ra mắt gần đây và bạn phải dành một tháng để phát triển một dashboard nội bộ mà chỉ có ích cho mỗi CEO, vậy thì có cần thiết lắm không nếu bạn có nhiều task khác tạo ra ảnh hưởng nhiều hơn?
Yêu cầu được phân loại Won’t Have ở giai đoạn này có thể sẽ được nâng mức mức độ ưu tiên ở giai đoạn sau nhưng không phải tất cả.
3. Bạn cần chú ý gì khi sử dụng MoSCoW để phân độ quan trọng công việc cần làm
MoSCoW đơn giản dễ dùng, nhưng đây cũng là một vấn đề vì nó chỉ đánh giá mức độ ưu tiên một cách khá là một chiều và không toàn diện. Chẳng hạn thêm dark mode có vẻ như là một việc Could Have vì sản phẩm cũng chỉ hay hơn (nicer) nếu có nó. Tuy nhiên khi xét toàn diện tính chất sản phẩm là một app nhắn tin, dark mode mang lại lợi ích là giúp người dùng đỡ đau mắt và tiết kiệm pin, những lợi ích có thể tăng thời gian sử dụng sản phẩm. Vậy nên nếu mục tiêu ở thời điểm hiện tại của bạn là tăng thời gian sử dụng sản phẩm, bổ sung dark mode có thể là một việc Must Have. Bạn đừng cứng nhắc quá khi đánh giá mức độ quan trọng và có thể linh hoạt ứng dụng các framework để đánh giá mức độ quan trọng khác như RICE Scoring và Kano nếu phù hợp.
Bạn có thể tìm đọc định nghĩa các thuật ngữ xuất hiện trong bài như Agile, Scrum, Sprint, … tại đây.
3 comments