От аутстафера до менторства: как я обучаю разработчиков успешно работать в бигтехах

Здравствуйте! Меня зовут Данил Миронов. Я прошел путь от аутстаффера в крупных международных IT-компаниях до руководителя бэкенд-отдела в Doubletapp. В данный момент я помогаю своим коллегам успешно проходить интервью в российских и зарубежных компаниях, а также получать удовольствие от работы на аутстафе с максимальной отдачей.

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

В этом материале вы узнаете:

• Как быстро адаптироваться в команде и начать решать задачи?
• Как давать адекватные оценки и не сдвигать сроки?
• Что бы я изменил, если бы был на месте заказчика?
• Как поддерживать аутстафферов на проекте?
• Кто несет ответственность за профессиональное развитие: сотрудник, работодатель или клиент?
• Почему алгоритмы влияют на вашу карьеру в аутстафе?
• Стандарты грейдов в разных компаниях: есть ли совпадения?
• Почему аутстафферам предлагают перейти в штат (и как с этим справиться)?
• Аутстаф против штата: где больше возможностей?

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

Я не сталкивался с конфликтами в команде или “дедовщиной”, поскольку ко мне всегда относились как к штатному сотруднику. Первое время мне делали уступки, зная, что я новенький: «У Данила еще нет доступа, он разбирается». Я быстро освоился — первую задачу на первом проекте выполнил примерно за неделю. Доступы предоставили нестандартным образом: скинули zip-архив с кодом, этого оказалось достаточно.

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

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

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

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

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

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

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

Архитектурные решения также вызывали вопросы: не всегда выбирался оптимальный вариант. Нейминг переменных и функций оставлял желать лучшего — иногда он вообще был непонятным, а в одной функции оказывалось столько кода, что его разбор вытягивал много времени. Это требовало детального изучения каждой строки, чтобы понять логику.

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

Как руководитель, я провожу еженедельные “1-1” встречи с аутстаферами, обсуждаем текущие дела и необходимую помощь. Если возникают конфликтные ситуации, мы выслушиваем обе стороны и ищем подходящее решение.

Недавно у нас была ситуация, когда бэкенд-разработчика отправили на крупный проект, но ему начали давать задачи по фронтенду из-за его опыта. Хотя он справляется с этими задачами, он по своей специализации ориентирован на бэкенд. Мы созвонились, и он рассказал о своих предпочтениях. В итоге мы договорились, что он будет брать в основном бэкендерские задачи, а фронтендерские только по необходимости. Это принесло результат, и мы перераспределили нагрузку.

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

Если говорить о более общих аспектах профессионального развития, то в Doubletapp принято инвестировать в сотрудников: они принимают участие в конференциях, проходят платные курсы и покупают учебную литературу, могут тратить 10% рабочего времени на обучение и получают скидку 50% на курсы английского языка.

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

Что касается подготовки к собеседованиям, наряду с другими аспектами, главное — отработать алгоритмы, поскольку это один из ключевых навыков. На собеседованиях всегда есть алгоритмическая секция, и как минимум необходимо решить пару задач. Поэтому мы проводим для подготовляемых AI специалистов мок-собеседования, предоставляем набор алгоритмических задач и оплачиваем рабочее время, необходимое для их решения.

Общепринято считать, что в веб-разработке алгоритмические знания иногда нужны в 2% случаев, если вообще нужны, то это какие-то упрощенные задачи. Но это на самом деле отличный способ оценить, как человек мыслит и есть ли у него математический склад ума.

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

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

Бывают случаи, когда грейды не совпадают. Например, в апреле 2024 года мы представили фронтенд-разработчика как сеньора, но заказчик оценил его уровень как мидл+. Через несколько месяцев мы подняли вопрос о пересмотре грейда. Заказчик собрал отзывы о работе специалиста и подтвердил, что он соответствует уровню сеньора, поэтому получил повышение.

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

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

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

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

Обычно, работая в крупной IT-компании, вы задерживаетесь на одном проекте на два-три года. В аутстафе, когда контракт заканчивается, вы можете перейти в другую компанию и так же участвовать в новом проекте. Это уникальная возможность увидеть внутренние процессы и наладить связи с выдающимися людьми в индустрии.

Если есть вопросы,
если вы разработчик, присоединяйтесь к нашей команде. А если вашему бизнесу необходимы IT-специалисты или слаженная команда, узнать о технологиях и ставках можно на сайте Doubletapp, или в партнёрском канале в Telegram.