Привет! Меня зовут Анна, я архитектор Naumen Project Ruler. Я отвечаю за то, как устроена система: чтобы она соответствовала методологиям проектного управления, но при этом не оставалась «теорией из учебника». Мы проектируем Project Ruler достаточно гибким, чтобы он встраивался в реальные процессы разных компаний и учитывал разные подходы к управлению.

Анна

Архитектор решения Naumen Project Ruler

Откладывать дальше вопрос замены Jira уже не получится. Перспектива остаться без необходимого рабочего инструмента все ближе. Для компаний, которые до последнего держатся за Jira, есть вариант, купить готовое решение или разработать свое и больше никогда не оказаться в ситуации, подобной нынешней.

Первый вариант быстрее и проще — все готово, платишь и пользуешься. Правда, скорее всего придется пойти на компромиссы в привычных процессах, чтобы найти «общий знаменатель» между ними и возможностями решения. Кроме того, придется приготовиться к постоянным платежам за лицензии.

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

Что говорят исследования

Для начала посмотрим на имеющийся международный опыт. Дилемма «разрабатывать или покупать» многократно рассматривалась ведущими консалтинговыми компаниями. Вот примеры некоторых исследований.

Согласно  анализу, проведенному McKinsey & Company, крупные ИТ-проекты в среднем превышают первоначальный бюджет на 45%. При этом каждый шестой — более чем на 80%. Средний показатель отставания по срокам составляет 7%.

Ежегодные отчеты Standish Group (CHAOS Report), в которых проанализированы десятки тысяч ИТ-проектов по всему миру, демонстрируют стабильные показатели уже несколько десятилетий. Успешными признаются лишь около 30% проектов. К таковым относятся те, что были завершены в срок, уложились в бюджет и обеспечили заявленную функциональность. Спорными — около 50%. Это те, в которых сроки и бюджет превышены, а функциональность урезана. Наконец, провальными (отмененными до завершения или не используемыми после запуска) оказались около 20%. Проекты с бюджетом свыше $10 млн попадают в зону особого риска. Процент успешных среди них еще ниже. К примеру, доступны краткие обзоры отчета: 1, 2, 3.

Отчет Build vs. Buy: A Decision Framework for Software-Intensive Systems предлагает практический чек-лист из 10 ключевых вопросов. Но фактически, чтобы понять, имеет ли смысл разрабатывать продукт с нуля, достаточно ответить на три главных:

1. Является ли предполагаемая функциональность вашим конкурентным преимуществом?

2. Существуют ли готовые решения, покрывающие более 80% ваших потребностей?

3. Готовы ли вы к тому, что 70% затрат возникнут ПОСЛЕ запуска системы?

Если на первый вопрос ответ «Нет», а на второй и третий «Да», затевать собственный ИТ-проект не рекомендуется.

Исследования Gartner и Forrester Research сходятся в нескольких ключевых выводах. 70–80% ТСО программного продукта приходится на этап после запуска: доработки, обновления, техподдержку. Ежегодная стоимость владения кастомным решением составляет 15–25% от первоначальных затрат на разработку. На пятилетнем горизонте суммарные затраты на лицензии готового продукта составляют лишь 20–30% от совокупной стоимости владения собственной разработкой.

Источники:

• The Hidden Cost Of Code And Generative AI

• Custom vs Commercial Tools (Build vs Buy Analysis)

• Custom vs. Off-the-Shelf Software: Which Saves You More in the Long Run?

• The True Cost of Skipping Software Maintenance in 2026

• Custom vs Commercial Tools

• Total Cost of Ownership - IT Help Desk

А теперь перейдем к более конкретным цифрам и срокам, если вы решитесь разрабатывать аналог Jira с нуля или поймете, что сначала нужно оценить готовые варианты замены на рынке.

Вариант 1. Создаем свою систему для внутреннего использования

Предположим, цель — закрыть потребности собственной команды. На выходе вы хотите получить инструмент, способный заменить Jira в ключевых процессах: постановка задач, трекинг, базовое Agile-планирование. Первый релиз запланирован через 12 месяцев.

Как будут выглядеть этапы разработки

1–2 месяцы — проектирование. Сбор и формализация требований от команд, которые будут пользоваться системой. Проектирование модели данных — это фундамент, ошибки в котором потом исправляются годами и стоят очень дорого. На этом же этапе выбирается стек: язык программирования, база данных, архитектура.

3–6 месяцы — разработка ядра. Формирование серверной логики, проектирование API, выстраивание аутентификации, реализация базовых сущностей: задач, проектов, пользователей, статусов — всего того, без чего система не существует.

7–9 месяцы — проработка пользовательского интерфейса. Сборка Kanban‑доски с drag‑and‑drop, форм создания и редактирования задач, фильтров. Важно обеспечить стабильную работу при одновременном подключении десятков и сотен пользователей к одной доске.

10–12 месяцы — стабилизация и запуск. Производится нагрузочное тестирование, закрытие уязвимостей (OWASP Top 10 минимум), багфиксинг, настройка CI/CD, развертывание промышленного контура. Параллельно пишется хотя бы минимальная документация, чтобы команды могли начать работать.

