Приоритет задач в разработке продукта

Приоритет задач

Приоритет задач, важная составляющая управления продуктом. Как правильно распределять ресурсы команды? Какие доработки лучше брать в бэклог прежде всего, а о каких на время можно забыть? Читаем, запоминаем, используем.

“Расставляй приоритеты”, – часто слышишь со всех сторон. Еще будучи ребенком, ты понимаешь, что нужно делать выбор и вся ответственность на тебе.

То же и в разработке продукта. Невозможно взять сразу все задачи в работу, ресурсов не хватит. Нужно планировать релиз за релизом, выбирать то, что принесет пользователям и бизнесу профит.

У тебя есть команда и на тебе планирование ее загрузки. Ты отвечаешь за продукт, это твоя ответственность и твои решения, но как их принимать, чтобы на выходе получить то, что надо?

Приоритет задач: логика

Вся логика расстановки приоритетов начинается с целей, далее из этих целей планируются ключевые вехи продукта (роадмэп) , а потом и релизы со своими скоупами задач. Как-то так.

Приоритет задач: логика

Последовательность именно такая. Все начинается с крупных целей, а дальше разматывается до конкретных задач. Логика: шаг за шагом. Релизы обычно проводят раз в две недели, а планирование задач с учетом приоритетов на два релиза, то есть на месяц вперед. История про то: “А давайте напихаем новых задач за неделю до релиза”, – работает, но не очень. Почему?

Фокусировка

Чтобы прийти куда-то, нужно понимать куда. Когда вы понимаете куда, то планируете свои действия, дабы добраться до заветной точки.

Приоритете задач: фокусировка

Делая шаг, вы проверяете направление. А в ту ли сторону я иду? Затем, если сбились с пути, то корректируете курс и продолжаете идти.

Ровно то же самое происходит и в разработке продукта. Вот вы построили роадмэп (план), вот релизы, а в них задачи. Чтобы не сбиваться с намеченного курса вам нужно поднимать голову и смотреть “А туда ли я иду?”. Как эта задача в релизе приближает меня к цели?

Кажется, все просто? Да не очень…

Гибкий мир, гибкие условия

Как вы думаете, почему появились гибкие методологии, всякий agile и прочее? Потому что, все вокруг меняется.

Приоритет задач

Ты вроде бы такой молодец все запланировал, выполнил домашнее задание и летишь на Сапсане прямо к остановке “Успех”. Ага, щаззззз.

В жизни скорее так: ты наметил цели, запланировал релизы, а потом раз и рынок изменился. Не нужны пользователям те фичи, которые ты пилил. Давай перекраивай релизы.

Или раз, новые вводные по целям сверху, идем сюда, а не туда. И снова перекраивай релизы.

Что с этим делать?

Менять приоритет задач, а что еще? У тебя есть роадмэп, крупный план действий на год. Он обновлятся по мере поступления новых вводных. А дальше по плану: релизы и задачи в них.

Приоритет задач: новые вводные

Планируйте на месяц вперед. Если 2-х недельные релизы, то как раз по ним и составляйте план задач.

Смотрите, какие задачи и как помогают привести твой продукт к цели? Точно ли нет ничего получше, что бы внесло больший вклад? Вдруг задача, которую ты не включил в релиз, может принести гораздо больший эффект?

Чтобы такого не произошло, используйте скорринг (оценку) задач.

Скоринг задач

Когда к вам приходит задача, то вы должны посмотреть на нее через призму ваших целей.

Приоритет задач: скорринг

У вас должны быть метрики, по которым вы оцениваете вес задачи. То есть, на сколько она приближает вас к цели.

Пример

Продукт – приложение с фотографиями. Снимаете фото, на него накладываются фильтры, выглядит забавно и классно, для фана в общем.

Одна из ваших целей, это нарастить базу пользователей. Появилась задача “шэринг в соц.сети фото”.

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

Если вам нравится, как в фильме Матрица Нео уклонялся от пуль  и вы хотите знать, когда появятся материалы в блоге, то подписывайтесь на наш telegram канал!

Телеграм канал alexcouncil.com

