Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было».
Всем привет, это команда продукта SimpleOne SDLC. Техническую сторону миграции мы уже разбирали в других статьях, например — «Аналоги Jira». Сегодня — про то, о чем обычно молчат: сопротивление команды, потеря продуктивности в первые недели и как этого избежать.
Компании фокусируются на технической стороне миграции — перенос данных, настройка workflow, обучение. Но около 70% провалов при смене инструментов происходят не из-за технических проблем, а из-за человеческого фактора: сопротивления, потери привычных паттернов и падения мотивации в переходный период. В результате даже технически безупречная миграция превращается в месяцы хаоса.
Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.
Любое изменение — это дискомфорт. Оно требует времени
Есть простая и неудобная правда: любой переход на новый инструмент в любом случае принесет временный дискомфорт и замедление. Попытка убедить команду, что «все будет хорошо с первого дня», только усиливает разочарование, когда на второй неделе что-то идет не так. Лучше честно сказать: да, первое время будет сложнее, чем вы привыкли, но это нормально и временно.
Диалог. Разработчик и менеджер — первая неделя после перехода
— А зачем мы вообще переехали? В Jira все нормально работало.
— Jira больше не поддерживается в России.
— Ну да, ну и что... Почему именно этот инструмент? Тут все по-другому.
— Помочь разобраться как фильтры работают?
— Я сам разберусь. Просто раздражает, когда все меняют и тебя не спрашивают.
Обратите внимание: разработчик не против нового инструмента как такового. Он против того, что его не спросили. Это принципиально разные вещи, и от этого зависит, как выстраивать работу дальше.
Как сделать изменения легче
Полностью убрать дискомфорт не получится, но можно существенно снизить его интенсивность и длительность, если подойти к переходу осознанно.
Понять: зачем нам эти изменения
«Jira уходит с рынка» — это правда, но слабый аргумент. Для команды он не объясняет то, почему мы переходим именно на этот новый инструмент, и что конкретно теперь станет лучше.
Прежде чем идти к людям с объявлением о переходе, стоит ответить самим себе:
Чего нам не хватало в Jira, помимо того, что она уходит?
Какие конкретные задачи новый инструмент решает лучше?
Это просто замена трекера — или возможность улучшить процессы в целом?
Диалог. Менеджер и руководство перед запуском проекта
— Нам нужен бюджет на переход с Jira, у нас уже есть несколько вариантов систем.
— А зачем что-то менять? Нельзя просто оставить все как есть?
— Поддержка прекращена, дальше будет только сложнее.
— Ну раз надо — выбирайте любую, только не дорогую.
— Но нам же не просто надо переехать «хоть куда-то»: у нас сейчас три отдела в разных инструментах, нет единой аналитики, разработка и поддержка вообще не связаны. Хорошо бы при переезде и это исправить.
— Тогда понятно. Давайте рассмотрим варианты.
Разница между «нам надо менять Jira» и «мы хотим объединить разработку и поддержку в одном контуре и видеть сквозную аналитику» — огромная. Второй аргумент убедительнее для руководства и честнее для команды.
Найти людей, заинтересованных в изменениях — и понять, что им важно
Одна из самых частых ошибок: решение спускается сверху без какого-либо вовлечения команды. Люди чувствуют, что изменение происходит над ними, а не вместе с ними.
Первый шаг — найти внутри команды тех, кто сам заинтересован в переходе. Не менеджеров с задачей, а обычных разработчиков, тестировщиков или аналитиков, у которых есть конкретная боль от текущего инструмента.
Второй шаг — с этими людьми проработать. Выяснить, что им не нравится, что нравится и что они хотят. Если они готовы делиться — это уже ценный ресурс, который нужно правильно использовать.
В одной из команд таким человеком оказался тестировщик — он год мучился с фильтрами в Jira и первым попросил доступ к новой системе. Через неделю он уже показывал коллегам как настроить доски под себя. Один такой человек стоит десяти обучающих вебинаров.
И третий шаг — подключить представителей разных ролей: тестировщик подсветит то, что менеджер не увидит; аналитик расскажет про нужные поля в карточке; разработчик — про интеграцию с CI/CD. Широкий круг участников дает более полную и честную картину.
Диалог. Тимлид и команда — ретро перед переходом
— Через месяц переходим на новый трекер, давайте обсудим.
— Jira совсем отключат?
— Да, поддержки уже нет.
— Я давно хотел нормальные доски — в Jira с этим было нелегко.
— Да, и интеграции постоянно ломались.
— Окей. Давайте так: у кого были конкретные проблемы с Jira — запишите. Посмотрим, решает ли новый инструмент эти проблемы. Если решает — это будет весомым аргументом для переезда именно на него.
Внедрять постепенно, а не сразу
Когда вся команда одновременно оказывается в незнакомом инструменте, происходит несколько вещей разом: люди не понимают, где что находится; ломаются привычные паттерны; продуктивность падает; раздражение копится. Раздражение переходит в сопротивление. Лучше начать с одной команды, одного проекта или одного типа задач. Дать им время освоиться, собрать опыт, найти решения для неочевидных кейсов. И только потом — следующий круг.
Здесь также важно учитывать цель перехода. Если задача — поменять трекер для всей компании разом, логика может быть другой: слишком долгий параллельный период создает риск отката к старому. Но если есть возможность идти постепенно — лучше идти постепенно.
Небольшое отступление: когда мы обсуждали эту статью, кто-то пошутил: «Как избежать переход на новый инструмент? Никак!» — и, в общем-то, это точная формулировка. Если Jira ушла, она ушла. Вопрос только в том, как сделать переход менее болезненным.
Слушать обратную связь от сотрудников
Это звучит как банальность — но именно этот шаг чаще всего пропускают. Переход случился, все обучены, процесс запущен. Дальше предполагается, что люди просто привыкнут.
Не привыкнут. Или привыкнут гораздо медленнее, чем могли бы.
Обратная связь в переходный период — это не пустые жалобы. Если несколько человек говорят, что не могут найти фильтр по ответственному — это не «они плохо изучили систему», это сигнал: либо нужна настройка интерфейса, либо документация, либо что-то доработать.
Что реально помогает:
Короткие синки раз в неделю в первый месяц — не «как вам новый инструмент вообще», а конкретные вопросы: что мешает, что занимает больше времени, что непонятно.
Внутренний канал в мессенджере для вопросов по инструменту — без осуждения, с быстрыми ответами.
Назначить человека, который будет собирать обратную связь и иметь полномочия что-то менять в процессах адаптации.
Диалог. Тимлид и команда — через три недели после перехода
— Ребята, давайте честно: что все еще мешает?
— Фильтры на доске сбрасываются каждый раз при обновлении страницы.
— Не могу найти задачи, которые на мне, но не в активном спринте.
— А мне, честно, удобнее, чем в Jira.
— Хорошо. Про фильтры — это настройка, узнаю как. Про задачи вне спринта — там есть отдельный раздел, просто называется «неочевидно», сейчас покажу. Все это записываю как задачу на доработку документации.
Именно так выглядит нормальный процесс адаптации. Не «все уже должны были разобраться», а живой разбор конкретных проблем с конкретными решениями.
Резюме
Переход на новый трекер закончится не когда данные перенесены и workflow настроен. А когда разработчик перестанет начинать утро с фразы «а в Jira было удобнее». Обычно это занимает месяц-полтора — если с командой разговаривать, а не просто обучать.
***
А вам уже приходилось мигрировать с привычного трекера на новый? Как вы справились с саботажем?