Cách đánh độ ưu tiên cho công việc bằng phương pháp MoSCoW

Bài đăng này đã không được cập nhật trong 2 năm

1. Đánh giá độ ưu tiên là gì?

Đánh giá độ ưu tiên là một quy trình nền tảng của Agile. Bởi trong Agile các nhóm phải “Luôn chào đón các thay đổi về yêu cầu, ngay cả khi ở giai đoạn sau này của dự án”. Nhưng điều gì thực sự xảy ra khi một yêu cầu mới được thêm vào dự án khi dự án đã và đang làm việc hết công suất? Nếu khách hàng không đưa ra độ ưu tiên cho các hạng mục công việc, thì nhóm sẽ rơi vào tình huống khó xử. Nhóm sẽ “ép” mình như thế nào cho công việc mới thêm vào? Tiếp tục task công việc cũ hay để đó và làm task mới

Trên thực tế, có thể khách hàng sẽ nói "Tôi muốn có tất cả!". Tuy nhiên chúng ta cần làm việc với khách hàng và đưa ra được task nào cần nhanh chóng triển khai vì mang lại giá trị cao nhất cho khách hàng. Những task đó sẽ được đánh độ ưu tiên là High, những task mang lại ít giá trị hơn hoặc chưa cần thiết sẽ có độ ưu tiên tương ứng là Normal hoặc Low Việc đánh giá độ ưu tiên này là một quá trình liên tục trong suốt dự án, nó quyết định sự thành công của dự án.

2. Tại sao cần đánh độ ưu tiên cho công việc?

Giúp đội dự án nắm rõ sprint goal và focus vào các task công việc chính
Hỗ trợ việc quản lý dự án một cách rõ ràng hơn đảm bảo được tiến độ.
Giúp việc quản lý phạm vi dự án, không để nó quá lớn
Việc phát triển hay hỗ trợ dự án cũng sẽ dễ thực hiện hơn bằng cách bỏ qua những yêu cầu ít quan trọng.
Tập trung vào các yêu cầu chính sẽ giúp sản phẩm đáp ứng các yêu cầu tối thiểu để đưa vào sử dụng. Chính vì thế nên điểm “Bắt buộc phải có” phải là điểm bán hàng độc đáo và mang lại lợi ích cho người mua.
Đánh giá độ ưu tiên giúp công việc của bạn mang lại nhiều giá trị thiết thực

3. Phương pháp đánh giá độ ưu tiên MoSCoW là gì?

Phương pháp MoSCoW được phát triển bởi Dai Clegg của Oracle UK Consulting vào giữa những năm 1990. Đây là một cách tiếp cận hữu ích để phân loại các nhiệm vụ của dự án thành những hạng mục quan trọng và không quan trọng.

“Must have”: Các yêu cầu hoặc tính năng “Must have” là những yêu cầu cơ bản đối với hệ thống; không có chúng, hệ thống sẽ không hoạt động hoặc sẽ không có giá trị. Nói cách khác đây là những yêu cầu quan trọng và cấp bách

“Should have”: Các tính năng “Should have” rất quan trọng - theo định nghĩa, chúng ta nên có chúng để hệ thống hoạt động chính xác. Hay đây là những yêu cầu quan trọng nhưng chưa cấp bách

“Could have”: Các tính năng “Could have” là các bổ sung để tăng thêm giá trị hữu hình. Hay đây là những yêu cầu mà nếu được thực hiện thì cũng tốt

“Won’t have”, hoặc “Would like to have, but not this time”: Các yêu cầu “Won’t have" là các yêu cầu có cũng được không có cũng không sao. Đây là những yêu cầu không quan trọng, không cần thiết ở thời điểm hiện tại

Đây là trang chủ của Google thông qua phân tích MoSCoW.

4. Cách áp dụng phương pháp MoSCoW

Bước 1: Xác định Sprint Goal: phạm vi, mục tiêu, nguồn lực, deadline, của dự án

Bước 2: Liệt kê danh sách công việc

Bước 3: Đánh độ ưu tiên cho các task đó. Chia các task thành 4 nhóm Must, Should, Could, và Would. Hãy cùng thảo luận với cả team và khách hàng của bạn. Mục tiêu là giữa danh sách Must dưới 60% thời gian và nỗ lực của đội. Càng ít hạng mục, cơ hội thành công càng cao.

Hãy cố gắng đạt được sự đồng thuận với tất cả mọi người trong nhóm. Nếu không thể, thì PO là người đưa ra quyết định chính, là người có tiếng nói cuối cùng.

Mẹo: Thay vì bắt đầu tất cả các nhiệm vụ từ loại Must và sau đó giáng cấp một trong số chúng, bạn nên đặt tất cả các nhiệm vụ trong loại Would đầu tiên và sau đó thảo luận xem tại sao mỗi nhiệm vụ xứng đáng được di chuyển lên danh sách trên.

Bước 4: Chia sẻ kết quả tới toàn bộ thành viên của dự án và phân chia các task. Trong suốt quá trình phát triển cần xem xét và đánh giá lại độ ưu tiên các task cũng như nhắc nhở thành vieecn focus và sprint Goal