Или обратная ситуация, есть задача добавить редактирование текстов в комментариях под фото после публикации. Согласитесь, что профита поменьше будет с точки зрения привлечения новых пользователей, если сравнивать с шэрингом?

Приблизительно так это и работает. Вы планируете релизы и наполняете их задачами с учетом более крупных целей.

Нюанс на миллион долларов

Если следовать логике только от целей, то наш продукт рано или поздно может превратиться в одну большую кнопку “Купить”. Ни тебе удобного интерфейса, ни приятного дизайна, ничего кроме конверсий.

Приоритет задач: нюанс

На практике все немного интереснее. Твой приоритет задач должен опираться не только на достижение целевых показателей. Ты ведь продакт, ты про пользовательский опыт и все такое…

Необходимо оставлять место прекрасному, место эволюции, место исправлению багов и аналитике. Только так ваш продукт сможет гармонично развиваться.

Существует 4 типа задач, с которыми вы будете сталкиваться.

Приоритет задач: типы

Все четыре типа должны присутствовать в вашем роадмэпе и релизах, чтобы продукт был сбалансированным.

Функционал – новые возможности для пользователя (шэры, лайки, комменты, возможность отметить друга в посте).

Эволюция – развитие интерфейса, удобства, дизайна (сокращение шагов в воронке, более удобные кнопки, улучшенная навигация, красивые картиночки).

Баги – исправление ошибок, глюков и прочего (не работает что-то в функционале, шрифты уехали, недоступность продукта).

Аналитика – доработки связанные с выгрузкой пользовательских метрик (не только GA и Метрика, настройка кастомных событий, выгрузки из базы данных, интеграция с хранилищами и дашбордами).

Приоритет задач должен учитывать все эти типы, в противном случае будет определенный перекос в продукте.

Распределение весов/ресурсов для каждого типа задач будет сильно зависеть от стадии, на которой находится продукт

ПРиоритет задач: распредление ресурсов в зависимости от стадии развития продукта

Вы можете только запускаться и при этом все ваши силы брошены на функционал. Нужно быстрее выйти на рынок, а про остальное подумаем потом.

Или наоборот, мы уже запустились, функционал укомплектован и самое время почистить все баги и улучшить интерфейс.

Задачи по аналитике также очень важны. В идеале, при планировании запуска продукта, ключевые метрики уже должны быть заложены, а доработки по сбору данных уже распланированы по релизам.

Схема выше, это лишь мое видение распределения ресурсов. Проанализируйте стадию, на которой находится ваш продукт, посмотрите, чем именно его нужно дополнить. Может быть пришло время дотюнить аналитику, чтобы вытаскивать инсайты из данных? Или же багами давно уже пора заняться, а то все на костылях держится?

Итог

Не существует универсальных рецептов, ровно как и универсальных продуктов. Приоритет задач зависит от многих факторов, но в ваших силах управлять им. Берите рекомендации из данного материала в работу и ваше планирование станет более осмысленным, а продукт будет развиваться в правильном направлении.

Алексей А.


Еще почитать:


А вот и “Трансмашхолдинг” подоспел со своим новым поездом “Москва” для метрополитена. Посмотрим, кто быстрее, болид или новый покоритель подземки.



1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (3 оценок, среднее: 5,00 из 5)
Загрузка...

3 комментария

Добавить ваш

  1. Слежу за блогом долгое время, почаще бы писал, а то что то все меньше и меньше

    • Алексей Арефьев

      17.07.2018 at 15:42

      Дмитрий, спасибо за комментарий!

      Пытаюсь как только руки освобождаются. Буду стараться чаще публиковать.

  2. Минус OmniFocus в том, что все мои знакомые, которые используют этот продукт, скатываются к выделению приоритетов через время. Если хотят выделить задачу, ставят ей дедлайн «на сегодня», и она загорается красным. Не все приоритетные задачи выполняются так быстро, как хотелось бы, и со временем список разрастается, а процесс уползает к менеджменту через дедлайны, что противоречит одному из принципов GTD — добавлять в календарь только те встречи и поручения, которые жестко привязаны к конкретным датам.

Добавить комментарий

Введите ваше сообщение и email.

*