Аналитик в огне!🔥 Как построить процесс постановки задач в условиях нехватки ресурса
Кому будет полезна статья?
- аналитикам и их руководителям, которые устали от бесконечного потока ad-hoc задач и хотят построить нормальный процесс работы;
- продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;
- бизнес-заказчикам, которые недовольны скоростью решения задач и отсутствием прозрачности в процессе их решения.
Коротко об авторах
Я работаю ведущим менеджером продукта в Авито и являюсь автором Telegram-канала Product Net, где делюсь своим опытом, оказываю карьерные консультации и помогаю продактам найти работу своей мечты. До этого работал продактом в AliExpress, Яндекс Маркете и 3 года развивал собственный бизнес.
Владимир Тепляков
Вова работает продуктовым аналитиком в Авито. У него больше 5 лет опыта в области анализа данных. Ранее работал в ГК ПИК, Везёт (нынче Яндекс.Такси) и Магнит. В свободное время администрирует Telegram канал «Дата-аналитика, и с чем её едят», где вместе с коллегами помогает начинающим аналитикам и делится профессиональным опытом.
В чем была проблема?
Если быть точным, то был целый букет проблем:
- Команде аналитики регулярно вкидывали срочные ad-hoc задачи в середине спринта.
- Бизнес-заказчики часто ставили своим задачам наивысший приоритет, в результате чего задачи продакта откладывались, от чего страдал весь продуктовый процесс.
- В спринт попадали непрогруммленные и плохо сформулированные задачи. В итоге на выходе заказчик получал не тот результат, который ожидал.
- Заказчики были недовольны сроком выполнения задач. Процесс был непрозрачным.
- Из-за всех вышеперечисленных проблем в команде постоянно возникали разногласия.
- Аналитик горел словно ведьма на костре инквизиции.
Что сделали?
1. Завели Google таблицу со следующими столбцами:
Задача
Указываем название задачи. При необходимости добавляем комментарии к ячейке с названием. К названию задачи прикрепляем ссылку на тикет в jira/трекер с подробным описанием задачи.
Типа задачи
- Исследование
- Выгрузка
- АБ-тест
Заказчик
Указываем имя заказчика, чтобы аналитик знал с кем связаться, в случае, если возникнут вопросы по задаче.
Приоритет
- Высокий
- Средний
- Низкий
Нужен ли грумминг
Тут ставим чек-бокс – да/нет
Задача прогруммлена
Аналогично - да/нет
Нужно взять в следующий спринт
Так же чек-бокс – да/нет. Это также влияет на приоритет задачи.
Story points (SP)
В этом поле навскидку аналитик указывает количество SP, которое ему потребуется на решение задачи.
Статус
- New – обсуждаются на регулярной встрече.
- In progress – в случае необходимости обсуждаются на регулярной встрече.
- Done – улетают в лист “Архив” в той же Google таблице, чтобы к ним можно было вернуться, если возникнет такая необходимость.
- Hold – улетают в архив, если больше месяца не берется в работу.
2. Поставили регулярную встречу для обсуждения аналитических задач
Состав участников
- Аналитик
- Продакт
- Проджект
- Маркетолог
По необходимости к встрече, могут присоединяться бизнес-лидер и представители команды продаж, но обычно их запросы транслирует проджект.
Подготовка к встрече
Каждый участник накануне встречи вносит свои задачи в таблицу и прикрепляет к ним тикет в jira.
Ход встречи
На встрече сразу договариваемся чьи задачи нужно обсудить в первую очередь, чтобы экономить время коллег. В ходе обсуждения вносим комментарии в тикет в jira. Обязательно уточняем приоритет и синхронизируемся со всеми участниками встречи, чтобы убедиться, что у аналитика хватит ресурса и что чья-то важная задача не будет выкинута из следующего спринта. За полгода существования процесса ни разу не возникло ситуации, чтобы мы не договорились по приоритетам и очередности задач на встрече.
После встречи
Пишем короткий отчет в аналитический чат, где указываем, какие задачи будут взяты в следующий спринт и какие особо сложные задачи нужно вынести на дополнительный грумминг. Пишем повестку на грумминг и зовем коллег, чья помощь может потребоваться.
Каких результатов добились?
- Свели к минимуму количество ad-hoc задач на аналитику. Теперь это редкие, единичные случаи.
- Сделали процесс прозрачным для всех членов команды.
- Нормализовали нагрузку на аналитика.
- Больше не толкаемся локтями и не спорим, чья задача важнее.
- Уже полгода радуемся эффективной и слаженной работе в команде ;)
P.S.
На этом все. Если вам понравилась статья, то поделитесь ей с теми, кому она может быть полезна, и подписывайтесь на мой канал Product Net в Telegram. Там вы найдете больше материалов на актуальные вопросы, сможете влиять на темы будущих постов и получить помощь в трудоустройстве в топовые российские IT компании ;)