Để một dự án thành công như kỳ vọng thì cả yêu cầu nghiệp vụ và các mục tiêu chính của dự án cần được sắp xếp độ ưu tiên một cách hợp lý. MoSCoW là một kỹ thuật sắp xếp độ ưu tiên hiệu quả và đã được áp dụng trong các dự án lớn trên toàn cầu.

1) Sự quan trọng của Ưu tiên

Một yêu tố quan trọng cho sự thành công của bất kỳ dự án nào là đảm bảo các yêu cầu đã được đánh độ ưu tiên. Trong nhiều trường hợp công việc này không được xem nặng và hoàn thành dẫn đến dự án thất bại. Nhiều khi đó là lỗi của khách hàng, người muốn toàn bộ hệ thống phải được chuyển giao ở cuối dự án. Nhiều khi đó là lỗi của người quản lý dự án, chuyên viên phân tích nghiệp vụ, bởi vì họ không thảo luận rõ ràng độ ưu tiên với khách hàng.

Sắp xếp độ ưu tiên không phải là một tiến trình dễ dàng. Nhiều người đã dùng cách đanh số 1, 2, 3 truyền thống cho độ ưu tiên của công việc. Những rắc rối của hệ thống số là nó xuất hiện một cách hợp lý để cung cấp các tính năng theo độ ưu tiên 1, 2, 3,… Tuy nhiên ai sẽ là người muốn độ ưu tiên ở vị trí thứ 2 hoặc thứ 3? Và kết quả hiển nhiên là gần như tất cả yêu cầu được sắp xếp độ ưu tiên số 1. Một sự nỗ lực sắp xếp độ ưu tiên trở nên vô ích.

Nguy hiểm với việc sử dụng hệ thống số là những tính năng không được phát triển trong khung thời gian của dự án thì thường bị loại ra khoải danh sách và cuối cùng là biến mất. Điều này khiến các nhà thiết kế và phát triển hệ thống không nhận thức những nhu cầu trong tương lai, do đó họ không thể chọn một giải pháp thiết kế có thể dễ dàng mở rộng trong tương lai.

Bạn thấy đó sự ưu tiên hiệu quả là rất quan trọng để đảm bảo thành công cho dự án nhưng làm sao để bạn có thể hoàn thành công việc này với cách đánh ưu tiên với hệ thống số đã lỗi thời?

2) Giới thiệu kỹ thuật MoSCoW

Kỹ thuật sắp xếp độ ưu tiên MoSCoW được phát minh bởi Dai Clegg của Oracle. Nhưng sau đó đã được tặng cho tổ chức Dynamic System Development Method (DSDM). MoSCoW đã được thiết kế để sử dụng trong khung thời gian (Time-boxing) và các yêu cầu. Nhưng trên website của DSDM ghi rõ rằng “can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests”.

• M – Must have: Cần phải có điều này
• S – Should have : Nên có điều này nếu có thể
• C – Could have: Có thể có điều này nếu nó không ảnh hưởng đến những thứ còn lại
• W – Won’t have: Sẽ không có điều này ở thời điểm hiện tại nhưng đó có thể là một yêu cầu trong tương lai

a) Must have:

Hạng mục phải thực hiện là những hạng mục cần làm phải có trong thoả thuận với khách hàng để đánh giá là hoàn thành công việc. Nếu bạn hỏi “Điều gì xẩy ra nếu hạng mục biến mất?”, và câu trả lời “Chúng ta không làm hoàn thành tất cả”. Vậy là bạn đã tìm được một hạng mục “Must”. Nhưng nếu có nhiều cách khác để vẫn tiến hành hạng mục, chẳng hạng như: làm một số bước tự chế, hoặc một cái gì đó có thể thêm vào sau,… thì bạn tìm thấy hạng mục “Should have” hoặc “Could have”.

DSDM Handbook có đưa ra một số điều kiện để xác định hạng mục “Must have” trong bối cảnh phát triển phần mềm như:

• Không thể chuyển giao trong khung thời gian mục tiêu nếu không bao gồm hạng mục này
• Sẽ không có xác định được cột mốc chuyển giao nếu trong khung thời gian mục tiêu không bao hạng mục này, giải pháp cũng không được triển khai
• Không hợp pháp nếu không có hạng mục này
• Không oan toàn nếu không có hạng mục này

b) Should have:

“Should have” sẽ khác nhiều với “Must have”. Đó là những hạng mục không bắt buộc để di chuyển về phía trước, nhưng nếu vắng mặt hạng mục này trong gói chuyển giao tổng thể thì có thể gây ra khó chịu cao hơn “Could have”.

DSDM Handbook có đưa ra một số điều kiện để xác định hạng mục “Should have”:

• Quang trọng nhưng không gấp
• Có thể khó chịu nếu loại bỏ hạng mục này nhưng giải pháp vẫn còn khả thi
• Có thể cần vài kiểu làm việc xung quanh ví dụ như: quản lý kết quả kỳ vọng, không có hiệu quả, một giải pháp đã tồn tại, thủ tục giấy tờ,…

c) Could have:

“Could have” là danh mục các hạng mục ao ước có, nó có tác động ảnh hưởng nhỏ hơn với những hạng mục “Should have”. Khác biệt hạng mục “Should have” có thể gây ảnh hưởng đến nhiều người dùng nếu không có chúng hoặc có thể gây gánh nặng lớn hơn đối một nhóm người dùng quan trọng nếu không có chúng. Một hạng mục “Could have” có thể gây ảnh hưởng đến một nhóm người dùng nhỏ nếu không có chúng.

DSDM Handbook có đưa ra một số điều kiện để xác định hạng mục “Could have”như:

