31.07.2023 08:33
DavidMkrtumyan 10 656 Источник
Типичный аналитик, заваленный ad-hoc задачами 
Типичный аналитик, заваленный ad-hoc задачами 

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

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

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

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

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

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

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

Вова грустно смотрит вдаль после получения очередной ad-hoc задачи)))
Вова грустно смотрит вдаль после получения очередной 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 компании ????

Комментарии (10)


  1. Farongy
    31.07.2023 08:50
    #25806926

    Не понятно, как табличка Excel помогла с

    Больше не толкаемся локтями и не спорим, чья задача важнее


    1. DavidMkrtumyan Автор
      31.07.2023 08:50
      #25806996
      -1

      Табличка лишь часть процесса. Во многом проблема была из-за отсутствия синхронизации между заказчиками. Регулярный синк помог отладить эти вопросы. Табличка нужна лишь для фиксации договоренностей и результатов


  1. 0mogol0
    31.07.2023 08:50
    #25806934

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

    хм... мой опыт работы в крупных конторах говорит, что обычно у задачи есть два приоритета:

    • приоритет выставленный пользователем

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


    1. DavidMkrtumyan Автор
      31.07.2023 08:50
      #25807036
      -1

      Это классная практика. Однако, что в Яндексе, что в Авито я сталкивался с тем, что у бизнес-заказчиков могут быть свои проекты: конференции, к которым нужно подготовиться, GR партнерства, защита стратегии и т.д. Именно для таких проектов мы и договаривались по приоритетам, если ресурса аналитика не хватало.


      1. 0mogol0
        31.07.2023 08:50
        #25807304

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


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


        1. DavidMkrtumyan Автор
          31.07.2023 08:50
          #25808324
          -1

          В данном случае вы рассматриваете исключительно ситуацию с багом. Я говорю о более широком круге задач, которые не связаны с багами на проде, но требуют ресурса аналитика. Например:

          • подготовка стратегии. У бизнес-заказчика есть дедлайн по защите стратегии. Для того, чтобы определить приоритетные направления, нужно сделать сегментацию текущих пользователей по размеру аудитории и бюджету. Может быть сегмент пользователей, который мы считаем перспективным, но он не выделен на дашбордах. Для идентификации сегмента может потребоваться выгрузка по кастомному набору параметров.

          • Проведение профессиональных выставок, на которых выступают заказчики. Может потребоваться аналитика, чтобы презентовать интересные цифры на конференции.

          • Маркетинговые кампании, для определения параметров которых может потребоваться информация по целевой аудитории в разрезе городов, чтобы понять, в каких городах стоит вкладываться в продвижение.

            Наша продуктовая команда шарит ресурс аналитика с бизнесом. Чтобы избежать ad-hoc задач. Мы построили этот процесс, который позволил договариваться о приоритетах на следующий спринт и избежать сдвига других задач. Таким образом, как бизнес, так и продукт имеют прозрачное понимание по ресурсам аналитика, срокам выполнения задач и приоритетам.


  1. kost_tr
    31.07.2023 08:50
    #25807090
    -1

    Вы уж простите, но источником проблемы в примере служит менеджер продукта:)))

    Тот случай, когда ответственный за коллектив занят:)))


    1. DavidMkrtumyan Автор
      31.07.2023 08:50
      #25808470
      -1

      Не соглашусь с вами)

      Есть чисто бизнесовые задачи, которые не проходят через продакта. Я их перечислил в комментарии выше. В данном случае важно синхронизироваться с командой и убедиться, что никто не подвинул чужие задачи, так как мы шарим ресурс аналитика с бизнесом. Более того, в процессе встречи гораздо легче найти компромисс по приоритетам. Ни раз было так, что каждый закзчик считал свою задачу важной, но в процессе обсуждения выяснялось, что чья-то задача может 1-2 недели подождать. Кажется, что 1 час в неделю не такая большая инвестиция, которая позволяет избежать потерь времени аналитика и других членов команды на выяснение почему чья-то задача была выкинута из спринта. При этом выстраиваются очень прозрачные и доверительные отношения в команде между командами бизнеса, продукта, аналитики и маркетинга.


  1. Vov4agius
    31.07.2023 08:50
    #25807502

    Идея и подход ясны, но можно же было использовать все возможности Jira/Я.Трекер и не заводить лишних таблиц


    1. DavidMkrtumyan Автор
      31.07.2023 08:50
      #25811830

      Практика показывает, что некоторых высокопоставленных заказчиков тяжело приучить к Jira/Я.Трекер. Для них, как для пользователей, это неудобный канал постановки задач и коммуникации. Обычно задачи от таких заказчиков прилетают в чате или ставятся голосом. Как следствие, задача ставится нечетко, и аналитику приходится несколько раз переделывать задачу.

      Гораздо эффективнее заставить встречу с такими заказчиками, снять с них их потребности, зафиксировать все договоренности в Jira. Таблица, в данном случае, лишь вспомогательный инструмент, который понятен всем и позволяет сделать быстрый overview всех задач, сроков и приоритетов.

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

      Такой процесс помогает:
      - избежать переделок задачи и дополнительных трат ресурса аналитика
      - синхронизировать всю команду
      - сделать работу аналитика прозрачной для всех заказчиков и выровнять их ожидания