Как стать руководителем ИТ-команды за 5 лет

Александр Штыков за пять лет прошёл путь от стартовой позиции до уровня технического руководителя: в 2014 году устроился в веб-студию контент-менеджером, а в 2019-м стал лидом фронтенд-команды в дочке Сбербанка. Александр рассказывает о своей карьерной лестнице, навыках и технологиях, которые осваивал по пути.

Уровень 1. Работа контент-менеджером и попытки верстать

Я учился в Иванове в школе с математическим уклоном. У нас было много информатики, тогда у меня и появился интерес к ИТ. В бакалавриат я осознанно поступил на факультет информационных технологий в МГТУ «СТАНКИН».

К концу первого курса я уже твёрдо знал, что хочу работать в ИТ-сфере. Так что после летней сессии начал мониторить вакансии и попал в небольшую студию на позицию контент-менеджера.

У студии был свой образовательный продукт, который работал по принципу карточек: с одной стороны вопрос, с другой ответ, или с одной стороны слово, с другой перевод. Я эти карточки заполнял. Работал 20 часов в неделю, получал 10 тысяч в месяц.

Помимо карточек ещё помогал с другими задачами, вёл соцсети, занимался SEO. Если натыкался в продукте на баги, то заводил их в отдельную систему, так научился делать баг-репорты: доносить до разработчиков информацию как можно подробнее, чтобы им было проще всё починить.

На работе и в общаге вокруг меня было много студентов и молодых ребят, которые что-то программировали, так у меня появился интерес к разработке. В итоге на втором курсе увлёкся сайтостроением, начал учить HTML, CSS, PHP.

Со временем решил, что могу что-то сверстать сам. У отца тогда был бизнес по производству и продаже медицинской одежды и сопутствующих товаров, и я сделал для него сайт (но никуда не выложил).

После этого начал брать заказы на фрилансе по вёрстке макетов. В целом шло неплохо, но не без шероховатостей. Например, из одной компании, которая занимается подбором ИТ-кадров, три месяца выбивал 10 тысяч. В студии тоже помогал с вёрсткой, правил небольшие блоки. Мне подняли зарплату до 15 тысяч, но я решил, что хочу большего.

Уровень 2. Работа веб-мастером

В 2015 году я ушёл из студии и попал в компанию, которая занималась eSIM — это сим-карта, которая не привязана к конкретному оператору, а подключается к локальному, когда пользователь приезжает в новую страну. Меня взяли туда веб-разработчиком.

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

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

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

В итоге изучал всё сам, искал решения на Stackoverflow. Помню, была такая проблема: надо было получать данные с сервера, который жил на другом домене. У него не был настроен CORS — политика совместного использования между разными источниками, — так что мои запросы не проходили. На Stackoverflow увидел, что такое можно решить с помощью JSONP: оно предоставляет способ запросить данные с сервера не заботясь о кросс-доменных ограничениях. Я попробовал — сработало. Таких задач было много, приходилось во всём разбираться.

Моё резюме всё это время висело в открытом доступе, я его периодически обновлял. И вот однажды мне позвонили и пригласили на собеседование в дочернюю компанию Сбербанка — «Деловую среду». Я сходил на встречу и в апреле 2016 года вышел туда верстальщиком.

Уровень 3. Логика на JavaScript, фреймворки и препроцессоры. Рост от верстальщика до джуниор-фронтендера

Первое время я занимался только вёрсткой. Дизайнер рисовал макеты страниц с анонсами мероприятий или новых продуктов, а я их собирал. Потом начались задачи с логикой, например, написать поведение слайдера, сделать интересный адаптив или настроить форму обратной связи.

В команде был опытный разработчик, который начал меня обучать. Мы с ним вместе программировали, он объяснял мои ошибки, показывал новые инструменты. Под его руководством начал использовать gulp, препроцессоры CSS, вроде SCSS. Учился писать на чистом JS. Я быстро впитывал, закреплял дома по вечерам и вскоре дорос до позиции джуниор-фронтендера.

Один из проектов, над которыми я работал, была платформа для соревнований по биг-дате. На ней заказчики рассказывали о своих задачах, загружали данные, которые можно было использовать. А участники соревнований использовали эти данные, чтобы проверить гипотезы и предложить бизнесу решения.

