Привет, Хабр! Я Алексей Шишкун, руководитель проектов в Т-Банке. Моя история — часть проекта «20 в 20» в честь 20-летия компании. Двадцать специалистов из двадцати городов делятся своими историями в серии статей, чтобы показать ИТ-хабы в разных городах и рассказать о людях, которые в них выросли.
Мой путь не был прямой линией «университет → стажировка → разработка». Я начинал как инженер техподдержки и долго верил в миф: чтобы попасть в ИТ, нужно только писать код. Оказалось, точек входа гораздо больше.
Расскажу, как смещался мой фокус от железа к процессам, почему «переписать все с нуля» — это ловушка и как среда ИТ-хаба в Челябинске помогала расти быстрее, чем удаленка.
Начало: три линии поддержки и LeetCode по вечерам
Я пришел в компанию на роль инженера первой линии. В Челябинске тогда только открывался наш ИТ-хаб. Формально мы занимались всем — от выдачи доступов к AD до настройки СКУД и сборки стоек под телевизоры в новом офисе.
Структура поддержки выглядела классически. Линии:
первая — распределение заявок, базовые сценарии;
вторая — диагностика железа, сопровождение рабочих мест;
третья — узкие профи: Windows-администраторы, сетевые администраторы и другие инженеры.
Я работал «в полях», видел, как живут разработчики и тестировщики, и очень хотел к ним. Параллельно учил Java и Kotlin, решал задачки на LeetCode. Мне казалось, что техподдержка и разработка — два разных мира, а единственный мостик между ними — синтаксис языка программирования.
Мне помогали расти документация внутри компании на вики, статьи на Хабре, внутренние курсы: PM.Basics, IT Manager Start и другие.
Что я сделал бы иначе, если бы проходил путь заново. Раньше бы начал разбираться, как устроена сфера в целом. Оказалось, недостаточно знать язык — нужно понимать роли (PO, PM, SA), процессы и то, как команда поставляет ценность.
Точки роста: бэклог из 700 задач и первый проект
Моей первой задачей стала поддержка WebTutor и E-Staff. Наш руководитель предложил подключиться к разбору накопившегося бэклога из 700 задач по восстановлению доступов, выдаче прав, созданию опросников и мероприятий. На старте нас было пятеро, но через некоторое время я остался один. Большинство задач требовали не фикса багов, а выяснения того, чего на самом деле хочет заказчик. Труднее всего было не починить что-то, а понять, что именно надо сделать.
Название задачи собиралось автоматически из полей формы — «Рабочий режим / Группа / Классификация / Тематика», — а в описании часто стояла одна строчка вроде «Нужно создать новое направление для подразделения комплаенса».
Я оказался в ситуации, когда нужно было не просто делать по инструкции, а разбираться, уточнять, общаться с инициаторами и погружаться в сложную систему. Там я понял важную вещь: технический навык вторичен по сравнению с коммуникационным.
Мне нравится думать, что именно тогда начал формироваться мой профессиональный образ — человека, которого не пугают сложные задачи и неопределенность. В какой-то момент просто решать тикеты стало тесно. Я начал подключаться к новым активностям: помогал с открытием региональных колл-центров в Перми и Туле, участвовал в технической поддержке Solution Cup в Сочи и CTF-мероприятиях в Челябинске.
Во время нескольких таких запусков появился мой первый настоящий проект и вместе с ним впервые возникла перспектива сменить профессию на Project Manager (РМ).
В 2022 году мне предложили внедрить систему учета ИТ-оборудования. Задача 1 выбрать open-source-решение, интегрировать его с корпоративной авторизацией и оргструктурой. Срок — 3 месяца.
На этапе выбора мы тестировали два решения. Одно настольное, устанавливалось через инсталлятор и требовало отдельной базы данных, но протестировать его можно было быстро и локально. Второе оказалось интереснее: open-source веб-приложение. Для него нужно было разворачивать виртуальную машину и разбираться, как правильно запускать систему в корпоративном контуре.
На тот момент я слабо представлял себе инфраструктуру компании. Не знал, что целевой сценарий должен вести в Kubernetes через контейнеры и Linux-окружение.
Мы разбирались в задаче вдвоем с коллегой, который как раз ротировался в SRE. Довольно быстро подняли систему на тестовой машине под Windows и начали ее активно исследовать.
Пока я тестировал приложение и фиксировал блокеры внедрения, понял, что для боевого контура придется осваивать совсем другой уровень. Я решил хотя бы на тестовой машине научиться поднимать веб-приложение на Linux, и за одни выходные это удалось сделать.
Там же я получил и очень важный урок. Из-за внутренних ограничений и отсутствия понимания корпоративной инфраструктуры я выбрал неправильный способ передачи исходников и в процессе допустил ошибку в обращении с данными. История закончилась официальным выговором от ИБ и очень профилактической беседой с моим руководителем и руководителем нашего отдела.
После этого я стал осторожным, узнал, как устроена внутренняя инфраструктура, как безопасно передавать файлы, работать в Linux и терминале. Для меня это был не провал, а сильный мотиватор: я стал внимательнее к своим действиям и ответственности.
К моменту выхода в прод мы уже были уверены в выборе open-source-решения. Изучили его глубоко и понимали, что по базовой функциональности оно нам подходит, но потребует серьезной доработки: нужно было обновлять фреймворк, учить систему работать с PostgreSQL вместо MySQL, переделывать небезопасную авторизацию, встраивать ее в корпоративную оргструктуру и автоматизировать подхват сотрудников.
Мы успели внедрить систему и 1 сентября 2022 года полностью переехали.
Сервис нужно было не только поддерживать, но и развивать. Тогда я впервые понял, что мне интересно не просто внедрить решение и довести его до запуска, но и заниматься им дальше: организовывать работу, ставить задачи, разбираться в требованиях, поддерживать темп команды и видеть, как сервис становится полезнее для пользователей.
Наверное, именно из-за этой истории я позже и получил рекомендацию по смене профессии — сначала от непосредственного руководителя, а потом и от главного заказчика.
Переход в Project Manager и вызов нового сервиса
В 2023 году я прошел внутреннюю ротацию и стал Project Manager в отделе развития внутренних сервисов. Моим первым большим проектом стало решение переписать наш основной сервис с нуля.
Причины переписать сервис были вескими:
Плохое масштабирование.
Невозможность при такой архитектуре безболезненно делить системы на изолированные пространства.
Дублирование функций. В системе на одно действие было несколько вариантов выполнения, из-за чего страдали консистентность данных и история.
Поддержка и развитие становились все сложнее и рискованнее.
Мы оценили MVP в 6 месяцев. Спойлер: реализация заняла полтора года.
На старте проекта все выглядело обнадеживающе. Я форсировал его, вдохновившись успешной аттестацией и тем, что теперь уже официально мог запускать и вести проекты.
Мы сформировали эпики, верхнеуровнево договорились о зонах ответственности, наметили вехи, продумали, как распределить ресурс так, чтобы не забросить текущий продовый сервис. А весной 2024 года начались сложности.
Пока мы строили базовую часть нового приложения, в старом сервисе все заметнее проявлялись архитектурные проблемы. Один из самых болезненных моментов был связан с историей изменений. Она представляла собой плоские технические логи, которые со временем перестали быть прозрачными для пользователей. Мы внутри команды еще могли восстановить картину происходящего, а вот для пользователя все становилось менее понятным.
Это был важный урок: системные логи и пользовательская история — не одно и то же.
На фоне растущего негатива по отношению к текущему сервису приняли непростое решение: часть команды оставить на разработке нового продукта, а большую часть переключить на стабилизацию и тушение пожаров в старом. Ситуацию усложнил и кадровый фактор: в разгар проекта из команды ушли два бизнес-аналитика — новых специалистов пришлось искать и вводить в контекст уже по ходу кризиса.
К маю 2024 стало понятно, что обещанный срок нереалистичен. 2024 год был для меня самым тяжелым профессиональным годом. Но именно он дал максимальное количество уроков.
Вот где я ошибся как начинающий менеджер.
Недооценка рисков. Когда в старом сервисе начались пожары, я переключил туда команду, но не сразу подсветил стейкхолдерам, как это сдвинет сроки нового продукта.
Мне было страшно признать вслух, что мы сильно недооценили масштаб.
Аккуратность вместо честности. Я до последнего старался сглаживать углы в отчетах, хотя нужно было прямо говорить о проблемах.
Для меня это был очень важный профессиональный сдвиг: я понял, что руководитель проекта отвечает не за то, чтобы лично принимать все решения, а за то, чтобы решения принимались своевременно, на нужном уровне и на основе полной картины.
Задачи PM — держать проект в прозрачном и управляемом состоянии. Помогать команде, пользователям и заказчикам. Одинаково ясно понимать цели, рамки и текущее состояние проекта: что входит в состав работ, какие есть ограничения и по каким критериям мы поймем, что результат успешен.
PM отвечает за то, чтобы решения принимались своевременно, на нужном уровне и на основе полной картины. Для этого он управляет не только рисками, но и изменениями и ожиданиями стейкхолдеров. А еще РМ удерживает баланс между сроками, стоимостью и объемом работ, чтобы результат получился наиболее качественным. Если вопрос выходит за рамки полномочий команды, он должен быть вынесен на согласование уже в структурированном и аргументированном виде.
Расфокусировка. Параллельно я вел еще несколько мелких инициатив. Проблема была не только в ошибке на старте, но и в постоянной перегрузке.
Как мы вырулили. Отказались от идеи «большого взрыва», когда все переключаются на новый сервис в один день. Перешли к стратегии инкрементальной миграции.
Мы поэтапно выкатывали новый интерфейс и функциональность: сначала в новой системе появилась возможность видеть устройства и действия, которые продолжали совершаться в старой версии сервиса, но отражались в новом сервисе.
Ценность этого подхода была в том, чтобы иметь запасной вариант, возможность переехать на старую версию, если что-то не работает в новой. В итоге мы ни разу не откатывались.
Вариант был технически сложным, зато единственным, который давал шанс уложиться в обновленные ожидания и получить раннюю обратную связь от пользователей.
К концу 2024 года в новом продукте уже можно было увидеть реальные интерфейсы, искать данные и постепенно проверять жизнеспособность решений. Для заказчиков это тоже меняло картину: вместо разговоров о планах и показа макетов мы демонстрировали работающую функциональность.
В апреле 2025 года переезд завершился. Итог: количество обращений в поддержку сократилось на 90%.
Точных метрик нет, мы следили за динамикой на уровне операционной работы команды. В первые недели после переезда в поддержку могло приходить до 50 обращений в день. Через несколько месяцев поток снизился примерно до 10—15 обращений в день, а к концу 2025 года — до 1—5 обращений.
Характер запросов тоже изменился. Сначала были вопросы по работе сервиса, неудобствам и предложениям по улучшению. Позже обращения в основном стали касаться административной части: заведения новых локаций, категорий и моделей, удаления дублей или исправления найденных ошибок в данных по устройствам.
Стек и команда сегодня
Сейчас я тимлид, но все так же в профессии проектного управления. Под моим началом 11 человек (бэкенд, фронтенд, QA). Мы развиваем внутреннюю платформу учета и инструменты автоматизации для техподдержки. У нас пять продуктов: три развиваются активно, а два — в режиме поддержки.
Один из примеров — история 2025 года, когда коллеги из соседней команды начали популяризировать Linux-устройства среди разработчиков. В альтернативных почтовых клиентах под Linux не хватало привычной интеграции для создания встреч с KTalk. На одном из синков мы услышали об этой боли, решили, что задача выглядит посильной, и попросили завести нам таску на исследование без лишних обещаний.
В итоге разработчик настолько увлекся, что довел идею до рабочего решения: за месяц мы сделали плагины для двух почтовых клиентов и закрыли вопрос быстрее, чем это получилось бы через внешний запрос вендору.
Наш технологический стек:
Backend: Laravel (исторически), новые сервисы на Python.
Frontend: Angular + Taiga UI.
Infrastructure: Kubernetes, Kafka (асинхронность), Redis (кеш), OpenSearch (поиск).
Мы работаем в распределенном формате, но челябинский ИТ-хаб остается для нас «точкой сборки».
Как устроен ИТ-хаб в Челябинске и зачем он инженеру
Нашему хабу исполнилось 5 лет. Из опенспейса на 25 человек он вырос в пространство на несколько этажей в самом центре города — на челябинском Арбате.
Вот почему я хожу в офис 5 дней в неделю, хотя могу работать удаленно.
Культура «кухни». Многие сложные технические вопросы решаются за 10 минут у кофемашины или за партией в настольный теннис. В такой атмосфере часто обсуждаются не только рабочие вопросы, но и околоразработческие темы: языки программирования, технологии, разные инженерные подходы. Для меня особенно ценны эти разговоры: они подогревают мой интерес к разработке и мотивируют развиваться.
Широкий кругозор. В хабе рядом сидят ребята из мобильного банка, страхования, AI-центра и Т-Бизнеса. Это создает эффект «переопыления».
Локальные традиции. У нас есть традиция называть переговорки в честь знаковых мест региона. «Ай» — в честь реки, по которой мы сплавляемся каждое лето. «Тургояк» и «Инышко» — в честь озер, на которые мы ездим в походы. Все это делает нас локальным коммьюнити со своими традициями.
Мы активно работаем с вузами, например ЮУрГУ, ЧелГУ, МИДиС, проводим воркшопы и митапы для студентов и городских профи. Мне они нравятся за атмосферу профессиональной среды. На митапах я осознал, что в разработке гораздо больше важных ролей, чем я думал изначально. А еще для меня там всегда было много новой и полезной информации.
На первых внешних митапах я переживал, что студенты, пришедшие на встречу, начнут спрашивать о моей роли, а мне толком будет нечего рассказать. Я тогда только пришел в компанию.
В реальности ко мне никто с такими вопросами не подходил. И сейчас я бы здесь ничего не менял. Для меня участие во всех мероприятиях со стороны технической поддержки было очень важным. Я ощущал свою причастность. Именно эта включенность в жизнь ИТ-хаба в итоге и привела меня к смене профессии. Для многих ребят программа «Т-Старт» стала таким же мостиком в ИТ, каким для меня когда-то стала техподдержка.
Вместо вывода
Мой путь от инженера техподдержки до руководителя проектов занял несколько лет и прошел через ошибки, выговоры и архитектурные кризисы. Вот главные выводы.
Не ждать предложений. Я начал брать задачи второй линии сам, не дожидаясь изменения должности. Потом включился в поддержку сложных внутренних систем, а дальше старался подключаться и к другим активностям: открытию новых площадок, технической поддержке мероприятий, задачам, где требовались диагностика и общение с сотрудником. Именно через поддержку, инициативу и погружение в соседние процессы я и начал двигаться в сторону проектов.
Среда решает. Находиться среди людей, которые сильнее тебя, — самый быстрый способ роста. Я был в окружении разработчиков, много с ними общался, видел, как живут команды, и постепенно начал смотреть на свою роль шире. ИТ-хаб в этом смысле оказался очень полезной средой: он расширял кругозор быстрее, чем любые внешние материалы.
PM — не надсмотрщик. Это человек, который собирает варианты решений, подсвечивает риски и помогает команде не бежать в стену. Он управляет не только задачами, но и ключевыми доменами проекта: требованиями, содержанием работ, рисками, изменениями, сроками, отчетностью и приемкой результатов. Причем делает это на всех стадиях проекта — от инициации и планирования до выполнения, мониторинга, контроля и закрытия. Его роль — держать проект в прозрачном и управляемом состоянии, чтобы решения принимались вовремя, на нужном уровне и с пониманием последствий.
Если вы сейчас в поддержке или на другой стартовой позиции, не ограничивайте себя кодом. Ищите проекты, берите на себя ответственность за неочевидные задачи и не бойтесь спрашивать совета у коллег на кухне. Иногда один разговор за кофе может заменить целый курс по Project Management.
Другие статьи проекта «20 в 20»:
Иннерсорс: строим культуру открытого кода в большой компании