MoSCoW Prioritization

Bốn chữ M-S-C-W lấy từ Must have, Should have, Could have, Won't have this time. Phương pháp này ra đời trong DSDM, và điểm mạnh của nó là ai cũng hiểu ngay sau 30 giây — kể cả một trưởng phòng kế toán chưa từng nghe tới Agile. Điểm yếu cũng nằm luôn ở đó: dễ hiểu quá nên người ta dùng ẩu.

MoSCoW chia yêu cầu thành bốn mức cam kết, trong đó chỉ Must là "không có thì bản release này vô nghĩa", còn ba mức kia là chỗ để thương lượng khi hết thời gian.

Bốn nhóm nghĩa là gì

• Must have — thiếu là không release được. Đây là mức "không có thì sản phẩm vô dụng, hoặc vi phạm pháp luật, hoặc không an toàn", chứ chưa dừng ở mức "quan trọng". Phép thử: ngày mai go-live mà thiếu cái này, bạn có dám bấm nút không.
• Should have — đau nếu thiếu, nhưng có cách sống tạm. Thường có workaround thủ công.
• Could have — có thì tốt, tác động nhỏ nếu bỏ. Đây là vùng đệm để bạn cắt khi tiến độ trượt.
• Won't have this time — đã bàn, đã quyết định không làm trong lần này. Chữ "this time" cực kỳ quan trọng và hay bị bỏ mất: nó không có nghĩa là từ chối vĩnh viễn, nó có nghĩa là tạm gác, và điều đó giúp khách dễ đồng ý hơn nhiều.

Bệnh kinh điển: khách gắn Must cho tất cả

Cứ đưa danh sách 80 yêu cầu ra rồi hỏi "cái nào Must", bạn sẽ nhận về 76 cái Must. Chuyện này xảy ra ở mọi dự án, mọi ngành, và nó hoàn toàn hợp lý từ phía khách: gắn Must không tốn gì của họ, còn gắn Could thì rủi ro cái đó không bao giờ được làm.

Cách chữa: gắn ưu tiên vào ngân sách công sức, đừng gắn vào cảm xúc. DSDM khuyến nghị Must chiếm tối đa khoảng 60% tổng effort của giai đoạn. Phần còn lại chia cho Should và Could, và chính phần đó là biên an toàn khi ước lượng sai.

Vận hành trong phòng họp thì thế này:

1. Team ước lượng thô toàn bộ danh sách trước, ra tổng số ngày công.
2. Công bố hạn mức: "Sprint này chúng ta có 60 ngày công. Must được phép chiếm tối đa 36."
3. Khách gắn Must thoải mái. Khi tổng vượt 36, bạn không cãi — bạn hỏi: "Để đưa cái này vào Must, anh chị muốn đẩy cái nào ra khỏi Must?"

Câu hỏi đó đổi hoàn toàn cuộc chơi. Nó không bắt khách hạ ưu tiên, nó bắt khách đánh đổi, và đánh đổi thì họ làm được. Vài lần như vậy danh sách Must tự co lại.

Mẹo phụ: bắt mỗi Must viết kèm một câu "hậu quả nếu thiếu". Viết được "khách không thanh toán được, mất doanh thu trực tiếp" thì đúng là Must. Chỉ viết được "sẽ bất tiện cho nhân viên" thì tự nó rớt xuống Should.

Ví dụ thực tế

Vòng ưu tiên đầu tiên kết thúc với 47 trên 54 yêu cầu mang nhãn Must, và người gắn phần lớn số đó là chủ phòng khám — cũng là người trả tiền. Sản phẩm: app đặt lịch khám cho một phòng khám tư 7 chi nhánh, bản đầu hạn 10 tuần, team 4 dev.

Sau khi ước lượng và áp trần 60%, kết quả cuối:

Cái bị đẩy ra gây tranh cãi nhất là thanh toán online. Lý lẽ để đẩy: phòng khám đang thu tiền tại quầy, tỷ lệ khách bùng lịch khoảng 18%, mà thanh toán online chỉ giải quyết được một phần chuyện đó, trong khi tích hợp cổng thanh toán ngốn 3 tuần trên tổng 10. Đổi lại, nhắc lịch qua ZNS trước 24 giờ được đưa lên Must — rẻ hơn nhiều và đánh trúng cùng vấn đề. Thanh toán online quay lại backlog ở đợt sau, lúc đã có dữ liệu đặt lịch thật để thiết kế cho đúng.

Lỗi hay gặp

• Bỏ chữ "this time" khỏi Won't, biến nó thành lời từ chối. Khách nghe "không làm" sẽ chống, nghe "chưa làm đợt này" thì hợp tác.
• Gắn ưu tiên khi chưa có ước lượng. Không có effort thì mọi thứ đều Must, vì không ai thấy cái giá.
• Người gắn ưu tiên không phải người chịu trách nhiệm ngân sách. Ưu tiên phải do một người quyết, thường là Product Owner hoặc chủ đầu tư.
• Gắn xong rồi treo đó cả quý. Danh sách phải soát lại mỗi lần phạm vi hoặc thời hạn đổi.

Câu hay bị hỏi phỏng vấn

"Nếu khách khăng khăng tất cả đều Must thì bạn làm gì?" — Đừng trả lời "em sẽ giải thích cho khách hiểu". Hãy nói bạn sẽ đưa ước lượng lên bàn, áp trần effort cho nhóm Must, rồi yêu cầu khách chọn cái ra thay vì chọn cái vào. Người phỏng vấn tìm đúng câu đó.