За что компании недолюбливают аутсорс и аутстаф и как стать IT-подрядчиком, с которым хотят работать

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

Привет, меня зовут Антон, я уже больше 10 лет в IT и успел поработать в управлении проектов Альфа-Банка, Яндекса и Сбера. В 2024 году стал предпринимателем и открыл свою компанию IT-консалтинга — «План Б». Наших клиентов консультируют топовые специалисты из Skillbox, Google, AliExpress и других гигантов IT-индустрии.

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

У меня накопилось много опыта с IT-подрядчиками, и я стал регулярно замечать типовые ошибки — собрал всё в этой статье, чтобы самому не забыть и поделиться опытом. Расскажу, что чаще всего бывает «сломано» в аутсорс- и аутстаф-компаниях и как это починить, чтобы заказчики хотели с ними работать.

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

Аутстаф выгоден, потому что поиск и наем ограничен бюджетом, а не количеством ставок. Если у вас есть бюджет в 1 000 000 рублей, то на эту сумму вы можете нанять любое число сотрудников. Пять, семь или вообще 10 индусов, главное — чтобы справлялись с задачей. При этом не нужно платить пенсионные и другие отчисления, а проект можно закрыть хоть завтра, потому что у вас нет трудового контракта с людьми.

Еще один плюс аутстафа — широкая воронка. Подрядчик может нанять сотрудников в любой точке мира: в России, Узбекистане или Индии. Юридически это не имеет значения для заказчика.

Теперь о проблемах 👇

Проблема: постоянная смена разработчиков на проекте.

Представьте: подрядчик устроил 10 разработчиков в компанию «Ромашка», а через неделю в аутстаф пришла корпорация с запросом на пять айтишников. Большинство подрядчиков заберут разрабов у «Ромашки» и отдадут их новому заказчику, потому что корпорации можно выставить больший чек. У сотрудников нет мотивации глубоко погружаться в проект, ведь через месяц их могут перекинуть в новую компанию — и так до бесконечности.

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

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

Мы в Сбере тоже столкнулись с текучкой разработчиков по вине аутстафа. Но я придумал, как это исправить: стали фиксировать, что решение об увольнении принимает либо заказчик, то есть я, либо сам разработчик, но не подрядчик. Разумеется, если все иные условия соблюдены. Это похоже на ипотеку, когда ставка фиксируется на момент подписания договора. И что бы ни происходило на рынке, ни ставка, ни банк не меняются внезапно — «любите друг друга, пока смерть не разлучит вас». Со своей стороны мы следим за профессиональным ростом сотрудника и оклада.

Решение на стороне заказчика: фиксируем решение о снятии разработчика с проекта только по желанию заказчика или самого разработчика.

Проблема: разработчика не мотивирует зарплата, а перспективы ее роста туманны. Последнее, возможно, даже важнее.

Заказчик платит напрямую подрядчику, а он — сотруднику. Если подрядчик забирает 70% гонорара программиста, минимальный процент, который остается программисту, вообще не мотивирует работать. Сотрудник обычно не в курсе этой схемы. И проблема не в том, что подрядчик слишком много откусывает. Если он может забирать маржу даже в 90% и делать сотрудников счастливыми, то всё круто. Но, как правило, так не бывает. Проблема в том, что остаток слабо коррелирует с рынком, особенно если сравнивать столицы и регионы. А вторая проблема — нет никакой схемы роста. Ни профессиональной, ни зарплатной. Потому что это сложная HR-работа, на которую подрядчики обычно забивают.

Похожая ситуация сложилась в Сбере. Мы раскопали это в личных беседах и попросили дикую для подрядчика вещь — поднять сотруднику зарплату за наш счет.

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

Проблема: аутстаф-сотрудники не чувствуют себя частью команды.

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

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

Решение на стороне заказчика: обеспечиваем аутстаф-сотруднику привилегии наравне со штатом. Это в том числе решает проблему потенциального перетока людей от подрядчика в штат. Многие этого боятся.

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

Банальные проблемы и креативные решения 👇

Проблема: аутсорс называет нереалистичные сроки и в итоге задерживает проекты.

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

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

Именно поэтому тут к проекту стоит подходить с экспертной точки зрения. То есть мы не отдаем на аутсорс то, что не понимаем, как делать и сколько это делать. Ровно наоборот. Мы делаем полную оценку самостоятельно и ищем подрядчика, который подходит под наше определение сроков и качества.

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

Решение на стороне заказчика: проводим реальную оценку сроков вместе с аутсорсом.

Проблема: аутсорс выдает совсем не тот результат, что был в ТЗ, а дедлайн — сегодня.

ТЗ помогает зафиксировать, каким заказчик хочет видеть конечный продукт. Но главная проблема — как подрядчик ему соответствует и когда это соответствие можно проверить. Узнавать, что там получилось на выходе, в день дедлайна заказчикам совсем не хочется. Именно поэтому мы никогда не отдавали на аутсорс что-то критически важное и добавляли в команду своего технического эксперта, который может в любое время ответить на вопрос, насколько проект сходится с ТЗ.

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

Решение на стороне заказчика: добавляем в команду своего тимлида.

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

Проблема: подрядчики показывают заказчику фейковые резюме сотрудников.

Представьте: заказчик приходит с запросом на 10 сеньоров. Подрядчик понимает, что у него есть только пять. Он берет за основу резюме сеньоров и буквально меняет в нем имя и пару рандомных фактов. Готово! Теперь у подрядчика есть все разработчики нужного уровня.

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

В итоге я просто стал относиться к подрядчикам как к кадровым агентствам — дополнительному источнику кандидатов к штатному рекрутменту.

Решение на стороне заказчика: проводить одинаковые собеседования и для кандидатов в штат, и для будущих аутсорс-сотрудников.

Советую работать над имиджем ваших разработчиков. Отправляйте их выступать на конференции, мотивируйте писать экспертные статьи на популярных у разработчиков ресурсах. Если сотрудники будут лидерами мнений в своей отрасли, выше вероятность, что к вам за ними на аутстаф придут корпорации, которые готовы платить за крутых ребят. Например, так делают TopTal, «Злые Марсиане» и X-Team. Как правило, от заказчиков поступают схожие заказы. Инвестируйте в технические решения, которые помогают и вам, и заказчику в реализации проектов. Вкладывайтесь в open source. Всё это добавляет вес и цену.

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

Если хотите больше практических советов, подписывайтесь на мой телеграм-канал IT для бизнеса :// Антон Виноградов. Там пишу про решения, которые помогают бизнесу расти и зарабатывать.