Аутстафф-разработчик не работает в четырёх случаях. Все четыре на стороне заказчика

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

Мы в команде Фортех (fortech.dev) с 2017 года выводим разработчиков в чужие команды и видим одну закономерность. Когда аутстафф не взлетает, дело почти никогда не в квалификации специалиста. Его просто некуда было встроить. Ниже четыре ситуации, которые мы встречаем чаще всего, и что с ними делать.

Случай первый: задачи никто не ставит

Разработчик пришёл, доступы выдали, а бэклога нет. Есть устные пожелания продакт-менеджера, переписка в мессенджере и макеты, половина из которых устарела. Штатный сотрудник за год работы научился угадывать, что имеется в виду. Внешний человек угадывать не умеет и не должен.

Признак: первые две недели специалист «разбирается в проекте», а на созвонах выясняется, что он сделал не то.

Что помогает: у каждого внешнего разработчика должен быть один человек, который отвечает за его задачи. Не «вся команда», а конкретный тимлид или продакт. Задача пишется так, чтобы её мог понять человек без истории проекта: что сделать, где посмотреть, как понять, что готово. Если таких задач нет даже на две недели вперёд, сначала нужен порядок в бэклоге, а потом аутстафф.

Случай второй: нет ревью и общих правил кода

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

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

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

Случай третий: онбординг занимает дольше, чем подбор

Резюме кандидатов приходят за 1–2 дня, специалист готов выйти за 5 дней. Потом неделю ждёт доступ к репозиторию, ещё несколько дней к тестовому стенду, а VPN выдают через службу безопасности по заявке.

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

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

Случай четвёртый: купили руки, а нужна голова

Бывает, что аутстаффера берут закрыть дыру, которую должен закрывать архитектор или техлид. Например, проект без внятной архитектуры, а вы ждёте, что middle-разработчик «сам разберётся и наведёт порядок». Он разберётся в своей задаче. Наводить порядок в архитектуре его не просили и полномочий не дали.

Аутстафф хорошо масштабирует то, что уже работает. Если процесса нет, внешний человек ускорит хаос.

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

Как встроить внешнего разработчика: схема на первый месяц

До выхода. Тимлид заказчика готовит доступы, документ с правилами кода, задачи на две недели вперёд и назначает наставника.

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

Первая неделя. Наставник смотрит каждый запрос на слияние, короткие синки каждый день.

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

Конец месяца. Тимлид и менеджер подрядчика говорят о том, что мешает и что поправить в процессе.

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

История из проекта

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

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

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

Что сделать до того, как подписать договор

Аутстафф отлично работает как способ быстро усилить команду: наём senior-разработчика в штат занимает от 3 до 4 месяцев, а внешний специалист выходит за 5 дней. Если не подошёл, замена занимает до 3 дней. Но эти сроки имеют смысл, только если человеку есть куда выйти.

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