Метод поможет продактам и тимлидам спастись от хаоса

Решаем общую проблему всех команд — перегруженность задачами при ограниченных ресурсах на примерах:

• Составляем беклог продукта. 

• Планируем спринт.

• Решаем личные задачи.

Сравниваем MoSCoW другими методами, RICE, ICE, Kano и Buy a Feature.

Привет! Наша команда разрабатывает цифровые сервисы застройщиков.

Как и многим командам, нам приходилось справляться с бесчисленным объемом задач, ограничением ресурсов и сроков. Перепробовали различные методы, но именно MoSCoW стал одним из ключевых инструментов. Важно: метод требует осмысленного применения и не лишён «подводных камней».

MoSCoW помогает не просто расставлять приоритеты, но и обосновывать выбор для команды стейкхолдеров и руководителей.

Начнем с азов. Зачем приоритезировать задачи?

Ответ кажется очевидным, но на практике многие сталкиваются с трудностями.

Реальность такова: объём требований и идей всегда превышает доступные время, бюджет и ресурсы команды. Перед нами встаёт выбор: доработать дизайн или начать разработку фичи; повысить стабильность или интегрировать новый сервис; заменить креативы или оптимизировать текущие рекламные кампании. Этот список можно продолжать бесконечно, и у каждого он свой.

Чтобы принимать взвешенные решения, не «выгорать» в потоке задач и уверенно обосновывать свой выбор стейкхолдерам и команде, нужны чёткие методы приоритизации.

Сравним несколько методов, возможно один из них вам подойдет больше: RICE, ICE, Кано, Buy a feature. Поделитесь в комментариях, каким из методов пользуетесь Вы.

Почему RICE, ICE и Кано не подошли для приоритизации бэклога проекта. (это сценарий нашей команды, у вас может быть другое мнение).

RICE: Reach (охват), Impact (влияние), Confidence (уверенность в оценке охвата, влияния и трудозатрат), Effort (трудозатраты). Для применения задачи нуждаются в предварительной оценке. Но как оценить 50 задач, когда ресурс команды ограничен?

R - охват. При запуске новой фичи мы далеко не всегда можем точно спрогнозировать, сколько пользователей ею воспользуются. Но можем построить гипотезу.

I - влияние фичи. Все задачи в бэклоге теоретически влияют на метрики — иначе бы их там не было.

C - уверенность в оценки. Уверенность часто основана на предположениях.

E - трудозатраты. Для оценки десятков задач требуются время аналитиков и разработчиков, которые уже загружены задачами из спринта.

Итог: Процесс оценки отнимал больше времени, чем сама приоритизация.

ICE: по сути, упрощённый RICE без охвата (Reach). Хорошо работает для валидации гипотез, но менее применим для формирования долгосрочного бэклога.

Модель Кано: отличный инструмент для определения «продуктового ядра» и формирования MVP. Мы успешно используем его на ранних стадиях.

Buy a feature: интересный игровой формат для работы с мнением стейкхолдеров. Рекомендую попробовать.

Вот мы и подошли к методу приоритезации MoSCoW

Метод создал Дай Клегг, эксперт по разработке компании Oracle, в 1994 году.  Его цель — помочь своей команде правильно расставлять приоритеты и сосредоточиться на наиболее важных частях проекта. 

Впоследствии MoSCoW стал частью методологии DSDM (Метод разработки динамических систем) и получил широкое применение в Agile-проектах

Подход MoSCoW расшифровывается дословно как Must have (обязательно), Should have (желательно), Could have (возможно) и Won’t have (не сейчас). Это и есть те самые приоритеты.

Разберем на примере создания нового сайта и… аквалангиста? (почему бы нет).

М (обязательно): Критичные требования. Без них цель продукта не будет достигнута. Для сайта: размещение товаров, контактные данные, корзина, эквайринг. Для аквалангиста: баллон с кислородом — без него не выжить.

S (желательно): Важные требования, повышающие шансы на успех. Для сайта: адаптивная верстка под мобильные. Для аквалангиста: аварийный запас воздуха — повышает шанс выжить.

