Пока команда одна — все выглядит логично: есть бэклог, есть доска, есть понятный поток работы. Даже если что-то идет не так, это локальная проблема — ее можно быстро найти и исправить.
Но как только команд становится десять или пятнадцать, и они все начинают работать над одним продуктом, система начинает вести себя странно. Вроде бы ничего кардинально не поменялось, но прозрачности становится меньше, синхронизация сложнее, и весь рабочий процесс в Jira все чаще вызывает вопросы.
Всем привет, это команда продукта SimpleOne SDLC. В этой статье разберем, что именно ломается на масштабе и почему это не совсем про «плохую Jira» или «неправильный Scrum».
Сразу оговоримся: проблема не в том, что Jira «плохая», просто на определенном масштабе команда, проект, продукт и бэклог перестают совпадать. И если система продолжает мыслить проектами, а организация уже живет продуктами, начинаются обходные решения.
Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.
Один продукт — много команд
Когда 15 команд делают 15 разных продуктов — никаких особых проблем не возникает. Jira в этой модели чувствует себя нормально: проект равен команде, границы понятны, процессы изолированы.
Но как только все команды начинают работать над одним продуктом или общей целью — ситуация резко усложняется. Появляется необходимость синхронизации, возникают зависимости, формируется общий приоритет и общий контекст. Что именно начинает ломаться?
Проект перестает быть границей команды
Первое, что обычно происходит — команды начинают надстраивать текущую модель. Появляется отдельный «межкомандный» проект: для бизнеса, для синхронизации, для «общих задач». С одной стороны, выглядит как нормальное решение. С другой — в этот момент начинает размываться базовая логика Jira.
Раньше все было понятно: проект — это место, где работает команда. Теперь проект — это еще и контейнер для синхронизации, и место для задач без явного владельца. Задачи начинают расползаться: часть остается в командных проектах, часть переезжает в «общий», часть дублируется.
В одной компании 12 команд работали над платформой. В Jira было 14 проектов — 12 командных, один «общий» для бизнеса и один для «разных задач».
Product Owner открывал утро с обхода четырех проектов, чтобы собрать картину. Sprint review проводили в Confluence, потому что собрать данные из Jira в единый вид можно было только вручную.
Новый разработчик на онбординге спрашивал: «А где мне смотреть задачи?» — и получал ответ из трех пунктов.
В этот момент проект становится уже не рабочей областью, а компромиссом: он одновременно пытается быть местом работы команды, витриной для бизнеса и слоем координации.
Единый бэклог появляется «рядом», а не становится центром системы
Scrum предполагает простую модель: один продукт — один бэклог — один Product Owner. Как только появляется несколько Product Owner’ов — их нужно синхронизировать, а это уже доп проблема.
На практике у каждой команды остается свой бэклог, а «единый» появляется где-то рядом — в отдельном проекте. Здесь всплывает конкретное техническое ограничение: задача не может одновременно находиться в двух проектах. И получается, что формально единый бэклог есть,а по факту он становится еще одним артефактом, который нужно синхронизировать с командными бэклогами.
Зависимости уходят из системы
Пока команд мало, зависимости можно держать в голове или обозначать связями между задачами. Когда команд становится много, зависимости начинают жить отдельно от системы: часть есть в Jira, часть — в комментариях, часть — в обсуждениях в мессенджерах.
Главная проблема уже не в самих зависимостях, а в том, что они перестают быть объектом управления. Их нельзя нормально приоритизировать, планировать и анализировать, если они живут в комментариях и договоренностях.
Product Owner теряет единую точку управления
Единый бэклог превращается в формальность — он вроде есть, но управлять им сложно. Product Owner вынужден либо работать в одном «общем» проекте, либо бегать по всем командным проектам — что снова делает процесс непрозрачным, а жизнь продуктовнера тяжелой.
В итоге роль Product Owner начинает распадаться: стратегический приоритет живет в одном месте, командное планирование — в другом, фактическое исполнение — в третьем.
Почему это происходит: конфликт моделей
На этом этапе обычно кажется, что проблема в настройках Jira: не тот workflow, не та структура проектов, не хватает плагина, нужно лучше договориться о правилах.
На самом деле корень проблемы глубже: Jira исторически хорошо работает в модели, где проект, команда и поток задач более-менее совпадают, но на масштабе одного продукта и множества команд эта связка распадается.
Организации уже нужна продуктовая модель:
продукт → модули → команды → зависимости → релизы → общий бэклог
А система продолжает опираться на проектную модель:
проект → задачи → доска → workflow
Поэтому проблема не в том, что Jira не умеет хранить задачи: она-то умеет, вот только задача перестает быть достаточной единицей управления.
Jira + Advanced Roadmaps: помогает, но не решает корень проблемы
Advanced Roadmaps помогает визуализировать планы, зависимости и общую картину, но сам по себе не меняет базовую модель данных. Если внизу остаются разрозненные проекты и командные бэклоги, визуализация не превращает их в единую продуктовую систему. На практике это выглядит так: Advanced Roadmaps показывает красивую timeline, но если задача переехала из одного проекта в другой, связи теряются. Если команда переименовала эпик, roadmap его не узнает. Если зависимость добавили через комментарий — на timeline ее нет.
Для LeSS это еще можно собрать относительно компактно, потому что модель проще. В SAFe появляется больше уровней: portfolio, value stream, ART, teams. Если эти уровни не являются полноценными сущностями в системе, их приходится имитировать полями, проектами, связями и плагинами.
Корень проблемы один: в Jira нет понятия «продукт» как отдельной сущности. Есть проекты, есть задачи — но нет точки, где все это собирается в единую иерархию. Из-за этого построить структуру, которую требуют SAFe или LeSS, можно только через обходные решения: BigPicture, сторонние плагины, ручные связи между проектами.
Что с этим делать?
Первый порыв — поставить ещё один плагин или завести ещё один проект. Не надо. Проблема не в настройках.
— У нас 14 проектов в Jira на один продукт. Может, объединим в один?
— А кто будет владельцем?
— Product Owner.
— Какой из трёх?
— ...
Развести понятия «команда», «проект» и «продукт»
Пока они смешаны — любая структура держится на договорённостях. Команда — это люди. Проект — это контейнер для задач. Продукт — это то, что видит пользователь. В Jira все три сущности запихнуты в одну — «проект». Отсюда и хаос.
Сделать продукт верхним уровнем управления
Не меткой в задаче, не названием в Confluence, а отдельной сущностью — точкой, где собираются цели, модули, бэклог, зависимости и релизы. Если Product Owner утром открывает четыре проекта чтобы собрать картину — продукта как сущности в системе нет.
Вывести зависимости из комментариев
Если зависимость живёт только в чате или в комментарии к задаче — она неуправляема. Её нельзя приоритизировать, нельзя привязать к релизу, нельзя увидеть на timeline. Зависимость должна быть объектом, а не текстом.
Не лечить модель только плагинами
Плагины могут помочь с визуализацией, но они не решают конфликт базовой модели. Если данные продолжают жить в разрозненных проектах, любой roadmap становится красивой надстройкой над хаосом.
Проверить систему на масштабирование не по числу задач, а по числу связей
На масштабе ломается не хранение задач — с этим Jira справляется. Ломается управление связями: между командами, бэклогами, релизами, целями и ответственными. Если эти связи держатся на людях а не на системе — они рвутся при первом увольнении или отпуске.
Как мы смотрим на это в SimpleOne SDLC
Мы в команде SimpleOne SDLC смотрим на эту проблему через продуктовую модель. То есть считаем, что система управления разработкой должна отражать не только задачи команд, но и сам продукт: его структуру, зависимости, релизы и связь с другими процессами. Поэтому для нас масштабирование Scrum — это не столько вопрос «какую доску настроить», сколько вопрос того, какие сущности лежат в основе системы.
Главное отличие такого подхода — в том, что основой становится продукт, а не проекты. Если взять тот же сценарий из статьи — один продукт и 10–15 команд, то в классической модели обычно появляются обходные решения: общий проект, дублирование задач, ручная синхронизация.
В продуктовой модели это выглядит иначе: у продукта есть единый бэклог, из которого задачи распределяются по командам, но при этом не теряют связь с продуктом. За счет этого сохраняется общая картина: видно, что именно делается в продукте, какие есть зависимости и как формируется релиз.
Это снимает сразу несколько типичных проблем:
не нужно дублировать задачи между проектами;
зависимости остаются внутри системы, а не в комментариях;
Product Owner работает с целостным бэклогом, а не собирает его вручную.
Команды при этом продолжают работать в привычной логике Scrum или Kanban — меняется не их процесс, а уровень, на котором собирается управление.
Если коротко: мы просто убрали «проекты как основу» и сделали основой продукт.
Резюме
Jira начинает «ломаться» на масштабе не потому, что плохо справляется с задачами. С задачами как раз все обычно в порядке. Проблема начинается там, где организация пытается управлять продуктом через структуру проектов.
Пока одна команда делает один продукт, это почти незаметно. Но когда над одним продуктом работают 10–15 команд, появляются уровни, которых task tracker сам по себе не видит: общий бэклог, продуктовая иерархия, зависимости, релизные контуры, единая приоритизация.
Поэтому вопрос не в том, как еще хитрее настроить Jira. Вопрос в том, какая модель управления разработкой нужна компании на этом масштабе.
***
Сколько проектов в вашей Jira работают на один продукт? И сколько из них Product Owner реально просматривает каждый день?