Уход Atlassian с российского рынка не стал катастрофой для бизнеса: есть много отечественных решений, способных заменить привычное всем ПО. Разобраться в них, чтобы сделать самостоятельный выбор, можно, но придется потратить много времени и сил.
Бизнес-заказчиков ПО всегда пугает что-то новое: момент подбора, а тем более перехода на новое решение без сильного давления извне обычно сильно затягивается. Так, например, Atlassian заявила о своем уходе еще весной, однако оплаченные лицензии продолжили работать, поэтому большинство компаний не торопились искать замену. Тем более, продукты Atlassian занимали большой сегмент рынка и отечественные предприятия привыкли пользоваться базой знаний Confluence, системами для совместной работы и отслеживания задач Jira и Trello, сервисом для управления заявками, поддержкой и автоматизации сервисной службы Service desk и другими решениями разработчика.
По сути, "пролонгированный" уход позволил российским вендорам изучить новые потребности клиентов и дал дополнительное время для доработки продуктов. Большой шаг вперед за этот год сделали разработчики EVAProject, "Яндекс Wiki", "ТУРБО Трекинг", "ТУРБО Wiki", Kaiten, EVA Wiki. Я рекомендую начать анализ российских решений именно с них.
На что обратить внимание
Важно понимать, что российской "кальки" продуктов Atlassian нет: отечественные разработчики не пытались конкурировать с гигантом. Вендоры пытались занять смежные ниши и развивали продукты для интеграции с решением, которое стало некоторым стандартом в отрасли.
Так как прямых аналогов нет, в одночасье заменить продукты Atlassian не получится. Чтобы подобрать подходящее решение, в первую очередь нужен тщательный анализ потребностей компании и детальное сравнение доступных решений. Впрочем, близкими характеристиками к привычным Jira и Confluence, по нашему опыту, обладает ряд продуктов, в том числе решение вендора EVA.
Однако занимаясь подготовкой к переходу на другое решение, компании нужно помнить, что и Confluence, в частности, и экосистема Atlassian, в целом, работают таким образом, что каждый ИТ-продукт по отдельности представляет собой лишь базовый набор каких-то функций. А все возможности и потенциал решений раскрывается благодаря взаимодействию этих продуктов. Это важно учитывать, выбирая новые решения, - менять придется всю экосистему сразу.
Классическая потребительская стратегия пользователя ПО от Atlassian на российском или любом другом рынке обычно подразумевает покупку дополнительных модулей и плагинов - для решения конкретных задач. В итоге при необходимости мигрировать с Confluence в российскую систему компания сталкивается с нехваткой возможностей базового функционала. Плагины, которые компания докупала для работы с Confluence, нужно искать или разрабатывать заново. Переезд на новое решение превращается в полноценный отдельный проект, который требует много времени и привлечение разработчика. Он поможет с наименьшими потерями перенести все необходимые данные из системы в систему, не растеряв нужных функций.
С чего начать подбор решений
Для начала важно сформулировать, что компании на данном этапе развития хочется получить от системы. Здесь нужно подумать о том, какими функциями привычных программ предприятие на самом деле пользовалось, а какие были "мертвым грузом" и достались в наследство. На консультации мы прямо спрашиваем: "Какие слабые места вам нужно закрыть?". Попробуйте честно ответить на этот вопрос прямо сейчас. Часто выясняется, что система, идентичная той, что уже была у компании, нужна далеко не всегда.
Бизнес-требования к новому решению подскажут вашим аналитикам и инженерам, какую новую логику можно применить для решения ежедневных задач предприятия, чтобы двигаться дальше - к выбору нового продукта. Если в штате нет экспертов с достаточными компетенциями или не хочется надолго отвлекать дорогостоящих специалистов от их текущей работы, обратитесь за консультацией к технологическому партнеру.
Типичные ошибки, которые совершает компания при самостоятельном подборе аналогов, обычно выглядят так:
-
Ошибка выборки. Компания тщательно изучает 3-5 решений вендоров, чьи имена сейчас звучат на рынке, затем устает от перебора и пытается выбрать только из них. В этом случае бизнес упускает возможность познакомиться с менее известным на рынке продуктом, который может лучше подойти для задач компании.
-
Искажение при принятии решений. Красивый лендинг, эффектная демонстрация продукта и услужливый сервис на этапе продаж может довести до покупки продукта. Но когда доходит до дела и вендор начинает обучать сотрудников работать в новой системе, оказывается, что все не так, как было во время презентации: чуть другая логика, не так комфортно работать, сложно запомнить, где что, нет нужных инструментов.
-
Попытка сэкономить на "пилоте". Часто компания изучает декларируемый функционал "в теории", довольствуется презентацией и на основании этого делает свой выбор. Но скупой платит дважды: чтобы не переплатить, лучше сначала заплатить за пилотное внедрение и убедиться, что продукт действительно подходит и не требует дорогостоящих доработок под нужды предприятия, и только потом покупать полный функционал решения.
Подбор и внедрение новой системы может занять от нескольких месяцев до полугода: точное время зависит от нужд компании, количества пользователей и готовности к сотрудничеству при выработке новой бизнес-логики у смежных департаментов.
Выбор решения - всегда совместная работа. Важно, чтобы на "том конце провода", то есть на стороне разработчика, были правильно услышаны ваши потребности. Кроме того, придется потратить время, чтобы познакомиться с "дорожной картой" разработки продукта и проанализировать плюсы и минусы решения на данный момент. Делегируйте этот фронт работ, если в команде нет таких компетенций.
Базовые советы компании, которая ищет новое решение:
-
Изучите, как вы сейчас используете программу, которую хотите заменить. Проанализируйте плагины, которые действительно вам нужны, составьте список, от чего можно отказаться без существенных проблем.
-
Проанализируйте доступные вам решения самостоятельно или с помощью партнера. Если вы смотрели какое-то решение полгода назад, и тогда оно вам не подошло, не исключайте его в этот раз: возможно, продукт за это время уже доработан в нужную вам сторону.
-
Не стесняйтесь запрашивать демонстрацию продукта у вендора. Если у него нет такой опции и вендор не занимается прямой продажей своих продуктов, найдите партнера, который сможет ее провести. Чем полнее вы расскажете про текущие требования, опасения и сервисы, которые могут понадобиться в будущем, тем более качественный результат вы получите на демонстрации. В процессе демо нужно оценить, возможно ли то, что вы хотите, сделать в этой системе.
-
Попросите вендора настроить тестовый стенд. Некоторые компании делают это бесплатно, некоторые - только за отдельную плату. Если сомнения остались, запускайте пилот: это поможет избежать ошибок при внедрении.