Bài viết này sẽ giải thích cho bạn một cách ngắn gọn và thực tế về phương pháp MoSCoW. Hy vọng sau khi đọc, bạn sẽ hiểu được những kiến thức cơ bản của công cụ quản lý dự án hữu hiệu này.
ĐẦU TIÊN, PHƯƠNG PHÁP MOSCOW LÀ GÌ?
Xác định mức độ ưu tiên bao giờ cũng là bài toán khó khi triển khai các ý tưởng hoặc công nghệ mới. Mọi thành viên trong doanh nghiệp luôn muốn tất cả mọi việc phải được thực hiện ngay lập tức, nhưng đó quả là điều phi thực tế và không thể thực hiện được. Tuy nhiên, có một số công cụ có thể giúp bạn biến việc xác định ưu tiên trở nên dễ dàng hơn. Phương pháp MoSCoW là một trong số đó.
Ông Dai Clegg từ công ty phần mềm Oracle - một công ty công nghệ của Mỹ, sở hữu hãng phần mềm và hệ quản trị cơ sở dữ liệu rất phổ biến trên thế giới, đã phát minh ra phương pháp MoSCoW. Phương pháp này phân loại và dán nhãn cho từng yêu cầu, từ đó khiến việc đặt ưu tiên trở nên dễ dàng hơn.
Tuy phương pháp này bắt nguồn từ ngành phát triển phần mềm, nhưng nó vẫn rất phù hợp khi áp dụng cho việc ra mắt thị trường, ra mắt sản phẩm, bắt đầu một công ty mới hoặc cho việc xử lý thay đổi. Với phương pháp MoSCoW, các yêu cầu là tối quan trọng, ảnh hưởng trực tiếp đến kết quả của dự án hoặc sản phẩm.
Phương pháp MoSCoW nhắm vào việc sắp xếp các yêu cầu theo thứ tự ưu tiên. Các yêu cầu quan trọng nhất cần được đáp ứng trước để có xác suất thành công cao hơn.
MoSCoW là một từ viết tắt. Hai chữ O được thêm vào chỉ để làm cho từ 'moscow' dễ đọc hơn, ngoài ra không có ý nghĩa gì cả. M là viết tắt của 'Must haves' - bắt buộc phải có, S viết tắt cho 'Should have' - nên có, C cho 'Could haves’ - có thể có và W cho 'Won’t have’ - sẽ không có hoặc 'Would haves’ - sẽ có.
CÁC NHÓM YÊU CẦU
Tốt nhất bạn nên làm rõ các yêu cầu trước khi bắt đầu sử dụng MoSCoW. Khi xác định các yêu cầu, bạn nên tính đến những điều quan trọng đối với tất cả các bên liên quan. Để mọi người cùng tham gia suy nghĩ và đóng góp ý kiến sẽ giúp đạt được các yêu cầu có chất lượng tốt.
Các yêu cầu này được sắp xếp theo thứ tự ưu tiên để giảm thiểu việc chúng trở nên quá tốn kém hoặc phi thực tế. Mục đích chính của việc đưa ra các yêu cầu là để làm tăng thêm giá trị cho công ty. Và các yêu cầu của dự án được chia thành một trong các nhóm sau:
M - MUST HAVES - BẮT BUỘC PHẢI CÓ
Đây là những yêu cầu tối thiểu và cần xác định trước khi đạt được kết quả cuối cùng. Nếu không đáp ứng được nhóm yêu cầu này, dự án sẽ không thành công và sản phẩm sẽ không thể sử dụng được. Chúng là những điều kiện thiết yếu để tạo ra sản phẩm sử dụng được và không thể thay thế. Các yêu cầu 'Bắt buộc phải có' là cực kỳ quan trọng. MUST cũng được giải thích như là một từ viết tắt cho cụm “Minimum Use-able SubseTs” - có nghĩa là sản phẩm phải sử dụng được ở mức tối thiểu.
Ví dụ: Trong một bài tập cuối kỳ, các sinh viên trường Đại học Bách Khoa Hà Nội được yêu cầu thiết kế một chiếc xe có thể lái được (điều kiện tối thiểu). Không có vấn đề gì nếu chiếc xe chỉ có khung gầm mà không có thân xe. Quan trọng là họ phải tạo ra được các bộ phận, hệ thống truyền lực và động cơ đốt trong. Trong trường hợp này, yêu cầu “Bắt buộc phải có” ở đây chỉ đơn giản là một chiếc xe lái được vào cuối năm học.
S - SHOULD HAVES - NÊN CÓ
Đây là các yêu cầu bổ sung và được mong muốn nhiều nhất. Ưu tiên cho các yêu cầu này khá cao, nhưng không phải là thiết yếu cho sản phẩm khả dụng cuối cùng. Sản phẩm vẫn có thể sử dụng được ngay cả khi những yêu cầu này không được đáp ứng. Tuy nhiên khi được đáp ứng thì chúng sẽ gia tăng giá trị cho sản phẩm. Tùy thuộc vào quỹ thời gian của mình, bạn có thể quay lại với các yêu cầu này sau.
Ví dụ: Vẫn là việc sản xuất chiếc ô tô ở trên, các sinh viên có thể muốn thêm một thanh kéo (thanh sắt được lắp vào đằng sau xe ô tô (để kéo xe móoc, ..)) vào xe (nên có), miễn là chiếc xe của họ vẫn có thể lái được mà không cần thanh kéo, dự án của họ vẫn sẽ thành công. Họ có thể thêm thanh kéo vào ở giai đoạn sau.
C - COULD HAVE - CÓ THỂ CÓ
Những điều kiện này có thể được xem xét nếu còn thời gian. Nếu không cũng không có vấn đề gì và cũng không ảnh hưởng tiêu cực đến kết quả cuối cùng. 'Có thể có' là mức ưu tiên thấp hơn 'nên có'. Lựa chọn này chỉ nên đưa vào khi bạn có vẫn còn dư thời gian làm việc. Chúng còn được gọi là 'nice to have’ - có thì tốt; nó giống mong muốn nhiều hơn là một yêu cầu.
Ví dụ: Các sinh viên muốn lắp đặt một đồng hồ đo tốc độ trong xe. Đây không phải là yêu cầu quan trọng của bài thi, nhưng kết quả sẽ tuyệt vời hơn nếu có thể làm được như vậy.
Chú ý: Nice-to-have nếu được đưa vào liên tục, xuất hiện liên tục ở các phiên bản cải tiến thì trong tương lai gần sẽ trở thành Must-Have. Thí dụ như tính năng đăng nhập máy tính bằng vân tay, nhận diện khuôn mặt... Những tính năng mới này không làm tăng giá thành của máy, hoặc có tăng thì không đáng kể. Mục đích của nhà sản xuất hướng tới giữ chân khách hàng với thương hiệu sản phẩm, hoặc rút ngắn thời gian của người dùng quen với các tính năng mới trong tương lai...
W - WON’T HAVES (OR WOULD HAVES) - SẼ KHÔNG CÓ (HOẶC SẼ CÓ NHƯNG Ở THỜI ĐIỂM THÍCH HỢP TRONG TƯƠNG LAI)
Đây là những mong muốn trong tương lai mà thường khó hoặc sẽ tốn rất nhiều thời gian thực hiện. Nếu đơn giản yêu cầu đó là không khả thi, thì tốt nhất là đừng lãng phí bất cứ nguồn lực nào vào đó. Còn nếu trong trường hợp có thể đạt được nhưng sẽ tốn rất nhiều thời gian (và tiền bạc) thì yêu cầu đó sẽ được dán nhãn là “Would have- sẽ có”. 'Would haves’ thường được nghiên cứu ở giai đoạn sau khi dự án ban đầu đã kết thúc.
Ví dụ: Các sinh viên Đại học Bách Khoa không được yêu cầu phải tạo ra một chiếc xe thực sự lái được trên đường thật. Bài tập chỉ mang tính chất nghiên cứu. Nếu họ muốn xe của mình đi được trên đường thật, nó sẽ cần có thân xe và phải tuân thủ các tiêu chuẩn an toàn. Nó cũng phải được sự chấp thuận của Cơ quan đăng kiểm trong quá trình chế tạo.
DEADLINE
Áp dụng chính xác và tuân thủ Phương pháp MoSCoW sẽ hỗ trợ bạn quản lý dự án một cách rõ ràng hơn. Mọi người tham gia dự án sẽ biết những gì cần phải hoàn thành trước tiên, khi nào nó phải được hoàn thành và tại sao nó lại quan trọng. Bằng cách sắp xếp thứ tự ưu tiên cho các yêu cầu, một dự án sẽ trở nên dễ quản lý hơn và đảm bảo được tiế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. Bằng cách tập trung vào các yêu cầu chính, bạn sẽ hoàn thành dự án với một sản phẩm có thể bán được và đáp ứng các yêu cầu tối thiểu. 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.
Chia sẻ
Bạn nghĩ sao về bài viết này? Bạn áp dụng Phương pháp MoSCoW trong dự án hoặc tổ chức của bạn như thế nào? Bạn có nhận được những lời giải thích rõ ràng và thực tế từ bài viết này không hay là bạn còn muốn bổ sung thêm điều gì nữa? Các yếu tố dẫn đến thành công của bạn khi áp dụng Phương pháp MoSCoW là gì? Hãy chia sẻ cho chúng tôi biết ở dưới phần bình luận nhé!
NGUỒN : THEO SAGA.VN