Своя Jira или облачная подписка: где ломается экономика на 30 разработчиках

MAATRIX

Когда в отделе разработки 30 человек, счёт за Jira Cloud уже заметен в бюджете, а финдиректор рано или поздно спросит: «а если поднять своё?». Ответ не сводится к «да» или «нет» — он зависит от того, сколько стоит у вас час админа, насколько команда готова терпеть шероховатости open-source трекера и что вы теряете при переезде из экосистемы Atlassian. Разберём расчёт по шагам, без готового вердикта — с методикой, которую вы примените к своим цифрам.

Что именно мы считаем и почему 30 разработчиков — показательная точка

30 человек — это уже не стартап на пять человек, где Jira Free или дешёвый Standard-тариф не создают проблемы, но и не корпорация на 300+, где self-hosted решение почти неизбежно из-за требований безопасности и комплаенса. Это ровно та зона, где решение неочевидно и упирается в конкретную арифметику вашей компании, а не в общие лозунги «облако дороже» или «свой сервер — головная боль».

Мы будем считать два потока расходов на дистанции 12 и 36 месяцев:

• Подписка: цена за пользователя в месяц × число пользователей + доп. приложения из маркетплейса + рост тарифа при масштабировании.
• Self-hosted: аренда сервера + время на установку и настройку + постоянное администрирование (обновления, бэкапы, инциденты) + миграция данных при переходе.

Важная оговорка сразу: числа ниже — иллюстративные, чтобы показать методику расчёта. Точные тарифы Jira Cloud на конец августа 2026 года нужно смотреть на сайте Atlassian в момент расчёта — они меняются, зависят от валюты выставления счёта, скидок за годовую оплату и набора приложений, которые использует именно ваша команда.

Как устроена стоимость подписки на Jira Cloud

Тарифная модель Atlassian исторически строится по принципу «цена за пользователя в месяц, ступенями по уровню тарифа»: базовый уровень дешевле, но ограничен по функциям (автоматизации, права доступа, аудит), более дорогой уровень снимает эти ограничения. При росте числа пользователей цена за одного человека может как оставаться плоской, так и меняться порогами — это тоже нужно проверять в актуальном прайсе, а не в старых скриншотах из интернета.

Введём переменные, чтобы посчитать не приблизительно, а по формуле:

P  — цена за пользователя в месяц (по вашему актуальному тарифу)
N  — число пользователей (в нашем случае 30 разработчиков)
A  — сумма за платные приложения из Atlassian Marketplace в месяц
    (доски, тайм-трекинг, интеграции с CI/CD, кастомные поля и т.п.)

Месячный счёт = P × N + A
Годовой счёт  = (P × N + A) × 12

На практике A часто оказывается недооценённой статьёй: команда из 30 разработчиков редко обходится голой Jira — добавляются плагины для диаграмм зависимостей, для интеграции с GitLab или GitHub, для более гибких отчётов. Каждое такое приложение тоже тарифицируется за пользователя или фиксированной суммой в месяц, и на дистанции года это может добавить существенный процент к базовому счёту.

Ещё один момент, который часто упускают: при росте команды с 30 до 50–80 человек стоимость растёт линейно (а иногда — с переходом на более дорогой тариф из-за лимитов Standard-плана), в то время как затраты на self-hosted сервер растут гораздо более полого, пока не упрётесь в реальный потолок производительности.

Что нужно, чтобы поднять self-hosted трекер задач самостоятельно

Прямого open-source клона Jira с идентичным функционалом не существует — но для трекинга задач, спринтов и бэклога закрывают потребность зрелые open-source альтернативы, прежде всего Plane и Taiga. Мы подробно сравнивали Plane и Taiga — коротко: Plane ближе к современному UX (Kanban, циклы, модули, неплохой API), Taiga чуть более консервативна, но обе закрывают базовый сценарий «доска задач + спринты + бэклог + отчёты».

Что вам понадобится по факту:

1. Сервер. Для команды в 30 человек с активной работой (создание задач, комментарии, вложения, вебхуки из CI) с запасом хватает конфигурации в диапазоне 4 vCPU / 8 ГБ RAM для связки Plane (Postgres + Redis + очереди задач + сам бэкенд/фронтенд в Docker Compose). Это ориентир для старта, а не измеренный бенчмарк — при активном использовании вложений (скриншоты, логи в задачах) стоит закладывать больше места на диск и следить за ростом базы.
2. Домен и TLS — заводится за 15–20 минут через Let's Encrypt, ничего специфического.
3. Установка. Разворачивается через Docker Compose буквально за один вечер — читайте нашу пошаговую установку Plane на VPS, там разобран весь путь от чистого сервера до рабочего инстанса.
4. Резервное копирование. Обязательно: снимок базы Postgres + volume с вложениями по расписанию, желательно с выгрузкой во внешнее хранилище — если сервер один и без бэкапа, вы меняете риск подписки на риск потери всей истории задач.
5. Мониторинг. Хотя бы базовый — алерт на недоступность сервиса и на заполнение диска. Без этого узнаете о проблеме от разработчиков, а не от системы.

Разовые трудозатраты на первичную настройку с бэкапами и минимальным мониторингом — обычно один-два полных рабочих дня опытного администратора, плюс время на перенос части данных из Jira (об этом — ниже, в разделе про компромиссы).

Время администратора — самая скрытая статья расходов

Главная ошибка при сравнении «подписка vs свой сервер» — посчитать только аренду VPS и забыть про труд человека, который будет это обслуживать. Именно эта статья чаще всего и определяет, где на самом деле лежит точка перелома.

