{"id":14287,"url":"\/distributions\/14287\/click?bit=1&hash=1d1b6427c21936742162fc18778388fc58ebf8e17517414e1bfb1d3edd9b94c0","title":"\u0412\u044b\u0440\u0430\u0441\u0442\u0438 \u0438\u0437 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430 \u0434\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0437\u0430 \u0433\u043e\u0434","buttonText":"","imageUuid":""}

Аналитик в огне!🔥 Как построить процесс постановки задач в условиях нехватки ресурса

Типичный аналитик, заваленный ad-hoc задачами 

Кому будет полезна статья?

- аналитикам и их руководителям, которые устали от бесконечного потока ad-hoc задач и хотят построить нормальный процесс работы;

- продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;

- бизнес-заказчикам, которые недовольны скоростью решения задач и отсутствием прозрачности в процессе их решения.

Коротко об авторах

Давид Мкртумян (Linked-in | FB | VK | Instagram)

Я работаю ведущим менеджером продукта в Авито и являюсь автором Telegram-канала Product Net, где делюсь своим опытом, оказываю карьерные консультации и помогаю продактам найти работу своей мечты. До этого работал продактом в AliExpress, Яндекс Маркете и 3 года развивал собственный бизнес.

Вова грустно смотрит вдаль после получения очередной ad-hoc задачи)))

Владимир Тепляков

Вова работает продуктовым аналитиком в Авито. У него больше 5 лет опыта в области анализа данных. Ранее работал в ГК ПИК, Везёт (нынче Яндекс.Такси) и Магнит. В свободное время администрирует Telegram канал «Дата-аналитика, и с чем её едят», где вместе с коллегами помогает начинающим аналитикам и делится профессиональным опытом.

В чем была проблема?

Если быть точным, то был целый букет проблем:

  • Команде аналитики регулярно вкидывали срочные ad-hoc задачи в середине спринта.
  • Бизнес-заказчики часто ставили своим задачам наивысший приоритет, в результате чего задачи продакта откладывались, от чего страдал весь продуктовый процесс.
  • В спринт попадали непрогруммленные и плохо сформулированные задачи. В итоге на выходе заказчик получал не тот результат, который ожидал.
  • Заказчики были недовольны сроком выполнения задач. Процесс был непрозрачным.
  • Из-за всех вышеперечисленных проблем в команде постоянно возникали разногласия.
  • Аналитик горел словно ведьма на костре инквизиции.

Что сделали?

1. Завели Google таблицу со следующими столбцами:

Задача

Указываем название задачи. При необходимости добавляем комментарии к ячейке с названием. К названию задачи прикрепляем ссылку на тикет в jira/трекер с подробным описанием задачи.

Типа задачи

  • Исследование
  • Выгрузка
  • АБ-тест

Заказчик

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

Приоритет

  1. Высокий
  2. Средний
  3. Низкий

Нужен ли грумминг

Тут ставим чек-бокс – да/нет

Задача прогруммлена

Аналогично - да/нет

Нужно взять в следующий спринт

Так же чек-бокс – да/нет. Это также влияет на приоритет задачи.

Story points (SP)

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

Статус

  • New – обсуждаются на регулярной встрече.
  • In progress – в случае необходимости обсуждаются на регулярной встрече.
  • Done – улетают в лист “Архив” в той же Google таблице, чтобы к ним можно было вернуться, если возникнет такая необходимость.
  • Hold – улетают в архив, если больше месяца не берется в работу.

2. Поставили регулярную встречу для обсуждения аналитических задач

Состав участников

  • Аналитик
  • Продакт
  • Проджект
  • Маркетолог

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

Подготовка к встрече

Каждый участник накануне встречи вносит свои задачи в таблицу и прикрепляет к ним тикет в jira.

Ход встречи

На встрече сразу договариваемся чьи задачи нужно обсудить в первую очередь, чтобы экономить время коллег. В ходе обсуждения вносим комментарии в тикет в jira. Обязательно уточняем приоритет и синхронизируемся со всеми участниками встречи, чтобы убедиться, что у аналитика хватит ресурса и что чья-то важная задача не будет выкинута из следующего спринта. За полгода существования процесса ни разу не возникло ситуации, чтобы мы не договорились по приоритетам и очередности задач на встрече.

После встречи

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

Каких результатов добились?

  • Свели к минимуму количество ad-hoc задач на аналитику. Теперь это редкие, единичные случаи.
  • Сделали процесс прозрачным для всех членов команды.
  • Нормализовали нагрузку на аналитика.
  • Больше не толкаемся локтями и не спорим, чья задача важнее.
  • Уже полгода радуемся эффективной и слаженной работе в команде ;)

P.S.

На этом все. Если вам понравилась статья, то поделитесь ей с теми, кому она может быть полезна, и подписывайтесь на мой канал Product Net в Telegram. Там вы найдете больше материалов на актуальные вопросы, сможете влиять на темы будущих постов и получить помощь в трудоустройстве в топовые российские IT компании ;)

0
Комментарии
-3 комментариев
Раскрывать всегда