Введение
Для команды, которая развивает автономный продукт, многие вопросы можно решить на одной встрече. Ситуация резко усложняется, когда команд становится десятки, а изменения в общем инфраструктурном или платформенном продукте последовательно затрагивают несколько зависимых систем.
Что произойдёт, если команды в конце цепочки не знают о планах владельца core-продукта? Что будет, если инициативный Product Manager сможет быстро провести свой бэклог через смежные команды, но локальная оптимизация приведёт к общим потерям и замедлению time to market? Кто отвечает за задачи, которые годами накапливаются между командами?
Такие проблемы часто возникают в организациях, которые выросли быстрее, чем их процессы. При этом Agile-принципы начинают трактоваться как разрешение игнорировать долгосрочные интересы бизнеса и соседних команд.
Я не предлагаю выбирать между «чистым» Waterfall и «чистым» Agile. Методология — это набор инструментов, а не предмет веры. В каждой ситуации нужно искать подходящее сочетание практик. Ниже приведён пример того, как выстроить целеполагание и связи между задачами в Jira, если бэклог уже живёт собственной жизнью, а ресурсов на полномасштабную перестройку системы нет.
Анализ исходной ситуации
Не буду перегружать статью подробностями интервью со всеми стейкхолдерами. Сразу перейду к ключевым наблюдениям.
Приоритизация целей
-
В компании была утверждена методология формирования приоритетов на кросс-командном уровне.
-
На практике она полноценно применялась только во время годового планирования. Процесса квартального уточнения приоритетов при изменении целей не было.
-
Методология позволяла определить приоритет цели для команды-владельца, но не давала понятного механизма для зависимых команд.
Структура Jira
-
Все продуктовые команды работали в одном общем проекте.
-
Администраторов Jira было много. Это были не только специалисты поддержки, но и сотрудники, способные изменять конфигурацию всей системы.
-
Jira использовалась всей компанией, а не только продуктовыми командами, поэтому радикальные изменения стандартной иерархии задач были невозможны.
-
В стандартной конфигурации использовались три уровня: Epic, Task и Sub-task.
-
Каждая команда требовала настроить процесс под себя. В результате в проекте появились десятки типов задач, workflow и полей, хотя большинство из них практически не использовалось.
Такая конфигурация создавала несколько системных рисков: изменения одного администратора могли нарушить процессы других команд, а отсутствие владельца общего бэклога означало, что никто не хотел регулярно разбирать «чужие» задачи.
«Контракты» между командами
В компании использовалось понятие «постановка контрактов». При детальном анализе выяснилось, что под ним скрывались любые кросс-командные активности:
-
Change Request — запросы на изменение;
-
доработки API;
-
изменения схем данных;
-
инфраструктурные доработки;
-
другие работы, необходимые соседней команде.
При этом такие задачи могли не быть связаны ни с целью, ни с эпиком. Они просто оставались в бэклоге. Команда-инициатор считала, что передала запрос, а команда-исполнитель могла не знать о его существовании или не понимать его бизнес-приоритет.
Ключевая задача изменений состояла не в том, чтобы «идеально настроить Jira», а в том, чтобы обеспечить сквозную приоритизацию каждой значимой задачи и не разрушить процессы команд, которые уже работали в системе.
Компромиссный подход
Что делать, если формальные процессы существуют, но не соблюдаются, а команды перекладывают ответственность друг на друга? В такой ситуации нужен не очередной регламент, а простая модель с понятными правилами и автоматическим контролем.
Основные решения были такими:
-
Имя цели в Fix Version → отдельная задача-цель. Цель перестаёт быть только значением поля и становится полноценным объектом Jira.
-
Один общий проект → отдельный проект для каждой команды. Команды получают собственных администраторов и могут управлять внутренними процессами, не меняя настройки соседей.
-
Нет связи задачи с целью → автоматические проверки. Задачи без необходимой связи выявляются на дашбордах и не должны оставаться незаметными в бэклоге.
-
Нет регулярного grooming → ответственность команды за качество собственного бэклога.
-
Свободная постановка задач смежникам → стандартизированная связь. Для кросс-командной работы используется единый тип запроса — Change Request (CR, или ЗНИ — запрос на изменение).
-
Приоритеты выставляются вручную и нерегулярно → автоматическая актуализация. Скрипты и автоматизации Jira распространяют приоритет по цепочке связанных задач.
Главный принцип: каждая задача должна быть связана с целью, а каждая зависимость — явно отражена в Jira.
Далее в работу вступают автоматизации и скрипты ScriptRunner, настроенные на события и изменения задач. Они актуализируют приоритеты, сроки и связи по всей цепочке.
На схеме показаны два состояния:
До изменений: задачи находятся внутри эпиков, а эпики могут объединяться только общим значением Fix Version (релизом). Часть задач не связана ни с какой целью.
После изменений: в отдельном проекте появляется задача-цель. Она связана с эпиком команды, который декомпозируется на истории и задачи. Вся цепочка дополнительно объединена связями
parent of/child of. Такая струткура позволяет использовать глубокие автоматизации и скрипты для обновления задач.
Три стадии миграции бэклога
1/3. Исходное состояние
-
Все команды работают в одном проекте.
-
Каждая команда создаёт собственные эпики — крупные вехи или этапы.
-
Часть задач существует отдельно и не входит ни в одну группу.
-
Команда создаёт «контракт» на другую команду внутри своего эпика, но связь необязательна. Поэтому команда-исполнитель не всегда знает, что от неё требуется работа.
2/3. Промежуточное состояние: отдельные проекты команд
-
Для каждой команды создаётся собственный проект.
-
Задачи могут находиться в разных проектах, но связываются линками
parent of/child of. -
Старые «контракты» всё ещё могут создаваться в произвольном месте и теряться.
Этот этап снижает конфликтность администрирования, но сам по себе ещё не обеспечивает сквозного отслеживания целей.
3/3. Целевое состояние
-
Выделяется отдельный проект для общих целей команд.
-
Если требуется работа соседней команды, создаётся подцель или CR/ЗНИ — запрос на изменение. Он связывается с исходной целью.
-
Команды декомпозируют цели и запросы в собственных проектах так, как им удобно. Общее правило одно: все значимые задачи связаны с целью.
Как это выглядит в Jira
Проект «Цели»
-
Epic — цель команды A.
-
Change Request — запрос на изменение для команды B.
-
Цели и запросы связываются с помощью
parent of/child of. Автоматизация дополнительно объединяет их в единую иерархию и транслирует общий приоритет. -
При изменении цели — например, её приоритета, срока, команды или ответственного — изменения автоматически распространяются на связанные задачи по цепочке.
Проект команды A
-
Команда создаёт столько эпиков, сколько нужно для удобной декомпозиции цели. Эти эпики связываются с эпиком-целью.
-
Автоматизация актуализирует приоритет эпиков и всех дочерних задач.
-
Задачи внутри эпика объединяются в иерархию на основе стандартной структуры Jira. При необходимости используются дополнительные связи: например, одна история может быть родительской для другой. Это не разрушает общую модель, если правила связей формализованы.
Проект команды B
Принцип тот же, но между целью и задачами команды появляется дополнительный уровень — Change Request. Важно, что команда B не обязана владеть исходной целью: её ответственность начинается в выполнении согласованного запроса.
Граничные случаи
Задачи сервисной команде
Ситуация. Сервисная команда работает по Kanban и принимает отдельные задачи на доработку от других команд. Собственных бизнес-целей у неё нет, но приоритеты нужны для выбора наиболее срочных задач при ограниченных ресурсах.
Решение. Задача связывается с целью инициатора через parent of / child of. Благодаря этому она включается в общую иерархию и получает приоритет цели. Сервисная команда при этом продолжает самостоятельно управлять собственным бэклогом — никто не вмешивается в её внутренний workflow.
Сервисная команда агрегирует входящие запросы
Ситуация. Сервисная команда объединяет множество запросов других команд в одну собственную задачу.
Решение. Здесь требуется более тщательный grooming:
-
Команда-инициатор создаёт задачу по общим правилам и связывает её с целью.
-
Сервисная команда регулярно разбирает входящий поток и консолидирует однотипные запросы в одну задачу.
-
Исходные запросы связываются с итоговой задачей отношением
blocked by/blocks. -
Автоматизация выбирает максимальный приоритет из связанной цепочки и передаёт его агрегирующей задаче.
Подход с двумя «родителями» мне не кажется идеальным: он нарушает принцип однозначной иерархии. Однако в данном случае это был практический компромисс, который позволил не ломать внутренний процесс сервисной команды и сохранить предсказуемость приоритизации.
Скрипты миграции
Полностью переработать бэклог ради общих интересов сложно: нужно синхронизировать действия десятков команд и не остановить текущую работу. Поэтому миграцию лучше выполнять поэтапно, точечно обрабатывая конкретные задачи.
-
Формирование первичных связей. Существующие задачи связываются с эпиками и целями, чтобы не выпасть из поля зрения.
-
Построение агрегатов. Связанные задачи объединяются в единую иерархию, по которой можно передавать приоритеты и отслеживать зависимости.
-
Упрощение структуры. Убираются лишние элементы и связи, чтобы итоговая модель была понятна не только её авторам, но и внешним участникам процесса.
Автоматизация работает только при наличии минимально качественных исходных данных. Stand-alone-задачу без эпика, цели или релиза невозможно надёжно включить в общую цепочку. Поэтому миграция — это не только написание скрипта, но и договорённость о правилах заполнения задач.
Результаты
Изменения упростили целеполагание и отслеживание кросс-командных задач. Команды получили возможность:
-
быстрее находить блокеры и устранять задержки;
-
самостоятельно управлять внутренними процессами, не вмешиваясь в процессы соседей;
-
видеть, какие работы связаны с общей целью и почему они имеют именно такой приоритет;
-
обсуждать сроки и ограничения на основе общедоступных артефактов, а не только устных договорённостей;
-
сохранять разные модели реализации: Waterfall, итерационную или смешанную.
Это не было единственным изменением, необходимым для повышения прозрачности процессов. Однако создание связи каждой значимой задачи с конкретной целью стало важной опорной точкой. Когда задача связана с целью, приоритетом и зависимостями, её можно обсуждать в контексте общего результата, а не как изолированный элемент чужого бэклога.
Почему мы не стали делать ставку на Sub-task
На протяжении всего описанного процесса я почти не упоминал изменение подходов к Sub-task. Причина проста: когда у организации уже возникают проблемы с управлением общим бэклогом, продвинутые, но узкоспециализированные инструменты могут не помочь, а усложнить ситуацию.
Теоретически структуру можно было сделать проще, обязав команды использовать Sub-task. Но для этого потребовалось бы сначала вырастить устойчивую культуру декомпозиции и регулярного обслуживания бэклога.
Кроме того, у Sub-task есть техническое ограничение Jira: она существует только в контексте родительской задачи и должна следовать за ней по спринту. Это становится проблемой, когда команда помещает в один эпик набор работ на несколько месяцев, а затем пытается закрыть очередной спринт, с завершенными и открытыми Sub-task’ами в одной задаче.
Заключение
Приход к сквозной приоритизации не требует все начинать с нуля. В большинстве случаев достаточно выделить цели в отдельные объекты, разделить ответственность за проекты, стандартизировать кросс-командные запросы и автоматизировать передачу приоритетов по связям. В реальной работе команд данные изменения составили очень малую толику операционного времени, но значительно повысили качество и скорость кросс-командных взаимодействий.
А Jira при этом осталась очень эффективным инструментом для управления работами и бэклогом команд без полной переработки и оказания влияния на соседние команды.
Иногда лучший результат даёт не самая элегантная модель управления, а та, которую организация действительно способна поддерживать. В данном случае минимальное изменение Jira, ясные правила связей и автоматическая передача приоритетов оказались практичнее полной перестройки процессов.
Такой подход позволяет улучшать процессы инкрементально — без остановки разработки и без полной переработки уже работающей системы.
Если в данной статье вы встретили знакомые боли, то вам требуются межкомандные изменения, которые зачастую недоступны отдельному продакту или проджекту — нужен комплекс работ согласованный и самое главное — активно поддерживаемый C-менеджерами компании. Я видел множество хороших линейных руководителей с отличными видением процессов готовых активно продвигать улучшения своими руками, но которые просто выгорели в поисках “спонсоров изменений” — их не нашлось в руководстве компаний.
ссылка на оригинал статьи https://habr.com/ru/articles/1066454/