Приоритизация задач или как я балансирую между багами, хотелками и фичами

Была недавно на митапе с двумя продакт-менеджерами: из Skyscanner – сервис поиска авиа-билетов и Atrapalo – маркетплейс поиска ресторанов. Когда их спросили, что самое важное в работе продакт-менеджера они хором ответили «1. Говорить «Нет» и 2. Приоритизировать задачи».

Мастерство «говорить «Нет» я все еще осваиваю с переменным успехом, а вот о том, как мы приоритизируем задачи – расскажу с удовольствием.

Вся работа нашей продуктовой команды и программистов крутится вокруг тикетов. Тикеты ставятся в Jira, каждому назначается тип: баг, таск или задача. Баги и таски ставят все у кого есть доступ в Jira (руководилели отделов, некоторые менеджеры и ключевые специалисты). Задачи ставлю только я. Баги и таски стараюсь просматривать на предмет адекватности.

Баги делятся на критические и некритические. Критическим считается баг, блокирующий основной процесс для значительного количества пользователей. Формальных критериев мы пока не ввели – пользуемся здравым смыслом. Например, если пользователи из Германии не могут оплатить заказ или если не отправляются email'ы с напоминанием о платеже – это критический баг.

Критические баги идут с высочайшим приоритетом. Находим такой баг – сразу все бросаем и стараемся его закрыть.

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

Придерживаемся правила – иметь не больше 10 открытых багов. Во-первых, даже некритические баги ухудшают репутацию и снижают доверие пользователей к ресурсу. Во-вторых, для менеджеров, которые сообщают о багах важно видеть, что мы регулярно и быстро эти баги закрываем. В этом случае, ребята не ленятся сообщать о странном поведении системы. Если баги игнорировать – менеджеры не видят смысла о них сообщать и вообще перестают давать какой-то фидбек.

Таски – это то, что не требует разработки и деплоя – например, поменять текст, перелопатить URL'ы, поставить редиректы, сделать выгрузку из БД и др. У них приоритет в среднем низкий. Делаем их когда есть время, или если реквестор очень сильно просит.

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

В последнее время этих задач стало на порядок меньше, потому, что мы интегрировали систему для визуализации данных Tableau и теперь все, кому надо отчет о чем бы то ни было – могут посмотреть сами. Тема отличная и заслуживает отдельного подробного поста. Если хотите – расскажу :)

Задачи – это самое главное. По сути это то, чем я занимаюсь большую часть времени.

Они делятся на два типа:

На задачи по основной воронке у меня есть примерно 30-40% времени, на все остальное тоже около 30%. В сумме не получается 100%. Угу. Это потому, что есть баги, таски, рефакторинг, непредвиденные ситуации и прочий технический долг.

Идем дальше. Задачи одного из департаментов чаще всего стоят в приоритете над другими. Например, для нас критичен огранический трафик, поэтому SEO задачи приоритетнее задач продажников. Т.е. на SEO я выделяю примерно 20% времени, остальное – делю между остальными группами.

Внутри каждой группы задач собирается список идей/хотелок. Идеи поступают отовсюду – анализ конкурентов, брейнсторминг, идеи клиентов/сотрудников… При помощи интуиции и здравого смысла выбираем из этого списка штук 10-15 наиболее адекватных задач.

Дальше этот список скорится по методологии ICE-score с оглядкой на нашу North Star Metric. Каждой задаче дается три значения, каждое – от 1 до 5:
I – Impact – насколько большим будет выхлоп по нашему мнению (например, поднимаем конверсию на 1%),
C – Confidence - насколько мы уверены, что это сработает (например, у всех конкурентов если эта фича)
E – Ease - насколько легко реализовать (сколько программисто-часов надо вложить).

Значения складываем, делим на 3, получаем одну цифру ICE-score для каждой задачи. Сортируем, берем задачи с высочайшим ICE-score, запускаем в производство… ну, почти. На самом деле, если задача получила наивысший приоритет, это еще не означает, что она будет 100% сделана в ближайшее время. Об этом ниже.

Выбранные задачи ставятся в Jira, им назначается тип New development. Все задачи этого типа попадают на Канбан-доску. Почему Канбан и чем наш Канбан отличается от привычного Скрама я уже рассказывала.

В теории все красиво – планируем вперед примерно на квартал. Выбранные задачи попадают в Беклог (колонка ToDefine), где стараюсь держать около 10 задач. Беру по одной сверху, прорабатываю со стейкхолдерами, если нужно проводим клиентское исследование, бывает, что тестируем прототип, рисуем дизайн. Затем расписываю, готовлю для программистов и перевожу в ToDo где стараюсь держать около 5-и задач, чтобы все влезло в более менее один экран. Ребята берут по одной, переводят в InProgress и так далее в Done.

Однако в реальности все не так, вернее не все так линейно. Периодически задачи в ToDefine пересматриваются. Что-то может влезть в середину и подвинуть другие задачи – это нормально, т.к. бизнес живой.

Плюс, при краткосрочном планировании нужно учитывать очередь А/Б-тестов. По сути это – боттлнек. Я могу тестировать только одну фичу в один момент времени. На тест уходит 1-2 недели. Поэтому, задачи, которые нужно А/Б-тестировать должны выходить в продакшен друг за другом с указанным перерывом. Чаще – смысла нет, т.к. они встанут в очередь и снизят скорость разработки, реже – неэффективно, потому, что будет простаивать площадка для тестов, а это – дорогой ресурс.

Про А/Б/тесты я писала тут и тут. И скорее всего напишу еще, потому, что технология продвинулась и теперь мы тестируем кросс-доменно и меряем не только конверсию в заявку, но и конверсию в покупку.

Кроме того, бывает, что одна задача блокирует другую (например, внедряем поисковый движок Elastic и пока не закончим, нет смысла менять что-то в поиске лодок на лендингах). Либо задача блокируется внешними факторами (например, маркетинг не успел подготовить контент). Это тоже нужно учитывать, передвигать задачу в колонку Blocked и переигрывать очередность задач.

А бывает так, что задача теряет свою актуальность или ее приоритет внезапно снижается. Например, если мы не успеваем внедрить скидки Early Booking (раннее бронирование) до Нового года, то можно их уже не внедрять – они понадобятся только следующей осенью. Лучше сфокусироваться на чем-то другом, что даст результат сейчас. Если делаешь задачи только потому, что «Ну мы уже 3 месяца обещаем это сделать», становишься заложником обещаний и все время все делаешь не вовремя и чувствуешь себя под давлением.

Очень старалась расписать четко и ясно как же приоритизирую задачи, Скорее всего, наоборот, всех запутала :)

По большому счету, я придерживаюсь следующих принципов:

Буду рада услышать, а как у вас построен процесс приоритизации – что делаете так же, а что – по-другому. Если есть вопросы – задавайте, обязательно отвечу.