ИИ‑ускорение заманчиво, но не бесплатно

Отдельно стоит сказать про соблазн ускорить разработку с помощью инструментов на базе искусственного интеллекта, через вайб‑кодинг. ИИ‑ассистенты действительно способны генерировать большие объемы кода за короткое время. На старте проекта это выглядит как способ сэкономить недели работы. Однако при создании промышленной системы возникают существенные риски.

Первая группа относится к информационной безопасности. При использовании ИИ контекст разработки отправляется во внешние облачные сервисы. Это плохо совместимо с корпоративными требованиями к защите кода и данных. Возникает риск утечки архитектурных решений и чувствительных фрагментов во внешний контур.

Вторая группа относится к качеству и чистоте кода. ИИ генерирует код, который работает «здесь и сейчас», но не учитывает общую архитектуру. Результат — противоречивые паттерны, избыточные зависимости и сложный код‑ревью.

Третья группа рисков затрагивает стоимость дальнейшей поддержки. ИИ‑код требует тщательного рефакторинга почти в том же объеме, что и написание с нуля. Без этого поддержка и развитие системы превращаются в постоянную борьбу с техническим долгом, который накапливался неконтролируемо.

В итоге на практике ИИ может сократить время создания отдельных компонентов, но не отменяет необходимости в ИТ‑архитекторе и ручном контроле качества. Экономия на старте оборачивается кратным ростом затрат на сопровождение.

Команда на первый год

Теперь разберем, без кого проект не взлетит. Представленный ниже состав — минимальный, при котором реально получить работающий продукт, а не прототип.

Итого: 9-10 человек

Что НЕ войдет в первый релиз

Важно понимать, что за 12 месяцев вы получите MVP, только минимально жизнеспособный продукт. Функциональность, которая в зрелых системах есть «в коробке», останется за пределами. Например:

• продвинутое управление портфелями и программами;

• диаграмма Ганта с учетом зависимостей и выравниванием ресурсов;

• встроенный учет трудозатрат (time-tracking) и финансовая аналитика;

• no-code/low-code движок автоматизации;

• конструктор отчетов и кастомизируемые дашборды;

• готовые коннекторы к Git-системам, CI/CD-инструментам, мессенджерам;

• сертифицированная подсистема безопасности (ФСТЭК и аналоги);

• полноценная ролевая модель с разграничением прав на уровне полей и кнопок.

Все это — годы последующей разработки.

Бюджет на создание и последующие 5 лет владения

Посчитает затраты. Средняя стоимость нужных специалистов на рынке труда РФ с учетом налогов, страховых взносов, оборудования и инфраструктуры рабочего места — примерно 350–500 тыс. руб. в месяц. Возьмем 400 тыс. руб. как расчетное число.

И это без учета стоимости доработок тех функций, которые не вошли в MVP. Каждая крупная фича — отдельный проект с семизначным бюджетом.

Не исключено, что эти цифры сразу приводят к оценке окупаемости такого проекта. И в этот момент может появиться идея, как этому приблизиться, Например, продавать свою разработку во вне. Давай рассмотрим и такой вариант.

Вариант 2. Выводим свой продукт на внешний рынок

Если вы задумываетесь о создании не просто внутреннего инструмента, а коммерческого B2B-продукта, модель разработки меняется радикально. Состав решения, которое продается внешним заказчикам, кратно дороже внутреннего.

Что доработать для рынка

Для продажи в госсектор, банкам и на объекты КИИ потребуется сертификация ФСТЭК России. Это длительный процесс, требующий отдельной команды или привлечения лицензиата. Стоимость сертификации может составлять несколько миллионов рублей, а сроки достигают 6–12 месяцев.

Также вам предстоит обеспечить multitenancy и варианты развертывания. Крупные заказчики часто требуют on-premise: установку системы внутри своего контура, без доступа вашего SaaS к их инфраструктуре. Это означает отдельную ветку разработки и тестирования для поддержки развертываний на мощностях клиента.

Внешним клиентам недостаточно отдать установочный файл. Вам понадобится разработать подробные руководства администратора и пользователя, программы обучения с видеокурсами, портал документации для разработчиков (API-docs), демо-стенды.

Но еще до того, как потенциальные заказчики начнут интересоваться вашим предложением, потребуется привлечь внимание к своему продукту, рассказать о нем, заинтересовать аудиторию. А при этом на рынке представлено уже множество подобных решений. Это значит, что необходима команда маркетинга и продаж.

Конкуренция и риски

Рынок систем управления проектами и разработкой в России в 2026 году характеризуется как зрелый и высококонкурентный. Период острой нехватки российских решений, вызванный уходом западных вендоров в 2022 году, завершился. 

Ключевые игроки давно заняли свои ниши. Например, Naumen Project Ruler — яркий представитель крупных корпоративных low-code платформ, на которых можно построить не только управление проектами, но и смежные процессы: ITSM, ITAM, ITOM, HR. Также в сегменте BPM/low-code платформ известны SimpleOne SDLC, ELMA 365. Специализированные продуктовые системы — EvaTeam, Яндекс Трекер, Kaiten, Shtab.

