Джира в России осталась, но в очень нелегальном состоянии. 4 года назад Атлассиан ушёл из РФ, а 30 марта закрыли продажи on-premise версий для дата-центров. В 2029 году снимаются с поддержки все локальные версии.
При этом 70% компаний всё ещё сидят на неподдерживаемых версиях Jira, Confluence и Trello.
Это не малый бизнес, который не захотел успел разобраться, а гиганты с выручкой от 2 млрд рублей. Люди, которые управляют этими компаниями, прекрасно понимают ситуацию. И всё равно не уходят.
Потому что это годами настроенные рабочие процессы, тысячи задач в системе и команды, которые не хотят переучиваться. Больше половины бизнесов оценивают срок миграции в 1—2 года. С таким горизонтом легче решить, что «всё равно пока не горит».
А уже горит.
С 15 февраля 2024 Jira Server перестала поддерживаться — больше никаких апдейтов безопасности. Если вы пускаете снаружи людей без дополнительной прослойки типа корпоративного тоннеля или NGFW — остаётся спорить, создаёт ли Джира дыру в системе или ей является. Крякнутые версии тоже под вопросом относительно бэкдоров.
Atlassian Marketplace заблокирован для РФ — плагины и интеграции с другим софтом отваливаются все эти годы.
Для госкомпаний, компаний с госучастием, субъектов КИИ (Критическая информационная инфраструктура) и банков законодательно были чёткие сроки перехода на отечественное ПО. Jira прямо нарушает директивы ФСТЭК, Минцифры и указы Президента РФ.
Есть сложности с аудитами и проверками — если планируется сделка или сертификация, проверку получится пройти только с серьёзными замечаниями.
Админов по Джире всё меньше, а поддержка по мере разваливания стека всё нужнее.
Как все подсели на эту иглу
В 2010-х корпоративный мир узнал, что такое Agile, Scrum и спринты одновременно. Jira оказалась в нужное время в нужном месте и стала стандартом среди таск-трекеров. Если компания работает по Agile — значит, у них Jira. Это не обсуждалось, это просто подразумевалось.
Прошло 10 лет. Среди людей, которые реально лезли в настройки Jira, я крайне редко встречал тех, кто считал бы её удобной. Обычно это описывали как «грёбаный ад». Потому что Jira устроена нелинейно. Она очень модульная, и нужно держать в голове, как именно эти модули вкладываются друг в друга.
Типичная ситуация: нужно настроить проект в company-managed формате и собрать для него доску. На первом шаге создаётся сама доска, но этого мало. Чтобы она начала работать так, как ожидает команда, дальше приходится отдельно настраивать воркфлоу со статусами и переходами, связывать его с проектом, а затем возвращаться к настройкам доски и сопоставлять колонки со статусами.
И только после всего этого карточки начинают двигаться так, как задумано. Каждый шаг — в отдельном разделе, каждый раздел — своя логика. Для опытного Jira-админа это рутина, а для нового человека — кошмар.
При этом всё, что нельзя было сделать штатными средствами, закрывалось через плагины. Jira открыла API сторонним разработчикам, и те стали делать аддоны, закрывая свои локальные боли. ScriptRunner здесь не «отдельный язык программирования», а популярный app для Jira, который даёт скриптинг и автоматизацию на базе Groovy.
То есть в какой-то момент в компаниях появился отдельный человек — Jira-разработчик, который пишет скрипты под конкретный инструмент. Не продукт разрабатывает, не бизнес двигает. Просто сидит и поддерживает систему управления задачами.
Именно здесь начинается история настоящего прорастания. За 10—15 лет компании выстроили в Jira настолько сложные управленческие контуры, что перенести их один в один почти невозможно. Jira оказывается связана с CI/CD-конвейерами, базами знаний в Confluence, корпоративными порталами, ERP-системами и внутренними интеграциями. Попытка вытащить одно звено из этой цепи грозит обрушить всю остальную конструкцию.
И когда на собеседовании спрашивают, умеете ли вы работать в Jira, — это реально весомая строчка в резюме. Потому что быстро объяснить Jira не получится. Даже сейчас инструмент, который официально мёртв для российского рынка, мелькает в вакансиях.
Пару лет на переезд — это не преувеличение
Компании продолжают торчать на Jira, потому что о переезде страшно даже думать. Технически импорт задач — вообще не главная проблема. У нас в Кайтене, например, есть универсальный импорт: нажал кнопку, и данные, включая все комментарии, историю и часть кастомных полей, переехали. Но миграция всё равно может занимать до 12—24 месяцев.
Возьмём среднюю корпорацию. У неё в Jira лежат десятки проектов с сотнями полей. Причём никто толком не помнит, зачем нужно большинство из них. Ко мне как-то пришла компания с запросом на миграцию и сказала перенести 100 полей только из одного проекта. В итоге выяснилось, что реально используются из них около десятка. Кому нужны остальные — никто уже не знал.
Зато все боятся что-то выбросить, потому что потом обязательно придёт кто-нибудь и скажет: вы удалили моё поле, и мы потеряли что-то важное.
Переезд — это в первую очередь организационный вопрос. Сначала нужно провести аудит: что вообще используется, как устроены процессы, какие данные критичны. Это занимает время. Потом очистить данные: разобрать задачи из бэклога 2017 года, архивные проекты и остальной мусор. А потом — переобучить людей, и это самый тонкий момент.
У сотрудников годами формировались нейронные связи: куда жмать и где искать. А мозг очень не любит перестраивать привычки — это энергетически дорого, и он будет сопротивляться до последнего. Когда компания меняет инструмент, она первые два месяца живёт в режиме повышенной тревоги. Всё непривычно, что-то не находится с первого раза, люди раздражаются. Это нормально. Но кто-то должен заранее объяснить команде, что так будет и что это временно.
Пока всё это происходит, команды забирают время у рабочих задач и тратят его на переезд. Это и есть главный риск — не потеря данных, а потеря производительности на переходный период. Поэтому многие компании выбирают оставаться на серой Jira.
Иллюзия стабильности
После ухода Jira в 2022 российские компании стали покупать лицензии через посредников или зарубежные юрлица. Формально это называется «работаем в правовом поле». Фактически — это слон в комнате.
Во-первых, так Jira обходится дороже современных российских решений. Посреднические схемы стоят денег, серверная инфраструктура тоже. А Jira-администраторы в крупных корпорациях — это команды с зарплатами на уровне сеньор-разработчиков. В сумме всё это оказывается дороже перехода. А фактическая стоимость владения Jira может оставаться в тени.
Другой нюанс — облачные аккаунты. Если компания решила не мучиться с серверной версией и перешла на облачную Jira через VPN и зарубежное юрлицо — она находится в режиме постоянного риска.
Atlassian может заблокировать аккаунты российских пользователей так же, как Claude, ChatGPT и другие. Один сотрудник спросонья забыл включить VPN и зашёл в систему напрямую, его IP определился как российский. Второй сделал то же самое. Atlassian видит паттерн и может блокнуть.
Серверная Jira без поддержки не ломается в один день, но постепенно превращается во всё более хрупкую систему.
Плагины, которые раньше закрывали недостающий функционал, перестают получать обновления и исправления. Они завязаны на совместимость с конкретными версиями Jira, Java, API и зависимостей.
Когда ядро больше не обновляется, а вокруг него остаётся набор старых приложений, кастомизаций и интеграций — растёт риск конфликтов, ошибок и проблем, которые для пользователей выглядят как «мистика».
Я знаю реальный кейс: одна и та же компания, один и тот же набор данных, одна и та же задача — собрать спектральную диаграмму по потоку и посмотреть процентили. Поставили два плагина. Оба работают с одними и теми же данными — и оба показывают разные результаты. И дальше вопрос уже не в статистике, а в доверии к инструменту: если два расширения по-разному считают одно и то же, на что опираться в управленческих решениях?
Плюс к этому Atlassian официально объявил, что к 2029 году полностью перестанет поддерживать серверную версию. Она легко взламывается, есть на всех торрентах и не приносит им прибыли. Всех пользователей будут переводить в облако.
Для российских компаний на серверных версиях это финальная точка. У тех, кто дотянет до этого момента без миграции, будет экстренный переезд со всеми вытекающими.
Как выглядит нормальный переход
Переезд — это не значит, что вся компания одновременно бросает Jira и переходит в новую систему.
Нормальный переезд выглядит иначе. Сначала компания проводит аудит: что реально используется в Jira, какие процессы критичны, какие данные нужно обязательно перенести, а от какого хлама давно пора избавиться.
Потом выбирают пилотную команду — не самую крупную и не самую консервативную, а достаточно самостоятельную, чтобы работать относительно изолированно от остальных. Это «команда-чемпион»: она первой переезжает на новый инструмент, пробует его на практике и становится живым доказательством для скептиков, что переезд возможен и не убивает производительность.
Пока пилотная команда работает в новой системе, остальные продолжают в Jira. Никаких одновременных остановок и пожаров в процессах. Потом, когда пилот признают успешным — едет следующий отдел. И так до конца по несвязанным между собой подразделениям.
Здесь важна ещё одна вещь, которую обычно недооценивают. Переезд — это смена парадигмы. В Jira компании строили свои уникальные конструкции из доступных блоков, подгоняя систему под себя с помощью ScriptRunner'ов и плагинов. В современных инструментах методология уже заложена внутри.
То есть не нужно городить схемы, чтобы получить диаграмму потока — она есть из коробки. И не нужен отдельный разработчик, чтобы настроить автоматизацию, это делается через интерфейс.
Психологически это самый трудный момент. Люди приходят с запросом «перенесите нам всё так же, как было в Jira, только в новой системе». Но так почти не работает. Это как переехать в новую квартиру и требовать, чтобы все розетки были на тех же местах, а дверные ручки такой же формы. Часть привычек придётся отпустить.
Взамен компания получает не «ещё одну копию Jira», а рабочую среду, где часть вещей, ради которых раньше приходилось ставить отдельные плагины и поддерживать их совместимость, уже доступна внутри самого продукта.
То есть не нужно отдельно городить плагины, чтобы получить, например, спектральную диаграмму — в Kaiten она есть как встроенный отчёт. И во многих сценариях не нужен отдельный разработчик, чтобы настроить автоматизации. Для этого есть простые механики и настраиваемые правила через интерфейс.
Что в итоге
В последние годы я видел десятки историй переезда с Jira в Kайтен и хорошо понимаю, как это обычно устроено на практике. Переезд с насиженной Jira в наших реалиях — это уже не выбор в наших реалиях, а вопрос времени. И это в первую очередь перемена организационная.
Руководителям придётся наконец задать себе вопрос: а нам точно нужна именно Jira? Или просто нужен инструмент, в котором команды будут нормально работать?
Иногда складывается ощущение, что управленческий фокус в компании незаметно смещается. Вместо того чтобы думать, как зарабатывать и улучшать процессы, менеджеры начинают думать, как ещё удобнее настроить Jira.
И это, пожалуй, самый тревожный сигнал — система управления постепенно становится важнее задач, ради которых она вообще существует.
Сейчас у большинства компаний некоторое окно возможностей. Можно выбирать неторопливо, пилотировать, сравнивать, ошибаться в небольших масштабах и исправлять. Те, кто начинает этот процесс сегодня, придут к 2029 году с готовой системой и командами, которые уже умеют в ней работать.
Те, кто выберет ждать до последнего, — рискуют разгребать последствия замороженных аккаунтов и потерянных данных. В целом, если вы планируете уволиться до 2029 года — наверное, стратегия имеет смысл, потому что переезжать всегда тяжело. Но если вы вдруг собственник, CTO или просто планируете вдолгую — обратите внимание )