Руководитель решил, что на платформе нужно использовать React — фреймворк, который помогает собирать пользовательские интерфейсы. Так что мне пришлось быстро в него погружаться, что оказалось неожиданно сложно. У меня был технический бэкграунд, я учился уже на четвёртом курсе, понимал основы ООП, но здесь завис. Месяц смотрел обучающие видео, читал статьи, пытался вникнуть в концепцию. Постепенно въехал. 

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

Уровень 4. Больше инструментов, код-ревью подрядчиков. Рост до мидла

В конце лета 2017 года появился новый проект: Минэкономразвития и Сбербанк решили запустить образовательную платформу для малого бизнеса.

Там планировались отдельные модули для статей, видео, курсов, спецпроектов, кабинета пользователя, администраторов компаний, внутренняя социальная сеть и ещё много всего. Запуститься при этом нужно было до конца года. В итоге команда разработки буквально за пару месяцев выросла до 40 человек, команда фронтов — до 8. Ещё около сотни разработчиков были в подрядных организациях.

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

Я к тому времени уже хорошо подтянул навыки, разобрался с Реактом, был на уровне мидла. Мне доверили одну из команд подрядчиков, чтобы я ревьюил их код и принимал результат. Параллельно я сам писал один модуль. Учился ставить задачи, оценивать и принимать работу, делать код-ревью. 

Полгода мы кодили почти без остановки: сроки были очень сжатые, а объём задач только рос. Но мы горели этим проектом, масштаб и формат захватывали. В итоге удалось в срок запустить — решение было неидеальным, но масштабным и, главное, работоспособным, хотя какие-то модули в первый релиз не попали.

Потом оказалось, что запустить проект и сделать так, чтобы он был удобным для пользователя, — две разные задачи. После запуска мы остались работать только внутренней командой и начали разбирать весь код и модули, которые у нас остались. Фиксили критичные баги, дорабатывали ключевые части системы, настраивали процессы.

Во время работы над платформой я общался с опытными коллегами, решал сложные задачи, много читал. С одной стороны, погрузился в новые технологии на фронте. Например, познакомился с redux — библиотекой для управления состояниями. С другой, в целом стал сильнее как программист. Понял, что разработка — это не когда ты коммитишь в мастер, но и есть циклы QA, контуры, CI/CD.

Уровень 5. Флоу разработки, больше ответственности. Рост до сеньора и тимлида

У платформы, над которой мы работали, микросервисная архитектура. Это значит, что для разных частей бизнес-логики был свой отдельный сервис. Например, сервис, который хранит информацию о курсах, или сервис, который работает с платными продуктами. Всё это общается между собой и с фронтом через REST API. Но из-за особенности интерфейса использовать REST было не очень удобно.

Например, нам нужно показать пользователю карточку видеокурса. Название и описание лежат в одном микросервисе. Информация об авторе в другом. Рейтинг — в третьем. Данные о том, добавил ли пользователь курс себе в избранное, — в четвёртом. Платный ли курс — в пятом. То есть, чтобы отобразить карточку одного материала, нужно сделать много запросов. А у нас разные форматы материалов, карточек и несколько платформ, карточки на которых отличаются.

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

Я продолжал осваивать технологии, в том числе GraphQL, redux-saga, react native. К тому же глубоко погрузился в продукт, своими руками потрогал уже почти все модули платформы. Это помогало общаться с бизнесом и поддерживать других разработчиков: я понимал возможности и ограничения системы, видел пути, которыми лучше решать задачи.

В итоге я стал самоходным: мог решать задачи, не подключая тимлида. А он мог, в свою очередь, переключиться на работу с менее опытными ребятами. Мне хватало компетенций и ответственности брать на себя технические решения. Знание технологий и способность самостоятельно решать задачи привели меня к уровню сеньора. 

Например, вместе с одним бэкенд-разработчиком я полностью отвечал за интеграцию Apple Pay. Или была такая задача: нужно было подключить к платформе связку с другим продуктом — сервисом, на котором предприниматели могут найти ментора или эксперта. Я сам договаривался с разработчиками другой компании, как им нужно доработать методы, как и какие данные мы будем отправлять.

Весной 2019-го произошли внутренние изменения — почти всю команду перевели в другую дочку Сбербанка, а я остался: поддерживать платформу и другие проекты, собирать новую команду. Бывший тимлид тоже ушёл, и я занял его место — стал техническим руководителем фронтенда.

Уровень 6. Работа тимлида: меньше программирования, больше софт-скиллз

