Чем и как заменить решения Atlassian

Уход 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 решений вендоров, чьи имена сейчас звучат на рынке, затем устает от перебора и пытается выбрать только из них. В этом случае бизнес упускает возможность познакомиться с менее известным на рынке продуктом, который может лучше подойти для задач компании.

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

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

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

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

Базовые советы компании, которая ищет новое решение:

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

• Проанализируйте доступные вам решения самостоятельно или с помощью партнера. Если вы смотрели какое-то решение полгода назад, и тогда оно вам не подошло, не исключайте его в этот раз: возможно, продукт за это время уже доработан в нужную вам сторону.

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

• Попросите вендора настроить тестовый стенд. Некоторые компании делают это бесплатно, некоторые — только за отдельную плату. Если сомнения остались, запускайте пилот: это поможет избежать ошибок при внедрении.