• Muốn hoặc kỳ vọng có nhưng không quan trọng
• Ít gây ảnh hưởng nếu không có chúng nếu so sách với một hạng mục “Should have”

d) Won’t have

“Won’t have” là hạng mục mà đã được xác định mong muốn có hoặc có giá trị nhưng đã phân định không nằm trong phạm vi của một đợt phát hành hiện tại, giai đoạn bàn giao sản phẩm, không phù hợp với ngân sách đã duyệt. Chúng không hợp lệ, chúng không bao gồm ở thời điểm hiện tại.

3) Các bước áp dụng kỹ thuật MoSCoW để đánh độ ưu tiên

• Bước 1: Làm việc với tất cả các đối tượng tham gia để xem xét và tinh chỉnh lại mục đích của đánh độ ưu tiên. Chúng bao gồm các yêu tố như: Danh sách các hạng mục cần đánh độ ưu tiên, điều kiện đánh độ ưu tiên, làm thế nào để đưa ra quyết định gán độ ưu tiên cho từng hạng mục.

• Bước 2: Xác định quy trình leo thang cần áp dụng nếu tất cả các đối tượng tham dự phiên đánh độ ưu tiên không tìm được sự đồng thuận thích hợp. Điều này bao gồm quá trình xử lý xung đột như: bỏ phiếu, nhà tài trợ đưa ra quyết định, hoặc bất kể cơ chế nào mà các đối tượng liên quan và đội dự án có thể đồng ý với nhau. Xác định quy trình leo thang trước thời hạn có thể tránh được quá trình đanh ưu tiên rơi vào ngõ cụt hoặc mắc kẹt trên vấn đề có xung đột liên quan đến lợi ích của hạng mục có độ ưu tiên.

• Bước 3: Xác định bối cảnh ưu tiên cần sử dụng. Bạn đang ưu tiên cho một hoặc nhiều đợt phát hành? Một nỗ lực phát triển quan trọng nhất? Cho những giá trị kinh doanh cao nhất? Để hiệu quả nhất? Đã có khung thời gian của dự án để xem xét trong qua trình ưu tiên chưa? Tất cả thông tin này cần tài liệu hoá và lưu lại chung với các hạng mục cần ưu tiên. Trong tương lại, thông tin này sẽ giúp những đối tượng liên quan khác hiểu được tại sao có độ ưu tiên được đánh như vây.

• Bước 4: Thu thập tất cả các hạng mục cần đánh độ ưu tiên, như liên quan đến tài liệu nghiệp vụ, hạng mục còn tồn đọng (Product Backlog) và tổ chức chúng nếu thấy cần thiết.

• Bước 5: Xác định nơi lưu trữ quyết định ưu tiên và làm sao để lưu trữ. Bạn có thể dụng ký hiệu kế bên hạng mục còn tồn đọng, hoặc dùng chữ cái để đánh dấu, hoặc dụng màu sắc để đanh dấu,..

• Bước 6: Bắt đầu quá trình ưu tiên, tất cả các đối tượng tham dự sẽ đi duyệt cùng nhau từng hạng mục và đánh độ ưu tiên cho chúng. Mặc định tất cả các hạng mục được đánh “Won’t have”, các đối tượng tham dự cần phải biện minh lý do tại sao hạng mục được gán độ ưu tiên cao hơn.

• Bước 7: Nếu bạn gặp thách thức là tất cả các hạng mục đều đánh độ ưu tiên “Must have”, bạn cần dựa trên điều kiện đanh giá độ ưu tiên (bước 1) và hỏi người tham dự lý do tại sao hạng mục này được đánh ở mức độ ưu tiên này?

• Bước 8: Ghi lại các hạng mục đã đánh ưu tiên như đã đề cập ở bước 5.

• Bước 9: Sau khi tất cả các hạng mục đã được đánh độ ưu tiên. Duyệt lại tất cả các hạng mục để đảm bảo không còn hạng mục nào bị bỏ sót.

• Bước 10: Nếu bạn phát hiện sự phụ thuộc giữa các hạng mục đã được ưu tiên. Bạn cần tìm kiếm nơi hạng mục phụ thuộc có độ ưu tiên cao hơn hạng mục nó phụ thuộc vào không? Nếu tìm thấy thì bạn cần đánh độ ưu tiên thấp cho hạng mục phụ thuộc hoặc những hạng mục có phụ thuộc vào nhau cần đánh độ ưu tiên bằng nhau.

• Bước 11: Tiếp tục đánh giá lại bản đánh ưu tiên cho tình huống có thay đổi như có hạng mục mới thêm vào, những thay đổi trong quá trình thực thi dự án (chẳng hạng như: thay đổi liên quan đến ngân sách, phạm vi dự án, hoặc thời gian bàn giao, và giải pháp triển khai có sự thay đổi). Tất cả các yếu tố thay đổi này cần xem xét nghiêm túc để thay đổi độ ưu tiên sao cho hợp lý.

Kỹ thuật sắp xếp độ ưu tiên là một kỹ thuật tốt nhất khi có hơn 50 hạng mục cần đánh độ ưu tiên. Việc chọn được được thứ tự ưu tiên hợp lý không phải là dễ dàng. Bất kỳ sự chọn lự cần xem xét tính cân bằng liên quan đến giá trị, thời gian, nguồi lực, phạm vi và cả những rủi ro trong dự án.

Kỹ thuật này có thể áp dụng hiệu quả cho chuyên viên phân tích nghiệp vụ, quản lý dự án, Product Owner, quản lý công việc tồn đọng trong dự án Agile.

<< Xem thêm ở website của APEX Global

Chúc các bạn Business Analyst áp dụng kỹ thuật hiệu quả và nâng cao được hiệu suất công việc.

Thân ái,

Nguyễn Đức Giang