😎Почему в 2025 MoSCoW всё ещё рулит в продуктовых командах

Итак, понедельник и время прокачивать базу! Сегодня разбираемся с MoSCoW - это один из самых простых и эффективных способов приоритизировать задачи и фичи в продукте. Название, правда, немножко бесит, потому что пока его напишешь надо нажать 4 капслока в одном слове) Что такое и откуда появилось Это аббревиатура из ключевых категорий: Must have - должно быть Should have - следует иметь Could have - можно иметь Won't have - не будет Появился этот метод в конце 1990-х в британской компании Dynamic Systems Development Method (DSDM) как часть гибких методологий. И с тех пор помогает продактам и менеджерам чётко расставлять приоритеты, избегая хаоса и бессмысленных спринтов

Когда применять Когда нужно быстро выделитьфундаментальные функции и выстроить roadmap. Еще пригодится в сложных проектах с множеством требований и ограниченным временем/ресурсами, где тысяча и один заказчик с разнородными требованиями. Ну и для прозрачности между стейкхолдерами - чтобы все понимали, что действительно важно, а что можно отложить. Хорошая штука, чтобы быстро навести порядок в бэклоге и не потратить на это вечность. Но есть нюансы)

Ключевые ошибки ❌Все хотят “Must Have” Когда под «обязательно» спрятано почти всё, результат будет фигня и мы такое не принимаем. Потратим чуток времени и задаем жёсткие критерии что такое Must Have и каждая из категорий, чтобы была понятная всем линейка ❌Игнорирование “Won't Have” В категорию «Won’t Have», кладем все, что сейчас точно нет: из-за технической неготовности, блокеров, отсутствию влияния на метрики. Боремся с расширением объёма без плана (scope creep) ❌Нет регулярного пересмотра приоритетов Итак, мы расставили приоритеты один раз и забыли?Пересматриваем либо после каждого релиза, либо после изменения условий, либо перед квартальными челленджами, чтобы оставаться гибкими, но и не тратить время на то, что уже никому не нужно ❌Нет четких требований Ну, это наша общая боль - обнимемся! Надо не забыть про критерии приёмки (acceptance criteria), а то сами знаем как по-разному можно понять задачу😁 Как начать внедрять MoSCoW 🗳Оцениваем реально ли нам подходит фреймворк и не дублирует ли другие системы приоритизации - а то 10 фреймворков в одном продукте = фигня в бэклоге и ненормализованные спринты 🗳Обучаем команду и стейкхолдеров, тут хватит понятной презы или доски в Miro с описанием подхода, его ценности, что и зачем, чтобы избежать недопониманий с первого дня 🗳Собераем все требования и запросы и делаем большой список всего, что хотят видеть в продукте. Лучше всего создать флоу в Jira, куда вам заказчики могут кидать наполненные по структуре брифы и тз, руками собирать будет больно и долго 🗳Размечаем требования по категориям MoSCoW сначала вместе с командой по категориям, потом выносим на ревью ключевым стейкхолдерам. Непрошенные советы: не приходите приоритезировать к заказчику с пустой таблицей, заполните сначала сами исходя из своего понимания и проставьте как видите внутри команды - экономим время и нервы 🗳Зафиксируем приоритеты в доке или таск-трекере, чтобы все видели расстановку, если что-то актуализируем, оповещаем кому важно. Не забываем про зависимости со смежными командами! 🗳Всегда начинаем работу с Must Have, фокусируясь на минимальной реализуемой ценности. Без чего «почки отвалятся» и продукт не полетит - скорее всего это ваш Must)

Дополняем MoSCoW количественными метриками и решения становятся более обоснованными, учитывая риски и выгоды. А еще это хорошая тема когда проходят совместные воркшопы и надо быстро запилить приоритизацию в доступной и понятной форме.

Короче, MoSCoW - отличный инструмент, если использовать его с умом, он помогает не утонуть в списках задач и сфокусироваться на существенном, а не на шуме, но важно правильно выбрать что реально важно, а что - бантики🙃

Что еще почитать по теме 💬Kaiten: Метод MoSCoW - что это, как применять для приоритизации задач 💬Creately: Understanding the MoSCoW Method: A Comprehensive Breakdown Ciao!💚 И #этобаза