Приходит уведомление: «Переезжаем на Jira». В организации уже работает self-hosted система с 20+ интеграциями – автоматические боты, вебхуки, синхронизация с GitLab, генерация отчётов. Всё это строилось годами, поддерживается командой платформенных инженеров, которые «умеют и в инфраструктуру, и в кодинг». И вот кто-то наверху решил, что нужна Jira.
Знакомая ситуация? Если нет – просто подождите. Рано или поздно это случится с каждым тимлидом.
На встрече сообщества мы разобрали этот кейс живьём – с участником, который прямо сейчас проходит через миграционный ад. И выработали стратегию, которая применима не только к Jira, но к любому навязанному техническому решению.
Почему «просто скажи нет» не работает
Первый рефлекс инженера – объяснить, почему это плохая идея. Технически. Подробно. С аргументами.
Проблема в том, что решение принималось не на техническом уровне. Кто-то хочет набрать политические очки путём «успешного внедрения». Или продажник из Atlassian хорошо поработал с вашим руководством. Или новый CTO хочет оставить свой след.
Когда вы приходите с техническими аргументами к человеку, который принимает политическое решение, вы играете не в ту игру. Он не слышит «20 интеграций сломаются». Он слышит «айтишники опять ноют».
Переведите проблему в деньги
Менеджеры мыслят экономикой. Это не недостаток – это инструмент, который можно использовать.
Вместо «20 интеграций» скажите: «21 проект по миграции и разработке новой платформы». Одна миграция Jira – это не один проект. Это проект по каждой интеграции плюс сама миграция. Плюс двойная нагрузка на обслуживание старой и новой системы в переходный период.
Конкретный алгоритм:
1. Посчитайте интеграции. Не «у нас много интеграций», а «мы насчитали 20 интеграций». Число бьёт сильнее прилагательного.
2. Оцените каждую. «Если по оценке каждая интеграция – неделя работы, то получится столько-то человеко-месяцев». Даже грубая оценка лучше, чем никакой.
3. Покажите двойную нагрузку. В переходный период вы обслуживаете две системы. Тикеты по старой не исчезнут. Тикеты по новой появятся. Среднее время решения тикета вырастет. Посчитайте, насколько.
4. Учтите провижининг. Нужно железо? Доставка, настройка, тестирование. Пока серверы не приехали – команда простаивает. Уже полгода ушло – а до миграции ещё не начали.
5. Добавьте обучение. Новая система – новые привычки. Привычка помогает работать быстро. Когда привычку меняешь, человек замедляется. Это не лень – это физиология. Планируйте время на обучение, потому что иначе оно всё равно уйдёт – просто незаметно, в форме ошибок и задержек.
Вам не нужно считать зарплаты. Достаточно человеко-месяцев. «Все менеджеры знают, сколько стоит, как это моментально в денежку пересчитать». Так вы не умничаете, но цифры говорят за вас.
Найдите союзников
Политические игры не выигрываются в одиночку.
Кто пострадает от миграции, кроме вас? Отдел продаж, который пользуется дашбордом, сгенерированным из текущей системы. Финансы, которые получают автоматические отчёты. Любой отдел, у которого есть рабочий инструмент, завязанный на вашу систему.
Найдите самые болезненные интеграции – желательно те, которыми пользуется человек, стоящий выше инициатора миграции. И скажите: «Эти дашборды сломаются на такой-то срок».
Вам не нужно строить коалицию. Достаточно, чтобы пострадавшие знали о проблеме. Они начнут задавать вопросы сами.
Не принимайте ответственность за чужое решение
Это, пожалуй, самое важное. И самое сложное.
Когда вам говорят «переезжайте на Jira», соблазн – взять задачу и тащить. Потому что вы инженер, вы привыкли решать проблемы. Но в этом случае проблема – не ваша. Её создал тот, кто принял решение.
Практические шаги:
Фиксируйте всё в деловой переписке. Устное «давайте переедем» – это ничего. Письменное «я, Иван Петрович, утверждаю миграцию на Jira в срок до…» – это ответственность. «Я зафиксировал наше решение, что такой-то декларировал…» – ваша страховка.
Торгуйтесь. «Я соглашусь, если получу дополнительных людей / дополнительное время / снятие текущих задач». Если вам не дают ресурсы – скажите, что произойдёт: «Среднее время решения тикетов вырастет, мы не сможем отвечать вовремя».
Ставьте инициатора в позицию того, кто принимает решение. Не вы решаете мигрировать. Вы описываете последствия. Решение – его.
Тяните время (это не саботаж)
Внедрение, которое растягивается, теряет поддержку. Продажники, которые лоббировали Jira, не готовы тратить ресурсы на сделку, которая займёт несколько лет. Внутренний спонсор теряет интерес, когда видит, что «быстрая победа» превращается в марафон.
Вы не саботируете. Вы честно оцениваете. «Нам нужно оценить объём миграции – для этого нужно…» «Нужно закупить железо – доставка займёт…» «Нужно обучить людей – запланировали…» Каждый шаг – объективная необходимость. Но сумма шагов делает проект менее привлекательным для лоббиста.
Кейс из стенограммы: система отчётности
В разобранном кейсе была ещё одна деталь: система, которая автоматически генерирует отчёты по производительности сотрудников и отправляет их наверх. Внутри – обработка данных через LLM.
При миграции на Jira эту систему нужно переписывать с нуля. А пока она не работает – отчёты не приходят. Или приходят из двух разных источников, и нужна «точка правды»: какая система считает правильно?
Это идеальный аргумент. Потому что последствия видны наверху, а не внизу. Руководство перестанет получать привычные данные. И внезапно миграция станет их проблемой, а не вашей.
Почему вообще принимаются такие решения
Параллельно с разбором кейса сообщество обсуждало системную проблему менеджмента в Казахстане: вузы закрывают набор на управленческие специальности из-за переизбытка менеджеров – при том, что качество менеджмента хромает. «Рынок поощряет лояльных, а лояльные – это родственники», – сформулировал один из участников.
Навязанные технические решения – часто симптом этой проблемы. Человек, принимающий решение о миграции, может не иметь технической квалификации для его оценки. Он принимает решение по другим критериям: рекомендация знакомого, красивая презентация от вендора, желание «стандартизировать».
Это важный контекст для тимлида: вы боретесь не с глупостью, а с системой, в которой решения принимаются по нетехническим причинам. И поэтому технические аргументы не работают – нужны экономические.
Когда бороться не стоит
Не всякое навязанное решение – плохое. Иногда миграция действительно нужна. Иногда ваша «идеальная система» – это зоопарк из скриптов на пяти языках без документации, который держится на одном человеке.
Честный тест: если автор системы уйдёт завтра, сможет ли команда её поддерживать? Если нет – может быть, стандартное решение не так уж плохо.
Бороться стоит, когда:
- Текущая система работает, задокументирована, поддерживается командой
- Миграция не несёт экономической выгоды
- Решение принято по политическим, а не техническим причинам
- У вас нет ресурсов на миграцию без ущерба текущим задачам
Чек-лист тимлида: что делать, когда «сверху» пришло плохое решение
- Посчитайте объём работы в человеко-месяцах, а не в абстрактных «это сложно»
- Найдите 3–5 критичных интеграций, которыми пользуется руководство
- Определите пострадавшие отделы – потенциальных союзников
- Переведите всё общение в деловую переписку
- Не принимайте на себя ответственность за решение о миграции
- Торгуйтесь за ресурсы: люди, время, снятие текущих задач
- Учтите провижининг, обучение и двойную нагрузку в оценке
- Честно оцените: может, текущая система действительно хуже?
Ваш спокойный сон стоит нескольких часов подготовки. Документ с расчётами – это не бюрократия. Это ваша защита.
А вы сталкивались с навязанными техническими решениями? Как боролись – или не боролись? Обсудить можно в Telegram.
Эта статья основана на встрече сообщества «Тимлид не кодит» 7 мая 2026 года, где Жахангир разобрал живой кейс миграции на Jira. Контекст о проблемах менеджмента – из инсайтов за 5–11 мая. Присоединяйтесь к обсуждению в Telegram.