Привет, Хабр! Я Алексей Шишкун, руководитель проектов в Т-Банке. Моя история — часть проекта «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»: 

• Иннерсорс: строим культуру открытого кода в большой компании