Приоритизация
Я много раз писал про первые шаги при запуске продуктов или про работу над первым трафиком, или про генерацию идей (раз, два), а теперь хочу поговорить про вторые шаги при работе с чем угодно.
И речь пойдет конечно-же про приоритезацию задач и организацию бэклога.
Вот вы запустили какой-то проект: ответили на все вопросы из прошлых постов, потихоньку льется трафик, чето кто-то там регается и т.д. Но что делать дальше?
Ну, во-первых, завести бэклог, если вы не сделали этого раньше. Туда будем класть все подряд что в голову приходит. От самого маленького до самого большого.
А как оформить этот самый бэклог... это отличный вопрос. Это на самом деле шаг номер два 😁 Потому что первым бэклогом может стать, например, избранное в телеге, или заметки в телефоне. А потом, конечно-же, захочется это оптимизировать и улучшить. Например в тот момент, когда вы поймете, что не знаете что делать в первую очередь.
И вот тут, как говорится, собачка то и порылась.
К оформлению бэклога и приоритизации фич есть целая куча подходов. Фреймворков, если угодно. Вот некоторые из них в столбик:
→ Метод приоритизации PIE. Прямо сейчас я им пользуюсь в Структуре и не могу сказать что жалею.
В двух словах суть в том, чтобы каждой фиче присваивать три параметра: Потенциал, Важность, Простота реализации. А потом считать их сумму и на основе этих цифр брать фичи в работу. Не могу сказать что прям вся работа над структурой строится именно так, но жить помогает, рекомендую. В комментарии приложу скрин своего бэклога прямо сейчас.
→ User Story Mapping. Отличный фреймворк, которым я пользуюсь постоянно, но в голове. Очень редко что-либо рисую, потому что часто хватает воображения.
Вкратце суть в том, что вы не рассматриваете фичи отдельно, а всегда живете в цельном мире, где пользователь не касается продукта по кусочкам, а проходит путь целиком. Я часто если беру отприоритизированную фичу из бэклога с итоговым PIE, я все равно в голове прогоняю через юзер стори. Подробнее можно почитать у Тиграна на канале.
→ MoSCoW (Москва ни при чем). Прикольная тоже модель, но как по мне, не учитывает размер фичи. Зато визуально можно поиграться и подвигать стикеры. Хотя для двиганья стикеров еще куча других фреймворков подходят.
Кароче если вкратце, то суть в отделении критических фичей от некритических. Человек не может без дыхания — это критическая фича. Но иногда может ходить без одежды, это не берем в первый приоритет. Подход хорошо помог бы продуктам, которые слишком много времени тратят, скажем, на дизайн авторизации, но мало времени уделяют core функционалу.
Подробнее опять у Тиграна. Подпишитесь на него, кстати.
→ Модель Кано. Ценность\усилия, RICE. Вот вам еще ключевых слов на эту тему, если хочется упороться и узнать как можно больше по этой теме. Я эти подходы не использовал, поэтому и комментировать не буду.
Важно понимать, что ни один из подходов не является идеальным и лучше бы использовать 2-3 как это делаю я. Ведь умение взглянуть под разными углами на происходящее — это важнейший навык вообще по жизни.
Пишите как вы работаете с бэклогом у себя и понравился ли пост 👇