Привет! Меня зовут Данил Миронов. Я прошел путь от аутстафера в зарубежных бигтехах до руководителя бэкенд-отдела в Doubletapp. Сейчас я помогаю своим сотрудникам успешно проходить собеседования в российские и зарубежные компании и работать на аутстафе с удовольствием и максимальной отдачей.
В этом тексте я расскажу о том, как быстро вливаться в международные команды, как договариваться с заказчиками, если они ставят нереальные сроки, как прокачать грейд и зарплату всего за несколько месяцев.
Данил Миронов, руководитель бэкенд-отдела в Doubletapp
В этом тексте расскажу:
• Как влиться в команду и сразу начать решать задачи?• Как давать реалистичные оценки и не сдвигать дедлайны?• Что бы я изменил в проекте, будь я заказчиком?• Как поддерживать аутстаферов на проекте? • Кто отвечает за развитие: сотрудник, работодатель или заказчик?• Почему алгоритмы решают твое будущее в аутстафе?• Грейды в разных компаниях: совпадают ли стандарты?• Почему аутстаферам предлагают уйти в штат (и что с этим делать)?• Аутстаф vs. штат: где больше возможностей?
Как влиться в команду и сразу начать решать задачи?
Внедрить нового сотрудника в бигтех непросто, и дело тут не в аутстафе: даже если устраиваешься в штат, первый месяц уходит на получение доступов, приходится подавать заявки и ждать. Поэтому контракты обычно заключают хотя бы на полгода, чтобы потратить пару месяцев на знакомство с командой и проектом.
Сложностей с коллективом и дедовщины при выходе на проекты я не замечал, ко мне всегда относились как к штатному разработчику, на первых порах делали скидку на то, что я пока новенький: «У Данила ещё доступа нет, он пока разбирается». Разбирался быстро — первую задачу на первом проекте решил примерно через неделю. Доступы тогда дали костыльно — скинули zip-архив с кодом, этого хватило.
У ребят были созвоны, которые не касались моей работы напрямую, но давали возможность лучше погрузиться в проект в целом и понять, как он развивается и куда движется. Я был новичком на проекте, поэтому предложил добавлять меня на все возможные созвоны, даже такие, где напрямую не нужен. И там я не просто присутствовал, а задавал много вопросов и предлагал на обсуждение варианты решения технических проблем. Зачастую слышал: а ведь мы об этом не знали, не подумали, давайте делать так. Не скрою, было приятно.
В другой компании мне часто приходилось говорить на английском. В целом ничего сложного, но вот когда мы настраивали HR-автоматизации и работали со сторонними системами, начался челлендж: в техподдержке одного из сервисов, которые мы интегрировали, было много сотрудников из Индии, и общение с индийскими инженерами — это отдельный вид испытаний. Английский — не их родной язык, акцент мощный, приходилось напрягаться, чтобы что-то разобрать. А вот с коллегами-иностранцами в штате той компании, в которой я работал на аутстафе, всё было проще — общались в основном текстом.
Совет разработчикам: не стесняйтесь задавать вопросы, ходите на созвоны, узнавайте больше о проекте. Будьте активными, предлагайте решения. И учите английский.
Как давать реалистичные оценки и не сдвигать дедлайны?
В начале работ на одном из проектов у нас возникла проблема с оценкой и пришлось сдвинуть сроки релиза. Мы интегрировали несколько систем и когда взялись за первую, сказали: 100% ничего сложного, оценка такая-то, N часов. Заказчик приобретал готовые решения по системе SaaS. В процессе разработки выяснилось, что документации на них либо нет, либо она неполная, и нам нужно сначала потратить время на поиск решений и получение документации, чтобы разобраться, как системы работают. Для интеграции одного из сервисов нам предстояло общение голосом с индийской техподдержкой.
Мы оценили задачи по интеграциям и слегка вышли за оценку, потому что в каждой задаче была куча неопределенностей, потому что все задачи были связаны с другими системами, в которые тоже нужно погрузиться, понять, как они работают, а затем сформировать в голове идею и решение.
Этот опыт научил нас более ответственно подходить к оценке: сначала искать ключевые моменты, документацию, разбираться, реализуема ли физически задача с помощью той системы, с которой нам придется работать. Напомню, что мы работали с внешними системами, и если у них нет такого функционала, который хочет заказчик, то мы его точно не добавим.
В итоге мы научились делать более гибкие решения, с учетом того, что заказчик может прийти и сказать: «А я все-таки хочу вот это». Если это что-то, что мы можем предсказать, потому что мы уже знаем, куда движется проект и знаем эту систему, то мы стараемся сразу делать более гибкую реализацию, которая позволит в будущем быстро и легко что-то поменять. И это творческая часть нашей работы.
Что бы я изменил в проекте, будь я заказчиком?
Основная проблема на том проекте заключалась в том, что код-стайл сильно страдал, потому что мы работали с аналитиками, а это, как известно, не то же самое, что разработчики. Например, в Python есть общепринятые практики, но они не всегда соблюдались. Из-за этого код получался громоздким, сложным и непонятным. Где-то можно было сделать лучше, но этого не происходило.
Архитектурные решения тоже вызывали вопросы. Речь не о глобальных архитектурных проблемах, а о конкретных задачах: каждую из них можно решить множеством способов, но часто выбирался самый простой, в лоб. Нейминг переменных и функций оставлял желать лучшего — где-то он был совсем непонятным, а где-то в одной функции оказывалось столько кода, что разобраться в ней было почти невозможно. Приходилось буквально вчитываться в каждую строчку, чтобы понять, что происходит. Использовались устаревшие подходы, которые можно было бы сделать намного элегантнее.
В начале работы уходило много времени на то, чтобы разобраться в коде. Отчасти потому, что у заказчика был свой словарь терминов. Мне поздно дали доступ к их Notion, где это всё было описано, но при этом команда всегда шла навстречу: на все вопросы отвечали подробно и тратили на это много времени. Никогда не было такого, чтобы мои вопросы игнорировали или говорили «забей». Отношение было очень дружелюбным, и именно поэтому проект и команда мне так понравились.
Как поддерживать аутстаферов на проекте?
Я как руководитель отдела каждую неделю провожу «1-1» встречу с аутстаферами, обсуждаем, как дела, какая помощь нужна. Если возникают какие-то спорные ситуации, выслушиваем обе стороны и ищем подходящее для всех решение.
Например, недавно у нас была ситуация, когда бэкендера отправили на крупный проект, но ему стали давать и фронтендерские задачи, потому что у него был опыт работы с фронтендом. Для нашего сотрудника это не проблема, он справляется, но область его профессиональных интересов — все-таки бэкенд, и он рассчитывал на этот круг задач. В итоге мы с ним созвонились, он описал проблему, и мы подобрали решение — поговорить со своим лидом, и предложить забирать большинство бэкендерских задач, а фронтендерские — только по необходимости. Разговор помог, и проблема разрешилась, нагрузку перераспределили.
Кто отвечает за развитие: сотрудник, работодатель или заказчик?
Когда заказчик ищет разработчика на аутстаф, у него уже есть ряд требований к нему, и если человек не подходит под эти требования, его на аутстаф не возьмут. А что касается обучения во время работы, то, когда у нас была какая-то задача, допустим, заказчик переходил с одной базы данных на другую, там новый синтаксис и его нужно было изучить, нам выдали обучающие материалы и статьи. Естественно, это трекалось в рабочее время, потому что мы так решали задачу — изучали то, что для этого нужно.
Если говорить о менее прикладных вещах и общем профессиональном развитии, то у нас в Doubletapp принято вкладываться в сотрудников: ребята ездят на конференции, занимаются на платных курсах, покупают учебную литературу, могут тратить 10% оплачиваемого рабочего времени на обучение и получают скидку в 50% на курсы английского языка.
Doubletapp на конференции DUMP
И мы, и большинство наших заказчиков заинтересованы, чтобы специалисты работали качественно и с удовольствием, потому что у нас общие долгосрочные проекты.
Почему алгоритмы решают твое будущее в аутстафе?
Начать с подготовки к собеседованию, и здесь главное — подтянуть алгоритмы, это один из ключевых навыков. На любом собеседовании есть алгоритмическая секция, как минимум пару задач решить придется. Поэтому с сотрудниками, которых мы готовим на аутстаф, обязательно проводим мок-собесы, выдаем набор алгоритмических задач и оплачиваем рабочее время, которое потребуется на их решение.
Принято думать, и я согласен с этим мнением, что в веб-разработке специфические алгоритмические знания на практике нужны в 2% случаев, а если и нужны, то какие-то несложные. Но это отличный способ проверить, как человек мыслит, как он способен подстраиваться под задачу и есть ли у него математический склад ума.
Вторая важная составляющая подготовки — показать заказчику релевантный опыт, заинтересовать его на этапе подачи резюме.Мы показываем проекты разработчика с лучшей стороны — подчёркиваем их интересные и сложные технические аспекты. Чтобы сделать резюме интересным, мы проводим встречу с сотрудником, на которой вместе актуализируем резюме в соответствии с новым опытом.
Грейды в разных компаниях: совпадают ли стандарты?
Наши внутренние грейды в Doubletapp идут зачастую с шагом в минус от того, что требуют корпорации, например, мы от мидл+ требуем, как на рынке требуют от сеньоров и так далее. Поэтому нередки ситуации, когда специалист, который у нас был мидлом, выходит на аутстаф-проект как мидл+/сеньор. Он прошел все этапы собеседований, HR-скрининги, алгоритмическую секцию и показал себя как сеньор, заказчик оценил его как сеньора. Соответственно, по грейдам заказчика он сеньор.
Бывают ситуации, когда в чем-то оценки грейда не совпадают, например, в апреле 2024 года мы вывели фронтенд-разработчика, заявив его как сеньора, но заказчик оценил его на уровне мидл+. Через четыре месяца мы вернулись с вопросом о пересмотре грейда. Заказчик собрал отзывы о сотруднике и подтвердил, что разработчик соответствует сеньорскому уровню, поэтому ему повысили и грейд, и уровень сложности задач, и ставку.
У нас в Doubletapp раз в полгода проходит performance ревью, которое сопровождается повышением грейдов. И хотя с большинством заказчиков у нас прописан договор на год, где указана ставка сотрудника и зафиксирован грейд, мы стараемся обсуждать повышение грейдов и договариваться о корректировке.
Почему аутстаферам предлагают уйти в штат (и что с этим делать)?
Попытки хантинга на аутстафе неизбежны, и мы все с этим сталкиваемся, но для нашей компании, которая вкладывается в сотрудников, это особенно неприятно. Некоторые стараются быть честными и открыто говорят о таких практиках, например, один из наших заказчиков прямо сообщает о готовности перевести аутстаф-специалиста в штат. Бывает, что и сами аутстаферы получают предложения сменить работодателя, даже несмотря на запреты в договорах — компании целенаправленно хантят перспективных специалистов.
Наши сотрудники тоже иногда получают предложение перейти в штат от заказчика, но, как правило, отказываются, так как им нравится работать именно у нас: в Doubletapp хорошая атмосфера, приятные люди, и компания берет на себя все заботы — от организации собеседований до решения конфликтов с заказчиками.
Аутстаф vs. штат: где больше возможностей?
Не было бы возможности поработать без всякого гемора со сменой работы над несколькими большими проектами в международных компаниях и поучаствовать в создании продуктов, которыми пользуются миллионы людей по всему миру.
То есть обычно же, если ты в бигтех устраиваешься, ты работаешь два-три года на одном проекте. А на аутстафе, когда контракт заканчивается, ты можешь пойти в другую компанию и точно так же работать уже над другим проектом. Это отличная возможность узнать, как бигтехи и другие IT-компании работают изнутри и познакомиться с крутыми людьми.
Остались вопросы? Если вы разработчик, присоединяйтесь к нашей команде, а если вашему бизнесу нужны IT-специалисты или сыгранная команда — стек технологий и ставки смотрите на сайте Doubletapp, бэнч специалистов ищите в партнёрском канале в Телеграм.
Источник: habr.com
Похожие новости:
Гиперперсонализация: как сделать предложение пользователю релевантным
«Слушая подкасты, ничего не узнаешь, ты должен устать, упасть без задних ног — такой должна быть встреча с образованием»
Уровень «цифровой зрелости» компаний в России выше, чем в среднем по миру
Технологии в агрокомплексе: мастера, подмастерье и искусственный интеллект