Аутстафф: одна команда, два работодателя

Второй пост из серии про типы команд.

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

Это самая распространённая модель в крупных компаниях. И самая коварная потому что выглядит как единая команда, а управляется как две.

Зачем вообще миксуют. Бизнесу нужна скорость — штатный найм не успевает. Или бюджет выделен на проект, а не на расширение штата. Или нужна экспертиза, которой внутри нет. Причины разные, результат один — в твоём спринте сидят люди с разными работодателями. Что работает Скорость старта. Подрядчики закрывают дефицит быстрее, чем найм в штат. Подрядчик выделяет специалиста из своего штата или ищет на рынке, принимая на себя все риски — вплоть до отказа кандидата на этапе оффера. Но профили ролей и описание вакансии готовит заказчик — это важный момент, который часто упускают.

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

Свежий взгляд. Люди из других проектов приносят практики, о которых инхаус-команда могла не знать.

Где обычно болит. Два контекста. Штатные знают продукт глубоко, подрядчики — поверхностно. Со временем разрыв растёт, если с ним не работать.

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

Двойное управление. У подрядчика есть свой линейный руководитель, свои процессы согласования отпусков, свои правила. Тимлиду нужно выстроить отношения не только с командой, но и с ресурсными менеджерами на стороне подрядчика. И не формально, а так, чтобы тебя слышали.

Операционка множится. Таблица отпусков, отгулов, контактов на случай экстренной связи, рискует переехать во внешний контур, потому что вести две неудобно, хотя команда как будто одна. Важно с самого начала организовать единый инфраструктурный слой — хранилище кода, CI/CD, трекер, вики. Это можно разместить как на мощностях заказчика, так и на стороне подрядчика. Обычно выбирают где проще и дешевле. Code review. Стандарты кода у штатных и подрядчиков часто разные. Без жёстких гайдлайнов и линтеров — ревью превращается в бесконечный пинг-понг.

Как с этим жить Тех-лиды в штат при наличии бюджета. Это люди, которые держат архитектуру и стандарты. Эти же люди потом садятся на третью линию поддержки. Так формируется сильное ядро внутри — что всегда в плюс. Но это не значит, что подрядчики пилят только простые задачи! Распределение должно быть по компетенциям, а не по типу договора.

Единые стандарты кода — не рекомендация, а требование.

Онбординг для подрядчиков — такой же, как для штатных.

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

Код — заказчику. Об этом договариваются на старте, а не при расставании. Хранилище на стороне заказчика, версионность обязательна и вся экспертиза и кодовая база остаются внутри, даже если пишут её подрядчики.

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

Следующий пост про аутсорс — когда проект передают в разработку целиком.

А у вас как — штатные и подрядчики сработались или живут параллельно?