Настя Арсеньева, Project manager TG: @ursulaminor Даша Авдеева, Atlassian Engineer TG: @kenoaa
Есть менеджер, который: Прорабатывает проект Передает работу в другие команды Следит за продвижением по RoadMap Отвечает за попадание в сроки Поддерживает прозрачность для вовлеченных команд: что и зачем мы делаем Проблема
Менеджер : Много ручной работы Были перегреты Много переключались между задачами Внесение любых правок вызывало боль Команды: Не всегда получали информацию в полном объеме Иногда динамичные изменения не доходили до команд (человеческие ошибки)
+14% к скорости этапа проработки кампаний 0% человеческих ошибок при передаче обновлений Передача контекста в команды в полном объеме Минимизация ручного труда Повышение уровня удовлетворенности процессом
Текстовое поле под Бриф для команд каналов Выпадающее меню под список команд каналов с мультивыбором Дополнительный статус, который триггерит запуск автоматизации
Задача создается в проекте продюсеров и попадает в триггерный статус Автоматизация: Проверяет поле Media Mix (со списком команд каналов) Создает задачи-клоны в выбранные проекты, пробрасывает связь “родитель-ребенок” Копирует значение поля Description в Бриф (не редактируется у тикетов-детей)
Под конкретизацию ТЗ для команды канала осталось поле Description. Оно редактируется и автоматизация оставляет его пустым.
Любые изменения в оригинальной задаче на проведение акции переносятся в задачи-дети (обновляется поле “Бриф”). При этом исполнитель дочерней задачи получает нотификацию в Slack.
Trigger: перевод в статус Creating Дополнительно проверяем, нет ли уже эпика для команды Branch: For current issue с проверкой значения поля Media Mix Action: создание задачи в проекте
При создании эпика оставляем Description пустым, но копируем в Brief описание из родительской задачи типа Project. Brief сделали нередактируемым через Scriptrunner, чтобы оно всегда соответствовало родительской задаче. Линкуем задачи дочерне-родительской связью. А ещё добавляем лейбл, чтобы по нему строить диаграмму Ганта, но это совсем другая история:)
Когда в родительской задаче обновляется одно из полей, которое необходимо передавать командам, выполняется Branch For JQL, по которому находятся все эпики с задачей в Parent Link. Копируем из родителя значения полей, уведомляем в Слак исполнителя.
При каждом обновлении копируются все вложения. Три обновления задачи с тремя вложениями => девять вложений в дочерних задачах:)
Создали отдельную автоматизацию, реагирующую на изменения только во вложениях. Так же отправляем уведомление в Слак и с помощью инструмента n8n. Из истории изменений в задаче забираем последнее событие для Attachment. Если вложения не было, а теперь есть, забираем его и отправляем во все эпики.
Поля расшарены не на все проекты Нужного поля нет на скрине создания задачи в проекте В проектах могут быть свои обязательные поля Сотрудники приходят и уходят… а автоматизация остаётся:)
При первых тестовых запусках в одном из проектов создался эпик, к которому ни у кого нет доступа. Я до сих пор вижу его заголовок в поиске, но не могу открыть и изменить. Такое возможно в случае, если не установлена Security Scheme для проекта, но это не наш случай. Каждый раз автоматизация спотыкалась на нём, так как не могла его отредактировать. Мы придумали костыль: А теперь вопрос! Что не так с эпиком?
В управлении проектами В разработке ПО Исследования HR
(и спасибо за внимание)
