MoSCoW: Phân loại yêu cầu khi cháy nguồn lực
Hãy dùng Must, Should, Could, Won't: Deadline thì dí sát, tính năng thì ngập đầu. Làm sao để cắt scope mà không làm khách hàng nổi giận?
Hãy luôn có định nghĩa khi làm PRD.
Khi viết PRD hoặc chốt Scope cho Sprint, hãy gắn nhãn cho từng mục:
M - Must have (Bắt buộc phải có)
Đây là MVP. Không có nó, sản phẩm coi như đồ bỏ đi. Ví dụ App Grab: Tính năng Đặt xe là Must.
S - Should have (Nên có)
Quan trọng, nhưng không chết người. Có thể workaround đi đường vòng được. Ví dụ: Tính năng “Lưu địa chỉ nhà”. Không có thì user nhập tay mỗi lần cũng được, hơi phiền thôi.
C - Could have (Có thì tốt)
Nice-to-have. Làm thì user sướng, không làm cũng chả sao. Ví dụ: Hiệu ứng pháo hoa khi đặt xe thành công.
W - Won’t have (Sẽ không làm... lúc này)
Thống nhất rõ ràng là Cái này để sau. Tránh tình trạng Stakeholder cứ hy vọng rồi thất vọng.
Quy tắc ngón tay cái
Trong một Sprint/Release:
Must: Chiếm tối đa 60% nguồn lực.
Should: 20%.
Could: 20%.
Tại sao? Vì dự án luôn luôn có biến (Bug, Dev ốm, Sai sót). Nếu Must chiếm 100%, chỉ cần 1 biến cố nhỏ là bạn trễ Deadline (Fail). Nếu Must chỉ 60%, khi có biến, bạn sẵn sàng cắt bỏ Should và Could để bảo vệ cái Must và giữ đúng Deadline. Đó gọi là Scope Buffering.
T.D