Комментарии 11
Не понятно, как табличка Excel помогла с
Больше не толкаемся локтями и не спорим, чья задача важнее
Бизнес-заказчики часто ставили своим задачам наивысший приоритет, в результате чего задачи продакта откладывались, от чего страдал весь продуктовый процесс.
хм... мой опыт работы в крупных конторах говорит, что обычно у задачи есть два приоритета:
приоритет выставленный пользователем
внутренний приоритет выставленный по результатам обсуждения командой (пользователю он не виден), но именно на него ориентируются в реальной работе
Это классная практика. Однако, что в Яндексе, что в Авито я сталкивался с тем, что у бизнес-заказчиков могут быть свои проекты: конференции, к которым нужно подготовиться, GR партнерства, защита стратегии и т.д. Именно для таких проектов мы и договаривались по приоритетам, если ресурса аналитика не хватало.
Так внутренний приоритет ставится в том числе и с учётом приоритета заказчика. То есть заказчик чаще всего по умолчанию выставляет высокий приоритет, а вот те, кто отвечают за внутреннюю приоритизацию смотрят, чем он обусловлен. Если, например, баг некритичный, возникает только на тесте итп, тогда внутренний приоритет ставится низкий. Если же у заказчика лежит весь прод, то тогда и внутренний будет таким же.
Более того, в процессе дальнейшего изучения внутренний приоритет может уточнятся, например, если по важному багу заказчик не готов оперативно коммуницировать, тогда значит он не настолько для него важен и внутренний приоритет снижаем. И наоборот, если дальше заказчик излагает, что проблема хоть и на тесте, но является блокером для ближайшего релиза - приоритет повышается.
В данном случае вы рассматриваете исключительно ситуацию с багом. Я говорю о более широком круге задач, которые не связаны с багами на проде, но требуют ресурса аналитика. Например:
подготовка стратегии. У бизнес-заказчика есть дедлайн по защите стратегии. Для того, чтобы определить приоритетные направления, нужно сделать сегментацию текущих пользователей по размеру аудитории и бюджету. Может быть сегмент пользователей, который мы считаем перспективным, но он не выделен на дашбордах. Для идентификации сегмента может потребоваться выгрузка по кастомному набору параметров.
Проведение профессиональных выставок, на которых выступают заказчики. Может потребоваться аналитика, чтобы презентовать интересные цифры на конференции.
Маркетинговые кампании, для определения параметров которых может потребоваться информация по целевой аудитории в разрезе городов, чтобы понять, в каких городах стоит вкладываться в продвижение.
Наша продуктовая команда шарит ресурс аналитика с бизнесом. Чтобы избежать ad-hoc задач. Мы построили этот процесс, который позволил договариваться о приоритетах на следующий спринт и избежать сдвига других задач. Таким образом, как бизнес, так и продукт имеют прозрачное понимание по ресурсам аналитика, срокам выполнения задач и приоритетам.
Вы уж простите, но источником проблемы в примере служит менеджер продукта:)))
Тот случай, когда ответственный за коллектив занят:)))
Не соглашусь с вами)
Есть чисто бизнесовые задачи, которые не проходят через продакта. Я их перечислил в комментарии выше. В данном случае важно синхронизироваться с командой и убедиться, что никто не подвинул чужие задачи, так как мы шарим ресурс аналитика с бизнесом. Более того, в процессе встречи гораздо легче найти компромисс по приоритетам. Ни раз было так, что каждый закзчик считал свою задачу важной, но в процессе обсуждения выяснялось, что чья-то задача может 1-2 недели подождать. Кажется, что 1 час в неделю не такая большая инвестиция, которая позволяет избежать потерь времени аналитика и других членов команды на выяснение почему чья-то задача была выкинута из спринта. При этом выстраиваются очень прозрачные и доверительные отношения в команде между командами бизнеса, продукта, аналитики и маркетинга.
Идея и подход ясны, но можно же было использовать все возможности Jira/Я.Трекер и не заводить лишних таблиц
Практика показывает, что некоторых высокопоставленных заказчиков тяжело приучить к Jira/Я.Трекер. Для них, как для пользователей, это неудобный канал постановки задач и коммуникации. Обычно задачи от таких заказчиков прилетают в чате или ставятся голосом. Как следствие, задача ставится нечетко, и аналитику приходится несколько раз переделывать задачу.
Гораздо эффективнее заставить встречу с такими заказчиками, снять с них их потребности, зафиксировать все договоренности в Jira. Таблица, в данном случае, лишь вспомогательный инструмент, который понятен всем и позволяет сделать быстрый overview всех задач, сроков и приоритетов.
Естественно, после обсуждения, мы заводим все задачи в Jira, где детально описываем задачу после обсуждения и фиксируем все договоренности.
Такой процесс помогает:
- избежать переделок задачи и дополнительных трат ресурса аналитика
- синхронизировать всю команду
- сделать работу аналитика прозрачной для всех заказчиков и выровнять их ожидания
Если уж прям докопаться до определений, то задача не может быть "прогруммлена". Прогруммленным может быть бэклог )
Аналитик в огне! Как построить процесс постановки задач в условиях нехватки ресурса