Приоритизация

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

И речь пойдет конечно-же про приоритезацию задач и организацию бэклога.

Вот вы запустили какой-то проект: ответили на все вопросы из прошлых постов, потихоньку льется трафик, чето кто-то там регается и т.д. Но что делать дальше?

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

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

И вот тут, как говорится, собачка то и порылась.

К оформлению бэклога и приоритизации фич есть целая куча подходов. Фреймворков, если угодно. Вот некоторые из них в столбик:

→ Метод приоритизации PIE. Прямо сейчас я им пользуюсь в Структуре и не могу сказать что жалею. В двух словах суть в том, чтобы каждой фиче присваивать три параметра: Потенциал, Важность, Простота реализации. А потом считать их сумму и на основе этих цифр брать фичи в работу. Не могу сказать что прям вся работа над структурой строится именно так, но жить помогает, рекомендую. В комментарии приложу скрин своего бэклога прямо сейчас.

→ User Story Mapping. Отличный фреймворк, которым я пользуюсь постоянно, но в голове. Очень редко что-либо рисую, потому что часто хватает воображения. Вкратце суть в том, что вы не рассматриваете фичи отдельно, а всегда живете в цельном мире, где пользователь не касается продукта по кусочкам, а проходит путь целиком. Я часто если беру отприоритизированную фичу из бэклога с итоговым PIE, я все равно в голове прогоняю через юзер стори. Подробнее можно почитать у Тиграна на канале.

→ MoSCoW (Москва ни при чем). Прикольная тоже модель, но как по мне, не учитывает размер фичи. Зато визуально можно поиграться и подвигать стикеры. Хотя для двиганья стикеров еще куча других фреймворков подходят. Кароче если вкратце, то суть в отделении критических фичей от некритических. Человек не может без дыхания — это критическая фича. Но иногда может ходить без одежды, это не берем в первый приоритет. Подход хорошо помог бы продуктам, которые слишком много времени тратят, скажем, на дизайн авторизации, но мало времени уделяют core функционалу. Подробнее опять у Тиграна.

→ Модель Кано. Ценность\усилия, RICE. Вот вам еще ключевых слов на эту тему, если хочется упороться и узнать как можно больше по этой теме. Я эти подходы не использовал, поэтому и комментировать не буду.

Важно понимать, что ни один из подходов не является идеальным и лучше бы использовать 2-3 как это делаю я. Ведь умение взглянуть под разными углами на происходящее — это важнейший навык вообще по жизни.

Пишите как вы работаете с бэклогом у себя и понравился ли пост 👇