Сейчас у нас несколько крупных проектов, в команде 15 человек, до конца года планируем расшириться до 20. Я стал намного меньше писать код, зато больше — работать с людьми.

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

Например, бэкенд платформы можно рассматривать как отдельный продукт и продвигать по модели BAAS — backend as a service. Для этого мы готовим нашу прослойку на GraphQL, чтобы ей тоже могли пользоваться другие компании, первый клиент уже есть. 

Ещё мы переводим часть платформы с клиентского рендеринга на серверный. Платформа была разработана как SPA — single page application. То есть пользователь думает, что он переключается между разными страницами сайта, но на самом деле находится в рамках одного веб-приложения. Это здорово для скорости работы, но мешает поисковой оптимизации, серверный рендеринг помогает исправить это.

Кроме платформы мы работаем над некоторыми другими проектами: сервисом удалённой регистрации бизнеса, программой для корпоративных партнёров Сбербанка, образовательным проектом «Бизнес-класс» и другими, о которых пока не могу рассказывать.

Как теперь: работа с командой

У каждого проекта своя команда и свой внутренний руководитель, с которыми я взаимодействую. Есть проекты, в которых я участвую плотно: присутствую на планёрках, помогаю принимать решения, слежу за кодом. Есть проекты, в которых внутренние руководители работают довольно обособленно и я помогаю изредка, в основном просто слежу за соблюдением общих стандартов и технологий.

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

Например, во всех проектах мы внедрили общий стандарт: везде пишем на TypeScript. Это язык, похожий на JavaScript, который расширяет его возможности, при этом сохраняет обратную совместимость. В командах похожие процессы планирования. Мы не пытаемся забить день разработчика под завязку, а считаем эффективные часы. Практика показывает, что писать код больше шести часов в день сложно, мы имеем это в виду, когда определяем нагрузку.

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

Как теперь: работа с бизнесом

Задачи к нам поступают от владельцев продуктов, менеджеров проектов и других внутренних заказчиков, которым нужны определённые возможности в продуктах. От того, как мы построим процесс работы с бизнесом, зависит скорость и качество разработки, а ещё — удовлетворённость коллег нашей работой.

Раньше с этим были сложности, задачи приходили в абстрактном виде, без полноценных вводных. Из-за этого разработка растягивалась: сначала приходилось выяснять детали, которых потом всё равно могло не хватить, и программист делал не то, чего ждал заказчик.

Сейчас процесс работает лучше. Бизнес опирается на метрики, проводит исследования, менеджеры проектов помогают подробно описать задачу. От этого выигрывают все: в бэклоге лежат удобные для разработки задачи, из-за чего проще прогнозировать сроки и следовать плану.

Периодически мне приходится искать компромисс между скоростью и качеством. Например, бизнес хочет быстро выпустить новую фичу, и я объясняю, в какие сроки это реально сделать. А если нужно быстрее, то на какие компромиссы придётся пойти. Мы стараемся делать не одноразово, а чтобы решения можно было использовать повторно — это, в частности, и в интересах бизнеса, но иногда увеличивает сроки.

Как теперь: самоорганизация

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

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

При этом соблюсти баланс между работой и личной жизнью всё равно бывает сложно, дома тяжело оторваться от компьютера и поставить какую-то конкретную границу. Я начинаю работать ближе к десяти, заканчиваю в 7–8. 

У разработчика результат работы виден — вот он писал код, вот готовый продукт. А у менеджера такого может не быть: вроде работаешь, а как понять, в чём твой вклад? Я постоянно фиксирую, чем занимался в течение дня, это помогает видеть результат своих действий, визуализировать работу. И не засиживаться лишний раз, думая, что за день не сделал ничего полезного.

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

Рекомендации для начинающих разработчиков

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

Тем, кто планирует развиваться во фронтенде, советую не гнаться за фреймворками, а сначала хорошо разобраться с чистым JavaScript. Я понимаю мотивацию многих: за знания модных технологий сегодня предлагают хорошие зарплаты, но если сразу изучать Vue или React, не разобравшись с нативным языком, то делать качественные и долгоиграющие решения не получится.

Действующим разработчикам рекомендую пробовать решать задачи из смежных областей, развивать профессиональный кругозор. Например, я периодически решаю задачки на платформе LeetCode, это помогает отрабатывать навыки и не бронзоветь, думая, что я уже всё умею.