C (возможно): Полезные «улучшайзеры», но без них цель будет достигнута. Для сайта: стильная анимация. Для аквалангиста: подводная камера — можно обойтись без камеры, но классные записи и снимки можно будет сохранить на память.

W (не сейчас): Идеи, которые не влияют на достижение цели. Для сайта: VR-карточки товаров или 3D анимация. Для аквалангиста: ласты с подсветкой — красиво, но ни как не повлияют на удобство.

Надеюсь ассоциации были достаточно понятны. В следующий раз когда вы приступите к новой задаче, сможете представить себя в роли аквалангиста.

Как применять MoSCoW на примере продуктовых задач?

Пример 1: Приоритизация бэклога

У вас стартует новый проект или сезон. Сотни новых идей, запросов от пользователей и стейкхолдеров, бесчисленный список задач.

Что же делать? - спросили бы вы, и начали что-то делать если бы у вас не было под рукой MoSCoW.

1. Для начала с командой, аналитиком или соседом по команде распределите задачи по фреймворку. 

Предположу что получится как то так. В Must пойдет около 80% всех задач.

2. Проведите экспресс-оценку с командой, сколько каждая задача из Must и Should займет времени, поинтов, спринтов, попугаев (смотря чем измеряете).

3. Определите «ёмкость» команды на предстоящий период. Например, квартал = 6 спринтов.

4. Вы понимаете, что спринт, это икс времени. Простой математический прием Х*6 = лимит вашей команды. Около 30% заложите на риски, остаток будет вашими рамками.

5. Приходит осознание, что количество  задач помещенных в Must объективно больше, чем может сделать команда.

6. Начинайте перемещать задачи, оставляя в Must только те, которые влияют на достижение основной цели продукта и бизнес-метрик.

7. Вариант, который у вас получился, покажите заказчику и обоснуйте выбор задач.

8. Конечно заказчик захочет добавить в Must еще “важных” задач, но у вас уже есть рамки и заложены риски. Объясните заказчику, что если он хочет добавить задачу в Must, он должен убрать одну задачу в Should или Could.

9. Используйте этот момент для переговоров: запросите дополнительные ресурсы, упрощение требований или пересмотр сроков.

Признаюсь, итоговый план часто выглядит так — что ж, приходится идти на разумные компромиссы.

Поздравьте себя. У вас получилось обосновать и согласовать приоритеты.

Пример 2: Планируем спринт

Определите свой объем времени и ресурс команды. 

Предположим команда работает по спринтам и за спринт может вырабатывать 200 часов (capacity), из  них 70% это работа над новыми фичами - примерно 140 часов, еще 30%, это  устранение багов, и тестирование.

Открываете бэклог и видите десятки, а то и сотни задач, но какие поставить в новый спринт?

Алгоритм прост и схож с планированием бэклога: 

1. Проведите быструю приоритизацию по MoSCoW. (представив себя аквалангистом). 

2. Оцените трудоёмкость Must-задач. 

3. Осознайте, что в 140 часов физически не вместится всё «самое нужное»..

4. Могли пройти через стадии отрицания, торга и принятия - но не стали. 

5. Возьмите в спринт только то, что действительно является Must — то, что напрямую влияет на достижение бизнес-цели.

Пример 3: Личная эффективность

Всё то же самое! Определите свои цели и доступное время (например, 2 часа вечером). Это ваш «Must»-ресурс. Затем решите, как его потратить с максимальной пользой: на спорт, обучение, семью или отдых.

Заключение

С практикой MoSCoW становится интуитивным инструментом. Вы начнёте видеть, что даже в условиях неопределённости всегда можно выделить критичное (Must), важное (Should) и то, что может подождать (Could/Won't).

Так же MoSCoW не заменим при оценки MVP и старте новых проектов, но в данной статье хотелось рассказать, как метод работает при планирование.

Пишите ваше мнение в комментариях!

Хорошего дня и продуктивной жизни!