Крупные компании используют Jira по привычке — инструмент создавали для небольших команд, но его пытаются применять и в энтерпрайзе. Если вы управляете масштабными продуктами и используете масштабированные фреймворки (SAFe, LeSS и другие), вам нужны специализированные решения, и Jira с этим не справляется.
Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Внедрял гибкие методологии в различных компаниях — от 50 до 1000 человек. В нескольких из них ускорил выпуск новой функциональности в четыре раза, что помогло компании адаптироваться под сложный рынок. Работал с Jira как администратор, настраивал её для получения статистики по командам. Сталкивался с ограничениями этого решения и в маленьких компаниях, и в крупных.
Сейчас, развивая SimpleOne SDLC, наблюдаю, как компании сокращают время выпуска функциональности в два раза за счет решения больших проблем Jira. При этом повышается удовлетворенность сотрудников, потому что команда видит продукт и лучше понимает, что делает. Мотивация растет, так как разработчики создают ценность для пользователей, а не просто штампуют фичи.
В статье — подробнее о наших наблюдениях за компаниями, сидящих на Jira, и как мы развиваем продукт, который решает фундаментальные ограничения легендарной системы.
В чём проблема Jira
Мы собрали аналитику на основе нескольких десятков внедрений SimpleOne SDLC в крупном бизнесе. Выявили несколько основных проблем Jira, с которыми сталкиваются компании:
85% сталкиваются с тем, что нет единой ценности — никто не понимает, что делать
60% сталкиваются со сложностями приоритезации и определения, что правда важно;
70% сталкиваются с проблемами при синхронизации нескольких команд;
30% сталкиваются с тем, что Jira сложно подстроить под себя;
30% сталкиваются с тем много плагинов, которые не синхронизируются между собой;
60% сталкиваются со сложной интеграция инцидентов с процессом разработки.
Рассмотрим каждую проблему подробнее.
Нет единой ценности — никто не понимает, что делать
Будем честными: для нового сотрудника самое важное — начать работать или разобраться с проблемными местами. Разработчику нужно понять код, практики, которые используются в команде. Разобраться с ценностью продукта для прохождения испытательного срока обычно не так критично, этому уделяют меньше внимания. И Jira никак не способствует тому, чтобы команда разработки понимала ценность продукта.
В Jira есть только проект, в котором ведутся задачи, при этом нигде не прописано, что за продукт разрабатывается. Информация может быть в Confluence или Miro, но у сотрудника нет единой точки входа — когда человек приходит в компанию, он анализирует десятки файлов.
Продуктовый подход, который мы реализовали в SDLC, как раз дает эту точку входа. Вместо проекта с тасками — продукт с прописанной ценностью. Сразу видно, как работают команды, на чём специализируются. Разработчик понимает контекст при решении задач. Например, если разрабатывается высоконагруженная система, об этом легко забыть при написании кода. Когда разработчик регулярно заходит через продукт и взаимодействует с его описанием, у него формируется понимание — высоконагруженная система требует больше заботы о техническом долге.
Что такое «Продукт» в SimpleOne SDLC
Продукт — это основа, вокруг которого уже строятся команды, проекты, процессы. В SimpleOne это не просто папка с задачами, а полноценная сущность со своими характеристиками:
описание ценности и целевой аудитории;
модули для детализации функциональности (можно создавать бесконечно вложенные структуры);
единый бэклог, из которого команды берут задачи;
связь с релизами и интеграцией с системами контроля версий;
метрики и отчетность по продукту.
Продукт объединяет все команды, которые над ним работают. Команда видит не только свои задачи, но и общую картину: зачем разрабатываем функциональность, кому она нужна, как вписывается в продукт.
Отличие от других подходов: продукт — это ответ на вопрос «что мы делаем и зачем», а проект — «как делаем и в какие сроки».
В Jira сложно понять, что важно
Проблема вытекает из первого пункта. В Jira слишком много документов для понимания того, что разрабатывается.
Недавно мы обсуждали эту проблему на «Мы обречены»: когда приходишь в компанию, первое время долго ищешь команд-доску. Не то чтобы долго разбирался, какой продукт делаешь — просто анализируешь большое количество проектов.
В крупных компаниях их может быть 20+. Приходится идти к руководителю или скрам-мастеру, чтобы он нашёл проект. Потом сохраняешь ссылку в избранное и стараешься не терять её. Каждый раз при устройстве нужно заново понимать структуру проектов, их задачи, и из-за отсутствия единой ценности компании сложно онбордить новых людей.
В маленьких компаниях, где 2–3 проекта, это не проблема. Заходишь в список проектов — разбираешься быстро. В крупных компаниях под каждую команду или направление создается проект. Когда команд 30, нужно понять, в какую входишь, какое у неё название, куда переходить.
Как SimpleOne решает проблему
Портфель продуктов — центральная точка входа. Заходишь в систему, видишь список продуктов компании. Выбираешь свой, попадаешь на страницу продукта с описанием, командами, бэклогом. Оттуда переходишь в проект своей команды.
Путь стал короче: раньше «список проектов → поиск нужного проекта → доска», теперь «портфель продуктов → продукт → проект команды → доска». Да, звучит как дополнительный шаг, но продукт — это навигация, а не препятствие. Ты сразу понимаешь контекст.
Дополнительно помогает типизация задач и продуктовая иерархия: эпики, фичи, истории, дефекты. Приоритизация задач идёт на уровне продукта, команды берут уже приоритизированный бэклог. Не нужно гадать, что важнее — продакт-менеджер расставил приоритеты.
Сложно синхронизировать команды
Представим ситуацию из страховой компании. Есть отдел Discovery — люди в галстуках и пиджаках придумывают задачи. Например, решили внедрить КАСКО для электромобилей. Работают в своем проекте, создают большую задачу. Потом её нужно декомпозировать, потому что для внедрения требуется работа трёх разных команд.
Декомпозируем задачу — один эпик на команду «Машина» (она соединяет все команды), две другие задачи на портал для пользователей и внутренний портал для администраторов. Получается: один проект для бизнеса, потом проекты для трёх команд, и всё это нужно как-то синхронизировать.
Между задачами должна быть либо горизонтальная связь, либо иерархия. Тут всё рушится — становится сложно. Бизнес поддерживает свою задачу, не опускается в задачи команд. Командам приходится подниматься в задачу выше, чтобы разобраться, что в целом нужно сделать. Переходить между проектами неудобно и сложно.
Как SimpleOne решает проблему синхронизации
Общий проект превращается в продукт. В нашем примере бизнес-отдел завёл бы эпик «КАСКО для электромобилей» в бэклог продукта «Страховые продукты». Потом декомпозировал бы эпик на фичи и назначил бы фиче команду.
Так команда «Машина» видит свою фичу в бэклоге продукта, берёт её в спринт. Открывает фичу — видит связанные задачи других команд, понимает зависимости. Автоматизация подтягивает важные поля из родительского эпика: описание бизнес-ценности, сроки, критерии приёмки.
Структура становится плоской:
продукт «Страховые продукты» (с описанием, что продаём и кому);
бэклог продукта (эпики и фичи);
проекты команд (команда «Машина», команда «Портал», команда «Админка»);
доски команд с задачами из бэклога продукта.
Модули продукта помогают структурировать большие продукты. Например, продукт «Страховая платформа» содержит модули «ОСАГО», «Каско», «Недвижимость». Каждый модуль — мини-продукт со своим бэклогом, но всё живёт в рамках одного большого продукта. Команды видят, как их модуль связан с другими.
Тяжело подстроить под себя
Jira создавалась как таск-трекер — простой инструмент для ведения задач. В нишу разработки ПО Atlassian пришли уже позже. Базовая функциональность Jira действительно покрывает простые сценарии, но для сложных процессов приходится много настраивать.
Основная проблема в ограничениях архитектуры, например, в Jira есть области интерфейса, куда нельзя добавлять кастомные поля. Даже при доработках форма задачи выглядит определённым образом — жёсткая структура не позволяет менять визуал под потребности команды. Если вы захотите, допустим, добавить виджет с графиком загрузки команды прямо в карточку задачи — нельзя, Jira предусматривает только поля. Нужна кастомная панель с метриками по спринту на доске — придётся искать плагин или писать самим.
Как SimpleOne решает проблему кастомизации
SimpleOne SDLC построен на Low-code платформе. Можно менять почти всё: добавлять поля куда угодно, создавать кастомные виджеты, менять визуал форм и досок. Благодаря такой архитектуре можно настраивать систему без программистов.
Нужно добавить новый тип задачи с особым процессом — создаёте через конфигуратор. Хотите виджет с метриками по техдолгу на главной странице продукта — собираете его из компонентов.
Многие наши заказчики полностью перепиливают продукт под себя, и это нормально. Low-code позволяет адаптировать систему под любые процессы. Можно даже удалить сущность «Продукт», если команда решит, что продуктовый подход им не нужен. Тогда SimpleOne SDLC превращается в гибкий таск-трекер, похожий на Jira, но с большими возможностями кастомизации.
Много плагинов, которые не синхронизируются
Плагины — одновременно сила и слабость Jira. С одной стороны, экосистема плагинов решает почти любую проблему. Нет функциональности для планирования времени — ставьте Tempo. Нужна диаграмма Ганта — устанавливайте Structure. Не хватает отчётности — есть десятки плагинов для аналитики.
С другой стороны, плагины живут своей жизнью. Разработчики разные, мотивации интегрироваться между собой нет. В результате компании делают двойную работу вручную. Реальный пример из моего опыта в страховой компании: бизнес-отдел планировал задачи в Structure — удобно группировать, смотреть зависимости, строить план. Потом нужно было спланировать загрузку людей. Но Tempo не читает данные из Structure. Приходилось идти в Tempo и на каждого человека планировать задачи заново. Двойная работа, которая отнимает часы каждую неделю.
Другая проблема — российские реалии. Не все плагины можно купить официально, приходится искать обходные пути или ставить взломанные версии, что не совсем легально. Даже если плагин был куплен раньше, обновления и поддержка часто недоступны. Jira в России сейчас работает без официальной поддержки Atlassian — если что-то сломается, обращаться некуда.
Как SimpleOne решает проблему плагинов
SimpleOne — платформенное решение. Все модули работают на единой платформе и могут полноценно интегрироваться друг с другом. Платформа включает инструменты для работы со временем (учёт трудозатрат), планирования (спринты, итерации, бэклог), отчётности (Burndown, CFD, диаграммы времени производства). Всё нужное для полноценного управления разработкой в крупной компании есть в базовой поставке.
Сложная интеграция инцидентов с процессом разработки
Разработка и поддержка часто живут в разных мирах. Разработчики работают в Jira, служба поддержки — в Service Desk (если повезло) или в отдельной ITSM-системе вроде ServiceNow, Zendesk или российских аналогов.
Когда пользователь сообщает об ошибке, создаётся инцидент в системе поддержки. Если инцидент нужно исправить в коде, кто-то вручную создаёт задачу в Jira. Потом нужно связать инцидент и задачу, синхронизировать статусы, следить за обновлениями в двух системах одновременно.
Компании пишут интеграционные скрипты между ITSM и Jira. Скрипты ломаются после обновлений, требуют поддержки, не покрывают все сценарии. Информация теряется на стыках — непонятно, кто отвечает за задачу, какой приоритет, когда будет исправление.
Ещё хуже с техдолгом. Если один и тот же инцидент повторяется регулярно, это сигнал — нужно исправлять причину, а не симптом. В идеальном мире служба поддержки находит повторяющиеся инциденты, создаёт проблему, передаёт в разработку. На практике инциденты накапливаются, никто не анализирует паттерны, команда тушит одни и те же пожары месяцами.
Как SimpleOne решает проблему интеграции
SimpleOne ITSM и SimpleOne SDLC работают на одной платформе и используют единую объектную модель. Инциденты, запросы на обслуживание, задачи, дефекты — всё это сущности одной системы.
Сквозные процессы ITSM в управлении разработкой:
формирование техдолга — повторяющиеся инциденты автоматически попадают в базу известных ошибок (KEDB). Продакт-менеджер видит статистику, приоритизирует дефекты на основе количества обращений;
приоритизация задач — можно учитывать данные из ITSM при планировании спринта. Видно, сколько инцидентов связано с конкретной функциональностью, какие проблемы критичны для бизнеса;
доступность сущностей — в карточке задачи видны все связанные инциденты, запросы на обслуживание, изменения. Не нужно переключаться между системами;
сквозные уведомления — когда разработчик закрывает дефект, система автоматически уведомляет службу поддержки и обновляет статус связанных инцидентов;
согласование релизов — новая версия продукта оформляется как запрос на изменение в ITSM. Проходит процесс согласования, планируется внедрение, минимизируются риски.
Почему SDLC-система выигрывает у Jira в крупных компаниях
Все описанные выше проблемы особенно болезненны для компаний, которые внедряют SAFe (Scaled Agile Framework) — методологию масштабирования Agile на уровень энтерпрайза. SAFe требует координации десятков команд через PI-планирование, чёткую иерархию продукт → фичи → задачи команд, синхронизацию через единый бэклог.
С учётом описанных проблем, когда компания пытается реализовать SAFe в Jira, начинаются мучения: сложные структуры проектов, автоматизация через плагины, многомесячное внедрение. В России добавляется проблема с покупкой и поддержкой плагинов для SAFe.
SimpleOne SDLC изначально проектировался для крупных компаний и естественным образом поддерживает паттерны работы, необходимые для SAFe:
Продуктовая иерархия из коробки
Портфель продуктов → продукт → модули продукта → бэклог → проекты команд. Не нужно строить структуру из проектов — архитектура уже заточена под координацию множества команд вокруг продуктов.
Две итерации для PI-планирования
SAFe требует итерацию на уровне PI (Program Increment) и итерацию на уровне команд (спринты). В SimpleOne продакт-менеджер приоритизирует бэклог продукта для PI, команды берут фичи на PI-планировании, внутри проектов разбивают на задачи и планируют спринты. Всё работает без плагинов и костылей.
Agile Release Train через модули
Крупные продукты структурируются модулями. Agile Release Train работает над модулем, несколько команд внутри поезда синхронизируются через бэклог модуля. Зависимости видны, приоритизация прозрачна.
Подытожим
Когда вы выбираете инструмент для управления разработкой в энтерпрайзе, подумайте: хотите систему, которая работает из коробки, или готовы тратить месяцы на допиливание и поиск обходных путей?
Действительно, популярную Jira можно адаптировать и под крупную компанию — через плагины, кастомные скрипты, многоуровневые структуры проектов. Но вы будете постоянно бороться с архитектурой, которая для этого не предназначена. Добавили новую команду — перенастраивайте связи. Изменился процесс — правьте автоматизацию. Обновили Jira — проверяйте, что не сломалось.
SimpleOne SDLC создавался для крупных компаний и SAFe. Продуктовая иерархия, координация команд, интеграция с поддержкой — всё это заложено в архитектуру. Не нужно искать плагины, писать интеграции, объяснять администратору, как связать 30 проектов. Система понимает, как работают enterprise-компании, и поддерживает эти паттерны изначально.
Выбирайте инструмент под задачу, а не пытайтесь натянуть решение для маленьких команд на масштабную разработку.
***
Расскажите, сталкивались ли вы с ограничениями Jira в своей работе?