Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было».

Всем привет, это команда продукта SimpleOne SDLC. Техническую сторону миграции мы уже разбирали в других статьях, например — «Аналоги Jira». Сегодня — про то, о чем обычно молчат: сопротивление команды, потеря продуктивности в первые недели и как этого избежать.

Компании фокусируются на технической стороне миграции — перенос данных, настройка workflow, обучение. Но около 70% провалов при смене инструментов происходят не из-за технических проблем, а из-за человеческого фактора: сопротивления, потери привычных паттернов и падения мотивации в переходный период. В результате даже технически безупречная миграция превращается в месяцы хаоса.

Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.

Любое изменение — это дискомфорт. Оно требует времени

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

Диалог. Разработчик и менеджер — первая неделя после перехода

— А зачем мы вообще переехали? В Jira все нормально работало.

— Jira больше не поддерживается в России.

— Ну да, ну и что... Почему именно этот инструмент? Тут все по-другому.

— Помочь разобраться как фильтры работают?

— Я сам разберусь. Просто раздражает, когда все меняют и тебя не спрашивают.

Обратите внимание: разработчик не против нового инструмента как такового. Он против того, что его не спросили. Это принципиально разные вещи, и от этого зависит, как выстраивать работу дальше.

Как сделать изменения легче

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

Понять: зачем нам эти изменения

«Jira уходит с рынка» — это правда, но слабый аргумент. Для команды он не объясняет то, почему мы переходим именно на этот новый инструмент, и что конкретно теперь станет лучше.

Прежде чем идти к людям с объявлением о переходе, стоит ответить самим себе:

• Чего нам не хватало в Jira, помимо того, что она уходит?

• Какие конкретные задачи новый инструмент решает лучше?

• Это просто замена трекера — или возможность улучшить процессы в целом?

Диалог. Менеджер и руководство перед запуском проекта

— Нам нужен бюджет на переход с Jira, у нас уже есть несколько вариантов систем.

— А зачем что-то менять? Нельзя просто оставить все как есть?

— Поддержка прекращена, дальше будет только сложнее.

— Ну раз надо — выбирайте любую, только не дорогую.

— Но нам же не просто надо переехать «хоть куда-то»: у нас сейчас три отдела в разных инструментах, нет единой аналитики, разработка и поддержка вообще не связаны. Хорошо бы при переезде и это исправить.

— Тогда понятно. Давайте рассмотрим варианты.

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

Найти людей, заинтересованных в изменениях — и понять, что им важно

Одна из самых частых ошибок: решение спускается сверху без какого-либо вовлечения команды. Люди чувствуют, что изменение происходит над ними, а не вместе с ними.

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

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

В одной из команд таким человеком оказался тестировщик — он год мучился с фильтрами в Jira и первым попросил доступ к новой системе. Через неделю он уже показывал коллегам как настроить доски под себя. Один такой человек стоит десяти обучающих вебинаров.

И третий шаг — подключить представителей разных ролей: тестировщик подсветит то, что менеджер не увидит; аналитик расскажет про нужные поля в карточке; разработчик — про интеграцию с CI/CD. Широкий круг участников дает более полную и честную картину.

Диалог. Тимлид и команда — ретро перед переходом

— Через месяц переходим на новый трекер, давайте обсудим.

— Jira совсем отключат?

— Да, поддержки уже нет.

— Я давно хотел нормальные доски — в Jira с этим было нелегко.

— Да, и интеграции постоянно ломались.

— Окей. Давайте так: у кого были конкретные проблемы с Jira — запишите. Посмотрим, решает ли новый инструмент эти проблемы. Если решает — это будет весомым аргументом для переезда именно на него. 

Внедрять постепенно, а не сразу

Когда вся команда одновременно оказывается в незнакомом инструменте, происходит несколько вещей разом: люди не понимают, где что находится; ломаются привычные паттерны; продуктивность падает; раздражение копится. Раздражение переходит в сопротивление. Лучше начать с одной команды, одного проекта или одного типа задач. Дать им время освоиться, собрать опыт, найти решения для неочевидных кейсов. И только потом — следующий круг.

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

Небольшое отступление: когда мы обсуждали эту статью, кто-то пошутил: «Как избежать переход на новый инструмент? Никак!» — и, в общем-то, это точная формулировка. Если Jira ушла, она ушла. Вопрос только в том, как сделать переход менее болезненным.

Слушать обратную связь от сотрудников

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

Не привыкнут. Или привыкнут гораздо медленнее, чем могли бы.

Обратная связь в переходный период — это не пустые жалобы. Если несколько человек говорят, что не могут найти фильтр по ответственному — это не «они плохо изучили систему», это сигнал: либо нужна настройка интерфейса, либо документация, либо что-то доработать.

Что реально помогает:

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

2. Внутренний канал в мессенджере для вопросов по инструменту — без осуждения, с быстрыми ответами.

3. Назначить человека, который будет собирать обратную связь и иметь полномочия что-то менять в процессах адаптации.

Диалог. Тимлид и команда — через три недели после перехода

— Ребята, давайте честно: что все еще мешает?

— Фильтры на доске сбрасываются каждый раз при обновлении страницы.

— Не могу найти задачи, которые на мне, но не в активном спринте.

— А мне, честно, удобнее, чем в Jira.

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

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

Резюме

Переход на новый трекер закончится не когда данные перенесены и workflow настроен. А когда разработчик перестанет начинать утро с фразы «а в Jira было удобнее». Обычно это занимает месяц-полтора — если с командой разговаривать, а не просто обучать.

***

А вам уже приходилось мигрировать с привычного трекера на новый? Как вы справились с саботажем?