На этом фоне пробиться на рынок крайне сложно. Даже располагая уникальным технологически преимуществом, например, принципиально новым ИИ-движком в планировании, новый продукт сейчас не вызовет высокого интереса. Компании, которые уже перешли с импортных решений, не склонны менять их в ближайшие 3–5 лет. Кроме того, все сильнее растет тренд на комплексный подход к внедрению: заказчики отдают предпочтение вендорам, способным закрыть несколько смежных потребностей (BPM, ITSM, управление проектами и знаниями), а не точечными продуктами.

Бюджет на 5 лет для вывода решения на рынок

А что здесь с объемом затрат. Исходим из того, что в первый год для доработки до коммерческого продукта потребуется расширенная команда ~15 человек. Также включаем в расчет маркетинг и продажи.

Окупаемость возможна только при условии захвата ощутимой доли рынка. По оценкам экспертов, это потребует не менее 3–5 лет даже для крупного игрока.

Вариант 3. Покупаем готовый продукт

Остановимся на том, что получится, если выбрать другой вариант, — приобрести зрелую платформу от вендора.

Предсказуемый бюджет. Вы платите фиксированную стоимость за лицензии и внедрение. TCO на пятилетнем горизонте прозрачен и прогнозируем, так как не предполагает внезапного найма специалистов, чтобы обеспечить, к примеру, соответствие новым требованиям регуляторов.

Скорость запуска. В среднем внедрение занимает 1–3 месяца, далее можно начать использовать продукт. Если сравнивать с 12+ месяцев разработки MVP, для бизнеса это означает, что эффект от автоматизации будет получен уже в  рамках того же года, а не в следующем.

Полный функционал с первого дня. Зрелые системы десятилетиями накапливают опыт и обратную связь от сотен заказчиков и в соответствии с их бизнес-потребностями развивают свое решение. Вы получаете не только базовый трекинг, но все те возможности, которые в собственной системе добавляли бы годами.

Ответственность вендора. Безопасность, compliance, работа с персональными данными, поддержка отказоустойчивости — все это лежит на плечах вендора, а не вашего ИТ-департамента.

Снижение рисков. Работоспособность системы не будет зависеть от кадровой ситуации в вашем ИТ-подразделении. Специалисты могут меняться, но на обслуживании программного продукта это радикально не скажется. Меньше рисков, что решение не пройдет аудит безопасности. И вы не попадете в ситуацию, когда система разрабатывается под определенные требования, а ваши процессы изменились.

Экосистемный подход. Современные low-code платформы позволяют не ограничиваться одним направлением автоматизации. Впоследствие на них можно развернуть управление сервисным обслуживанием, HR-процессы и другие функции. И при этом избежать «интеграционного зоопарка». Для бизнеса это означает, что по мере роста потребностей компании не придется начинать новый проект с нуля, а можно подключать готовые модули на уже работающей платформе.

Экспертиза и методологии. Команда вендора обладает опытом десятков и сотен внедрений в разных отраслях, поэтому знает, какие, условно говоря, грабли лежат на дороге еще до того, как вы на них наступите. Эксперты помогут вскрыть системные проблемы, которые ваши специалисты перестали видеть, и предложат варианты оптимизации. Зрелые системы включает преднастроенные методологии управления, проверенные на реальных проектах. Это сокращает путь от покупки до первых результатов. Наконец, когда внедрение закрывает не только трекинг задач, но и более сложные задачи бизнеса, возврат вложенных инвестиций наступает быстрее и измеряется реальными сэкономленными деньгами и сроками.

Бюджет покупки готового продукта

Здесь стоимость зачастую складывается из трех основных составляющих: количества лицензий, объема внедряемых процессов и поддержки. Также она зависит от числа пользователей, глубины кастомизации и сложности интеграций. Приведем примерные цифры, основанные на опыте реализованных проектов внедрения решения Naumen Project Ruler.

Годовое сопровождение после внедрения — 19% от стоимости лицензий в год. При стандартном внедрении это примерно 2–3 млн руб. ежегодно: обновления, техподдержка, консультации.

Итого на пятилетнем горизонте — от 15 до 70 млн руб. в зависимости от масштаба. Даже верхняя граница в 70 млн — почти втрое ниже 190 млн, в которые обходится содержание собственной разработки за тот же период.

Так, например, реальная закупка Naumen Project Ruler для крупной организации обошлась в 24,9 млн рублей. Для сравнения: корпоративная лицензия Jira на несколько тысяч пользователей до ухода с рынка стоила от 10 до 20 млн рублей в год. И это без учета внедрения и техподдержки.

Что выбрать: итоговый взгляд

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

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

Чтобы снизить издержки и получить предсказуемый результат в сжатые сроки — зрелая готовая платформа выглядит более сбалансированным и быстрым решением, которое к тому же приносит с собой экспертизу, ускоренную окупаемость и проверенные методологии. Это в 12–22 раза дешевле разработки для коммерческого использования. Рынок предлагает достаточно инструментов, проверенных сотнями внедрений. Остается только выбрать тот, который ляжет на ваши процессы без необходимости изобретать всё заново.