🔎 Что такое MoSCoW Методика MoSCoW получила своё название от первых букв категорий приоритетов: M — Must have (обязательно должно быть) Критически важные требования, без которых система не имеет смысла. Без них релиз невозможен. 👉 Пример: система авторизации в интернет-банке. S — Should have (желательно иметь) Важные, но не критичные требования. Их отсутствие не сорвёт релиз, но снизит ценность продукта. 👉 Пример: возможность фильтрации товаров по нескольким параметрам в интернет-магазине. C — Could have (можно было бы иметь) Неплохие улучшения, «приятные плюшки», которые сделают продукт удобнее или красивее, но их легко отложить. 👉 Пример: тёмная тема интерфейса при запуске новой системы. W — Won’t have (this time) (не будет в этот раз) То, что сейчас не реализуется, но может быть запланировано на будущее. Важно явно зафиксировать это, чтобы у стейкхолдеров не было иллюзий. 👉 Пример: интеграция с внешними CRM, которая пока не нужна MVP. 🛠 Как работает MoSCoW Собираются все требования к продукту. Каждое требование распределяется по категориям M, S, C или W. План релиза формируется так: Сначала Must (без них релиз невозможен). Потом Should (то, что желательно, но можно перенести). Затем Could (если останутся ресурсы). Won’t фиксируется в backlog для будущих итераций. ⚡ Преимущества метода Простая и понятная логика даже для нетехнических заказчиков. Помогает сфокусироваться на действительно важных вещах. Отлично работает в Agile-проектах и при создании MVP. ⚠️ Подводные камни Требует дисциплины: заказчики часто пытаются записать всё в «Must». Иногда нужно дополнительное обоснование — «почему это Must, а не Should». Лучше работает для небольших проектов или итераций, а в крупных системах стоит комбинировать с другими методами (например, ранжированием или матрицей Эйзенхауэра). #MoSCoW #Приоритизация #BusinessAnalysis #ProductManagement #УправлениеПроектами #Требования #BA #ProductOwner #Аналитика #Agile #MVP #ПриоритизацияТребований #БизнесАналитика #ГибкаяРазработка #ТЗ