* Bài viết này được dịch từ một phần nhỏ của cuốn PMI-ACP Exam Prep của Mike Griffiths.
Đối với dự án Agile, không có cách nào được coi là tối ưu nhất để sắp xếp độ ưu tiên về yêu cầu dự án. Mỗi dự án phải tự tìm ra cách của riêng mình dựa vào đặc tính dự án để có lợi nhất cho khách hàng và tổ chức. Sau đây là một vài prioritization schemes (cách sắp xếp độ ưu tiên) thường được sử dụng cho dự án Agile.
1. Simple Schemes
Đây là cách đơn giản và thông dụng nhất, các items được đánh ưu tiên “Priority 1”, “Priority 2”, “Priority 3”… hoặc đơn giản hơn là “High”, “Medium” và “Low”. Tuy nhiên cách này có vấn đề vì nhiều khi có quá nhiều items được cho là “High”, khi đó cách này sẽ không còn hiệu quả. Khi có tính năng mới được đề xuất, ít khi người đề xuất chịu để tính năng của mình ở vị trí “Medium” hoặc “Low” vì những items này có nguy cơ không được động tới để nhường chỗ cho các items được đánh dấu là “High”. Trong trường hợp đó, cách này không thể áp dụng hiệu quả.
2. MoSCoW
MoSCoW là viết tắt của “Must have”, “Should have”, “Could have” và “Would like to have, but not this time (hoặc Won’t have).”
- “Must have” – là những yêu cầu hoặc tính năng cơ bản của hệ thống. Nếu không có nó, hệ thống sẽ không chạy được hoặc không có giá trị.
- “Should have” – là các tính năng rất quan trọng, chúng ta nên có chúng để hệ thống hoạt động chính xác; nếu không có nó thì hệ thống sẽ vận hành một cách tốn kém hoặc xử lý rất cồng kềnh.
- “Could have” – là những tính năng có thể tăng thêm các giá trị hữu hình cho hệ thống. Tuy nhiên những tính năng này có thể bị lùi lại do hạn chế về nguồn lực hoặc ngân sách.
- “Won’t have” – là những yêu cầu sẽ được lưu ý đề thực hiện, nhưng không phải lúc này. Hoặc các yêu cầu mang lại ít giá trị
3. Monopoly Money
Monopoly money là tổng số tiền ngân sách của dự án và được yêu cầu phân phối số tiền này cho các tính năng của hệ thống. Cách này giúp ta xác định mức độ ưu tiên của các thành phần hoặc tính năng của hệ thống, nhưng rất khó nếu ta phân chia tiền cho các hoạt động như: hỏi đáp, tạo tài liệu hệ thống vì những công việc này thường được coi là mang lại ít giá trị (giá trị ở đây được hiểu là phần mềm chạy được). Cách này sẽ hiệu quả nếu ta giới hạn để sắp xếp các tính năng trong business (prioritizing business features)
4. 100-point Method
Cách này được phát triển bởi Dean Leffingwell và Don Widrig. Với cách này mỗi người sẽ được cho số điểm là 100 và chia ra cho từng tính năng của hệ thống. Ví dụ, tính năng A sẽ có 30 điểm, tính năng B có 15 điểm, hoặc thậm chí có tính năng được 100 điểm nếu ta coi chỉ có tính năng đó mới được ưu tiên.
5. Dot-Voting or Multi-Voting
Với cách này, mỗi người sẽ được sở hữu một số lượng “chấm” cho trước và người đó sẽ phân phối số “chấm” của mình cho các lựa chọn cần sắp xếp.
Để dễ hiểu hơn ta có thể xem ví dụ sau: Trong phiên workshop OKRs đầu quý của phòng ban, ta có kết quả của một O với 40 KRs mà ta cần sắp xếp độ ưu tiên cho các KRs này. Khi đó mỗi người sẽ được cho 8 “chấm” để phân bổ cho các KRs mà họ cảm thấy quan trọng nhất. Mỗi người chỉ được giới hạn tối đa 8 “chấm”, có thể phân bổ cho 8 KRs với mỗi KRs một chấm, hoặc 4 chấm cho một KRs, 2 chấm cho hai KRs khác. Hoặc bất kỳ cách khác mà người vote cảm thấy hợp lý. Cuối cùng, facilitator sẽ tổng hợp lại và sắp xếp từ trên xuống các KRs có nhiều “chấm” nhất.
Để xác định bao nhiêu “chấm” nên được phân bổ cho mỗi người, ta có thể dựa vào quy tắc: 20 phần trăm tổng số items cần được đánh ưu tiên. Ở ví dụ trên, ta có 40 KRs, do đó, số “chấm được chia cho mỗi người là 40 * 20% = 8.
Hi vọng một vài phương pháp sắp xếp độ ưu tiên ở trên sẽ giúp cho các bạn sử dụng không chỉ cho dự án, mà trong cuộc sống hàng ngày ta cũng cần sắp xếp độ ưu tiên cho các công việc và dự định cá nhân của mình đúng không nào?