Собственная команда разработки или аутстаффинг: как не потерять миллионы? Интервью с директором по развитию Софт Медиа Груп

Типовой вопрос для сотен компаний: держать ИТ‑специалистов в штате, привлечь дополнительные ресурсы или отдать проект на внешнюю реализацию? Своим опытом в интервью поделился Артем Поляков, директор по развитию компании Софт Медиа Груп.

Когда собственная команда разработчиков действительно оправдана

В каких случаях оправдана собственная команда разработки?

Поговорим про стоимость дальше. Есть ли ситуации, где свой штат прямо необходим?

Да, такие примеры есть. Например, у вас банковское приложение. Его уже несколько лет разрабатывает команда, разбирающаяся во всех нюансах. Они писали код, знают стек, архитектуру и прочее. Если просто взять другую команду, даже опытную, она потратит время. Для чего, если текущая команда справляется?

Второй момент — вопрос безопасности. Ни один собственник не хочет, чтобы его Core Unit в такой ситуации ушел к конкурентам.

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

Ну и еще один важный момент, четвертый. У команды есть квалифицированный человек, отслеживающий эффективность сотрудников, и в целом выстроена система контроля.

Вот эти четыре пункта — прямо идеальный сценарий для существования инхаус‑команды.

Когда вместо собственной команды стоит рассмотреть аутстаффинг или аутсорсинг

В каких случаях аутстаффинг или аутсорсинг выгоднее собственной команды?

Посмотрим также на реальных примерах.

Ситуация первая. Текущая команда развивает и поддерживает, допустим, интернет‑магазин, уже не первый год. Бизнес развивается, и появляется новая задача: нужно разработать мобильное приложение на каком‑то стеке. Или скажем, внедрить ИИ в ответы техподдержки. Срок реализации — 6 месяцев.

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

Очевидно, что найти специалиста за столь короткий срок — довольно сложная задача.

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

Какие еще примеры можно выделить?

Вторая ситуация, типовая для стартапов. У проекта есть инвестор. Он согласен прямо сейчас вложить определенную сумму денег, набрать специалистов в штат и посмотреть на результат через время. Но…

Проект не взлетает?

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

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

Есть еще третий сценарий, тоже очень распространенный. Скажем, речь опять идет про интернет‑магазин. Есть инхаус команда, работает на проекте уже не один год. Бизнес хочет внедрить какой‑то функционал. Стек понятен, есть кому реализовать. Но ответственный за разработку говорит: «Это займет три года».

И бывает так, что собственник не знает, адекватные ли это сроки. Может быть, задача реально настолько долгая и сложная? И отвечает: «Ладно». Хотя по факту, у квалифицированных разработчик это заняло бы значительно меньше времени.

Почему разработчики на аутстаффинге могут работать быстрее штатных

Как получается, что разработчики на аутстаффинге работают быстрее штатных?

Проблема в том, что у бизнеса нет понятных инструментов отслеживания эффективности сотрудников. Один разработчик пишет код восемь часов, качественно, по всем правилам. Другой выделяет на программирование только 3‑4 часа времени.

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

Такая ситуация может продолжаться годами, пока компания теряет миллионы

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

Насколько обычно отличается время выполнения одних и тех же задач?

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

Почему так происходит:

1. Аутсорс‑разработчики мотивированы сделать быстро и качественно, чтобы получить оплату.
2. Разработчики не работают в вакууме, как порой бывает с инхаус‑командой. Есть выстроенная система контроля качества, прозрачная система отчетности. Бизнес всегда может посмотреть, чем занимался конкретный программист, какие задачи закрыл. Бывает, что один аутстаф‑специалист по производительности сопоставим с двумя‑тремя штатными.
3. На аутстаффинге люди подбираются под проект. Нужно реализовать фронтенд на React? Интегрироваться с SQL базой по API? Организовать CI/CD? На каждую задачу есть исполнитель.
4. Аутстаф разработчики работают с большим количеством проектов, и в целом имеют более высокую насмотренность, чем у инхаус разработки.
5. Это репутационная составляющая. Если внешний подрядчик не справится с проектом, к нему вряд ли обратятся другие компании.

Ограничения и риски аутстаффинга и аутсорса: что важно учитывать бизнесу

Мы обсудили преимущества. А какие ограничения есть у аутстаффинга и аутсорса?

Что это значит на практике?

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

А есть ли разница в уровне погружения в продукт между инхаус и внешней командой?

Да, и довольно существенная. Внешняя команда почти всегда хуже погружена в продукт — особенно если она подключилась не с нуля или работает меньше полугода. Чтобы делать качественные решения, нужно понимать внутреннюю кухню и бизнес‑контекст. Здесь инхаус‑команда выигрывает.

Какие еще есть риски?

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

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

Есть мнение, что в аутсорсе можно потерять контроль над процессом. Это так?

Такой риск есть. Подрядчик может формально выполнить ТЗ, но не до конца попасть в бизнес‑цель, если задача изначально поставлена размыто.

Но важно понимать: инхаус от этого тоже не застрахован. Практика показывает, что большинство проектов — и инхаус, и аутсорс — с первого раза попадают «не туда».

Как бизнесу выбрать модель разработки

Давайте поговорим по поводу стоимости. Что и в каких ситуациях выгоднее?

Допустим, средняя зарплата разработчика в инхаус‑команде — 160 тысяч рублей на руки. В месяце, в среднем, 160 рабочих часов. Значит, час стоит условно 1000 рублей. На проекте трудится два человека, затраты — 320 тысяч рублей.

Средняя стоимость услуг аутстаф‑разработчика по рынку — 2500 рублей в час, в 2,5 раза больше. Зарплата одного при полной загрузке в месяц — 400 тысяч, или 800 тысяч на двоих.

Но можно еще учесть нюансы: налоги и социальные отчисления (для бизнеса 160 000 рублей превратятся в другую сумму), прибавить стоимость потраченного времени со стороны HR‑отдела и руководителя этих разработчиков. И вот уже разница получается уже не в 2,5 раза, а меньше.

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

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

Что в итоге бизнесу нужно делать? Давай подведем итоги.

Во многих ситуациях инхаус вне конкуренции. Например:

• долгоиграющий проект с понятным стеком и архитектурой;
• есть стратегия загрузки команды;
• нет горящих сроков;
• недопустимо потерять Core Unit.

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

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

Но бывает и так, что переформатирование команды — единственный выход. С кем‑то нужно прекращать сотрудничество и менять модель управления.

Какие рекомендации можно дать по поводу переформатирования команды?

Есть три базовых сценария.

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

Если экономика совсем не сходится, отдавать всю разработку на аутсорс, оставив в штате только системного администратора.

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

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

Сценарий третий. По скорости вопросов нет, но затраты на IT слишком высокие. Нужно разобраться, где «узкое горлышко».

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

Что бы вы посоветовали собственникам бизнеса и топ‑менеджмента?

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