Что регулярно требует времени после первичной настройки:

• Обновления. Plane и Taiga активно развиваются, minor-релизы выходят часто. Обновление self-hosted инстанса — это не всегда «нажал кнопку»: иногда нужно проверить миграции базы, совместимость плагинов, иногда — почитать changelog на предмет breaking changes.
• Инциденты. Диск заполнился, контейнер упал после перезагрузки хоста, сертификат не обновился автоматически — на подписке это забота Atlassian, на своём сервере — ваша, и происходит она в среднем несколько раз в квартал даже при аккуратной настройке.
• Бэкапы и их проверка. Настроить снятие бэкапа — 20 минут. Регулярно проверять, что из него реально восстанавливается рабочая система — отдельная привычка, без которой бэкап существует только на бумаге.
• Доступы и права. Онбординг и оффбординг сотрудников, настройка ролей — в облаке это пара кликов в админке, на своём сервере — тоже несложно, но требует вашего процесса, а не готового чужого.

Если оценивать это в часах, реалистичный ориентир для стабильно работающего инстанса на 30 пользователей — несколько часов в месяц в спокойном режиме, и заметно больше в месяц миграции, крупного обновления или инцидента. Дальше это нужно умножить на реальную стоимость часа вашего администратора — свою или подрядчика. Мы отдельно разбирали, как оценить стоимость часа админа и когда дешевле доплатить за готовое решение — рекомендуем прогнать через эту методику именно ваши цифры, а не общие прикидки.

Где на самом деле ломается экономика: считаем точку перелома

Соберём формулу. Месячные затраты на self-hosted:

C_server — аренда сервера в месяц
H        — часы администрирования в месяц (в среднем)
R        — стоимость часа админа (своего или подрядчика)

Месячные затраты self-hosted = C_server + H × R

Точка перелома по числу пользователей N* — это число, при котором подписка (P × N + A) сравнивается с затратами на self-hosted:

N* = (C_server + H × R) / P

Если ваше реальное N (в нашем случае 30) больше N*, self-hosted теоретически выгоднее по прямым деньгам. Если меньше — подписка обходится дешевле, даже с учётом её роста.

Подставим условный пример только для демонстрации методики (не берите эти цифры как актуальные тарифы):

Условно: P = 1000 ₽/польз./мес, N = 30
Подписка ≈ 30 000 ₽/мес (без учёта Marketplace-приложений)

Условно: C_server = 4000 ₽/мес, H = 6 часов/мес, R = 2500 ₽/час
Self-hosted ≈ 4000 + 6 × 2500 = 19 000 ₽/мес

N* = 19 000 / 1000 ≈ 19 пользователей

В этом иллюстративном примере точка перелома оказывается заметно ниже 30 — то есть при таких вводных self-hosted выгоднее уже для команды в 19+ человек. Но обратите внимание, насколько результат чувствителен к H и R: если администрирование отдано не выделенному специалисту, а разработчику, который тратит на это время вместо профильной работы, реальная стоимость часа R может быть кратно выше номинальной ставки админа — и точка перелома сдвинется обратно вверх, к 40–50 пользователям.

Отдельно стоит закладывать разовые затраты на миграцию — перенос задач, вложений, истории комментариев из Jira. Это не входит в месячную формулу выше, но в первый месяц перехода добавляет ощутимый объём работы, который логично разложить на несколько месяцев вперёд при принятии решения.

Компромиссы, которые не видны в Excel-таблице

Прямой расчёт в деньгах — только часть картины. Есть вещи, которые формула не учитывает, но которые реально влияют на решение:

• Миграция данных. У Atlassian нет официального прямого мигратора в Plane или Taiga. Экспорт из Jira обычно делается в CSV или через API, а на стороне self-hosted инструмента приходится вручную сопоставлять кастомные поля, статусы воркфлоу, связи между задачами. Для 30 разработчиков с многолетней историей в Jira это может быть несколько дней работы, а не «перенёс за час».
• Интеграции. Экосистема Jira огромна: готовые интеграции с Confluence, Bitbucket, десятками CI/CD и аналитических инструментов. У Plane и Taiga интеграций меньше, часть придётся собирать через webhooks и API самостоятельно — это дополнительная разработка, а не готовая кнопка.
• Обновления функциональности. Atlassian регулярно добавляет новые возможности как часть подписки — вы получаете их бесплатно. В self-hosted решении вы либо ждёте, пока фича появится в open-source проекте, либо реализуете нужное сами.
• Ответственность за аптайм. В облаке SLA и ответственность за доступность — на стороне провайдера. На своём сервере, если платформа легла посреди спринта, это ваша проблема и ваша скорость реакции — это тоже часть цены, просто не в деньгах, а в риске.
• Гибкость и контроль. В обратную сторону: свои данные не покидают ваш сервер, нет риска повышения цены подпиской в одностороннем порядке, нет ограничений тарифного плана — вы настраиваете ровно то, что нужно команде, без переплаты за неиспользуемые функции корпоративного тарифа.

Если ваша команда уже плотно завязана на экосистему Atlassian (Confluence для документации, Bitbucket для репозиториев, десяток настроенных автоматизаций), стоимость разрыва этих связей может перевесить прямую экономию на подписке. Если же вы используете Jira преимущественно как доску задач и трекер спринтов без глубокой интеграции — переход технически проще и предсказуемее по деньгам.

Частые вопросы