Говоря об управлении проектами или руководстве деятельностью команд, трудно обойти стороной Jira. Одни считают, что это одна из лучших систем управления проектами, другие называют ее баг-трекером или идеальной тикет-системой (инструментом для организации работы с клиентскими обращениями). Jira также рассматривают как полноценную ITSM-систему и мощный инструмент для Agile-трансформации. Если взглянуть на одну из ниш, которую занимают продукты Attlasian на зарубежном рынке, а именно bug’n’issue tracking, то можно увидеть, что Jira является стандартом де-факто для более чем 85% компаний. Что касается российского рынка, то ситуация примерно такая же. По опыту экспертов “Консист Бизнес Групп”, которые взаимодействуют со многими заказчиками и дистрибьюторами, безоговорочным лидером в корпоративном сегменте для нужд управления задачами/заявками оказалась именно Jira. Теперь давайте рассмотрим, как же изменился российский рынок систем управления проектами с уходом Jira и какие продукты за этот год на нем обосновались.
Что умела Jira?
Проще ответить на вопрос, а что же она не умела? Я не зря в первом абзаце упоминал, что каждая компания или команда по-разному использовала Jira для решения своих бизнес-задач. Да, виды деятельности у команд могут быть абсолютно разные, но объединяет их одно - все они строятся вокруг контроля одной сущности - задачи (т.е. некоей единицы работы), у которой есть цель, ответственный за ее выполнение и дедлайн. Отличия возникают лишь из-за специфики самой сферы, в которой работают люди. У продавцов это - одно, у HR - другое, у разработчиков - третье, у бухгалтеров - четвертое и т. д.
Jira благодаря гибкости, а именно возможности подстроиться под любые нужды бизнеса без привлечения разработчиков, покорила рынок. Плюс за счет опции постепенного наращивания функционала инсталляция могла расти вместе с компанией: как говорится, от условного “гаража” до условной “корпорации” вне зависимости от рода деятельности компании.
Гибкость, которую я упоминаю, достигалась за счёт уникальной для рынка бизнес-модели Attlasian, а именно модели Marketplace. Сторонние разработчики могли использовать продукты Attlasian в качестве платформы, разрабатывая те дополнительные функции, которые, по их мнению, нужны рынку. Далее они выкладывали свои разработки в Marketplace и, естественно, продавали их за отдельные деньги.
Рынок систем управления проектами
Теперь вернёмся к управлению проектами. Для начала давайте определимся, а что же такое “рынок систем управления проектами” и на какие сегменты его можно поделить. Ведь системы управления проектами используют не только компании или отдельные команды, ведущие проектную деятельность. Отдельные функциональные блоки этих решений уже давно проникли в самые разные сферы деятельности организаций, где нет проекта в традиционном понимании. Повторюсь, что любой вид деятельности, где так или иначе присутствует единица работы с ответственным за ее выполнение исполнителем, нуждается в системе контроля. А выбор наиболее подходящего продукта определяется многими факторами, начиная со стратегических целей организации и заканчивая теми фреймворками, которыми руководствуются компании и команды.
Второе. Данный рынок поделен на несколько сегментов с разными игроками в каждом. Если взглянуть на картину до ухода западных вендоров, то она была примерно такая. В таблице ниже я привел только универсальные инструменты, исключив специализированные.
Дам еще небольшое пояснение о традиционном стеке управления проектами. Если взглянуть на его укрупненную картину с разделением по пользователям, то она выглядела следующим образом.
Как видите, если мы рассмотрим обычную крупную компанию, ведущую около проектную деятельность, то заметим, что “щупальца” Jira проникли на все уровни управления проектами.
Что изменилось
Что же поменялось после ухода зарубежных компаний? Шок от резких перемен прошел, но довольно сильно пострадали небольшие компании, использовавшие решения для управления проектами в облаке. Большие же корпорации, отдавшие предпочтение решениям в локальном контуре, прочувствовали это в меньшей степени. Да, они лишились доступа к обновлениям, но многие из них обеспечили себе пространство для маневра, закупив права на обновления и поддержку на год/три вперёд. Сейчас они могут позволить себе спокойно и без паники выбрать решение, которое их будет максимально устраивать.
А какие аналоги есть
Что касается достойных аналогов, то следует понимать, для чего, кем и какая система управления проектами использовалась, а также какой уровень зрелости проектного и процессного управления достигла компания.
Давайте попробую разложить крупными мазками.
-
Если говорить о системах верхнего уровня, на котором работало решение Oracle Primavera, то я бы рассматривал российскую систему Advanta. ТУРБО Трекинг тоже идёт в эту сторону, постепенно закрывая уровни бизнес-процессов и календарно-сетевого планирования, а также управление задачами. У ТУРБО Трекинга есть большое преимущество в том, что в экосистеме ТУРБО есть ERP-решение, что позволит использовать систему как проектное ERP.
-
Если спуститься на уровень систем календарно-сетевого планирования, где плотно сидел MS Project, то из коммерческих систем я бы рассмотрел ТУРБО Трекинг. Также есть ряд систем с открытым исходным кодом.
-
На уровне проектных команд, где осуществляется управление проектом с коротким горизонтом планирования, решений достаточно много. Это как раз та ниша таск-трекеров. На память приходит около десятка российских решений. Из них могу выделить YouGile, Kaiten из облачных и ТУРБО Трекинг из on-premise решений. Но стоит помнить, что 85% рынка данной ниши была за Jira, а это довольно специфический продукт, об уникальности которого я писал выше.
Что делать сейчас
На самом деле прошел уже год, и все, кому было сильно больно после ухода западных компаний, так или иначе нашли выход из ситуации. Сейчас же мы рассматриваем только те компании, которые обеспечили себе необходимый временной задел и до сих пор находятся в поиске.
Варианты достаточно простые. Их два.
-
Разработать ПО самостоятельно. Многие большие окологосударственные компании пошли именно по этому пути, чтобы обеспечить вендоронезависимость.
-
Проанализировать процессы управления проектами сейчас и то, как используются те или иные продукты, подготовить функционально технические требования к ПО и искать максимально подходящее под конкретные задачи.
Следует понимать, что полного клона вы не найдёте, и даже достаточно зрелые российские решения начали создаваться в 2019 году. Необходимо провести многофакторный анализ и выявить реально критичные для работы функции, сформировать шорт-лист решений, провести опытную апробацию выбранных решений.
Конечно, каждый вариант имеет свои преимущества и недостатки, и выбор будет зависеть от конкретных целей и стратегии компании.
О сложностях перехода
Говоря о сложностях перехода с зарубежных систем, мы в первую очередь говорим о Jira. А Jira - это целая создававшаяся годами экосистема решений от различных вендоров. Плюс зачастую заказчики разрабатывали собственные плагины. В итоге типичная инсталляция Jira - это непосредственно сам продукт, 10-15 сторонних плагинов, а также собственные разработки. Т.е. мы говорим о миграции не из одной информационной системы, а из 10-15, а это уже совсем другая задача.
Поэтому быстрая миграция 1:1 просто невозможна. Всегда следует рассматривать это как проект, который включает и этап обследования/анализа текущей инсталляции, бизнес-процессов, потоков данных, оценку рисков, разработку плана миграции, опытную миграцию, непосредственно миграцию, включая интеграцию с внешними системами. Естественно, внедрение любой новой системы потребует и переобучения пользователей, так как полной копии старых систем просто нет на рынке.
По опыту взаимодействия с крупными холдингами, уже имеющими опыт миграции между различными системами, могу сказать, что они отказались от миграции, предпочтя ручной перенос данных.
И еще несколько слов
Как я указывал в начале, всегда требуется понимать, для решения какой бизнес-задачи используется то или иное ПО. Я бы назвал используемую ранее Jira платформой-конструктором, из которой можно было собрать всё, что душе угодно.
Мы с решением ТУРБО Трекинг движемся именно по этому пути и всё необходимое у нас для этого есть, а именно:
-
платформа разработки ТУРБО X (именно на ней построено решение);
-
модульная архитектура, уже изначально заточенная под «плагинизацию»;
-
собственный язык разработки ТУРБО Скрипт;
-
low code-инструментарий, позволяющий осуществлять разработку и доработку решения своими силами;
-
готовая экосистема наших вендорских продуктов, имеющих интеграцию между собой.
Основные усилия сейчас направлены на создание сообщества разработчиков и развитие маркетплейса, куда наши партнёры будут выкладывать свои наработки, расширяющие функционал ТУРБО Трекинга.
Готов к обсуждению, пишите вопросы в комментариях.
Автор:
Vladimirovich1
