После ухода Atlassian многие компании стремятся как можно скорее найти отечественные продукты на замену Jira и Confluence. При импортозамещении систем управления проектами разработки и базами знаний ключевое значение имеет миграция данных. О проведении аудита процессов, оценке глубины миграции и успешном переносе данных рассказал Юрий Дручинин, лидер стрима Сфера.Управление Платформы Сфера, разработки вендора отечественного ПО НОТА.
В начале августа этого года Atlassian объявила, что уже в сентябре, через 30 дней после анонса, отключит российские аккаунты от своих сервисов. В скором времени так и произошло: компании из различных отраслей стали сообщать об отключении, параллельно подбирая альтернативные варианты.
Несмотря на решение австралийского разработчика покинуть российский рынок, о полном закрытии бизнеса в стране фактически было объявлено только спустя полтора года. Все это время процесс импортозамещения, по нашим наблюдениям, шел планомерно, не считая непродолжительного всплеска весной-летом 2022 года — когда на рынке присутствовала неясность.
Многие крупные компании занимались поиском подрядчиков, составляли шорт-листы продуктов, однако после неудачных пилотных проектов, цикл снова повторялся. И именно новость о скором отключении российских аккаунтов Atlassian стала главным стимулирующим фактором развития рынка аналогов Jira и Confluence. Прежде всего это касается средних и малых компаний, многие из которых использовали облачные продукты разработчика.
При этом заказчики не могут перейти на отечественные продукты в одночасье, миграция данных — длительный и технически сложный процесс. Кто-то пользуется бесплатными Open Source-системами, крупный бизнес изолирует решения на базе продуктов Atlassian, отказывая себе в обновлениях и вендорской техподдержке. Необходимо понимать, что оба варианта — это лишь «обезболивающее», действие которого скоро прекратится.
Насколько уже насыщены российскими решениями сегменты ПО для управления проектами и организации баз знаний? Чего не хватает этим решениям?
Российские аналоги Jira и Confluence в основном представлены в сегменте среднего и малого бизнеса, у корпоративного сектора выбор меньше. Это объяснимо: потребности СМБ удовлетворить проще, чем решить задачи для enterprise. В случае, если заказчик использовал Jira в рамках ITSM — подхода к управлению и организации ИТ-услуг — и ищет аналог исключительно для этой задачи, выбор отечественных систем будет больше. Если же Jira служила важным инструментом управления процессами разработки, придется организовывать полноценное импортозамещение.
Среди российского ПО есть немало решений, обладающих функциональностью, сравнимой с тем, что предлагает Atlassian. Однако они не заточены под широкий круг заказчиков и подходят лишь узкой группе пользователей. Мы видим, что большинство российских разработок не имеют методологии многоуровневого матричного управления процессами — заказчики сталкиваются с легковесными решениями с точки зрения настройки процессов и соответствия современному технологическому стеку.
Например, не все российские продукты поддерживают облачные решения, кроме среды SaaS. Те, кто поддерживает SaaS не всегда могут предоставить качественное on-premise-решение. Также они не всегда способны обеспечить требуемый уровень безопасности — некоторые продукты содержат уязвимости из-за несоблюдения стандартов безопасной разработки.
Какие рекомендации вы бы могли дать заказчикам, которые начинают проекты замены Jira и Confluence?
Основываясь на собственном опыте успешной миграции, мы советуем учесть следующее:
Сильные стороны решения. При выборе аналогов обращайте внимание на продукты с профильной экспертизой в приоритетных для вас направлениях.
Адаптивность к развертыванию. Выбирайте продукт, соответствующий технологического стеку и который может быть безболезненно интегрирован в инфраструктуру, где размещалась Jira или другая система на базе Atlassian.
Соответствие ландшафту. Продукты должны быстро реализовывать заложенные в них интеграционные возможности и вписываться в ландшафт внедренных информационных систем. Если ваш код хранится в Open Source-решениях, которые разработчики настроили под себя, необходимо искать подрядчика, способного обеспечить интеграцию с популярными Git-системами и, при необходимости, с оркестраторами.
Благодаря чему можно успешно осуществить миграцию процессов и данных?
Аудит. На старте необходимо провести аудит процессов, составить карту их связей и понять, какие данные и интеграции используются на различных этапах. Можно оцифровывать их в специальных редакторах, при необходимости добавляя отдельные плагины.
Глубина миграции. Прежде чем приступить к миграции данных, важно оценить уровень их глубины. Чем глубже исторический слой данных, которые вы хотите перенести, тем труднее это будет сделать из-за их сложной связанности. Так, данные за небольшой период можно выгрузить относительно легко, потому что не нужно дополнительно синхронизировать перенесенную на различных этапах информацию.
Сокращение возможных рисков. По возможности лучше оставить Jira в архиве, перенеся только текущие бэклоги. Новые задачи и спринты уже планировать в новом инструменте — в таком случае риски будут минимальны.
Выбор времени переноса. Если процессы в компании идут только по с понедельника по пятницу, работы по миграции лучше проводить в выходные. Так уже в понедельник часть команд сможет приступить к работе в новой системе, имея набор свежих тикетов и связанные между собой данные. При этом риски для производственных процессов будут минимальными.
Использование инструментов миграции. Дополнительные сложности могут возникнуть у компаний, которые используют Jira для ITSM или работы, требующей круглосуточного добавления информации и регулярного заведения тикетов. Помимо самой миграции, надо будет обеспечить полную синхронизацию приходящих данных из связанных систем, используя перекладчики — сервисы синхронизации и переноса данных в работающих системах.
Как вендор НОТА помогает заказчикам мигрировать на российские аналоги продуктам Atlassian?
Имея ряд пилотных проектов и коммерческих внедрений, включая проекты на десятки тысяч пользователей, мы полностью отработали все нюансы миграции с Jira на российскую систему Сфера.Задачи. Наши специалисты владеют различными инструментами на уровне скриптов и кода.
Если говорить о миграции с Confluence на решение Сфера.Знания, у нас есть современные UI-инструменты, с помощью которых можно подключаться к существующим системам и в удобном формате проводить миграцию. Команда платформы Сфера имеет опыт переноса информации из системы с миллионами задач и заявок, а также с сотнями тысяч статей из базы знаний.
Главное преимущество Сфера.Задачи и Сфера.Знания заключается в том, что они разрабатывались на современном технологическом стеке, близком к тому, что использует Atlassian.
Какие специфические требования вы отметили у заказчиков?
Мы обратили внимание, что многие компании существенно дорабатывали системы Jira и Confluence с целью их активного использования в рамках ITSM. Сервисные процессы обычно имеют сложную логику, и в них участвуют гораздо больше систем, чем в решениях для разработки ПО. Соответственно, требуется больше интеграций. В результате требования к автоматизации ITSM-продуктов значительно выше, чем в тех случаях, когда заказчику просто нужны решения для управления разработкой. Наш опыт в проведении пилотных проектов это подтверждает.
От чего зависит продолжительность проектов перехода с продуктов Atlassian на российские аналоги?
Сроки зависят от количества пользователей и от объемов данных, которые необходимо перенести. Для компании с десятками тысяч пользователей нам удалось перенести задачи из Jira за два месяца, занимаясь миграцией данных только по выходным. Миграция базы знаний — это всегда более сложный процесс, поэтому при тех же условиях она заняла около четырех месяцев. В процессе такой миграции мы увеличивали количество пользователей на несколько тысяч еженедельно для каждой из систем.