IT‑аутсорсинг: зачем передавать разработку продуктов внешним командам

Инхаус против аутсорса — вечная дилемма для тех, кто делает IT‑продукты. Особенно в крупных компаниях, где внутренние команды загружены развитием core‑систем. Стоит ли отвлекать их на эксперименты и MVP, которые могут не взлететь? Или передать задачи внешним подрядчикам — чтобы сохранить и фокус, и темп?

Мы в Purrweb уже 11 лет занимаемся аутсорс‑разработкой. Но когда аутсорс‑команды рассказывают о преимуществах своей работы, кажется, что это не очень объективно.

Поэтому мы пообщались с представителями крупных российских компаний — Skillbox holding, DocMa, Lamoda и «Литрес». Узнали, когда они обращаются к внешним подрядчикам, какие преимущества видят в этом и почему не всегда получается делать быстро с инхаус‑командами.

Статья будет полезна продуктовым менеджерам, тимлидам, CTO которые понимают, что нужно разгружать бэклог задач внешними силами, но не знают, как защитить перед руководством бюджет и идею того, что нужен аутсорс.

Что происходит на рынке IT‑аутсорсинга

C 2021 по 2025 мировой рынок IT‑аутсорса вырос на 131%. Согласно BusinesStat, в 2024 году объем российского рынка достиг 262 млрд рублей. Это на 22% больше по сравнению с 2023‑м.

Компании ищут партнеров, которые понимают специфику отрасли и могут предложить эффективные решения.

Почему корпорации передают разработку на аутсорсинг

Игорь Мелех, CPO в Skillbox holding, выделяет 4 сценария, когда стоит рассматривать найм внешней команды.

Эксперт из Lamoda добавляет.

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

1. Внутренняя разработка может привести к денежным потерям, если продукт не станет успешным.
2. No‑core проект отвлекает ресурсы от более приоритетных задач;
3. Сотрудники, долго работающие в одной сфере, могут не видеть очевидных рисков и возможностей.
4. Новый продукт требует стартап культуры — гибких методологий и быстрого принятия решений — и в корпорации с устоявшимися процессами проект может «утонуть» в бюрократии.

Также аутсорсинг помогает быстро найти команду с необходимыми навыками и технологиями — не нужно тратить месяцы на поиск, отбор и адаптацию новых сотрудников. Заказчик сразу получает опытную команду с выстроенными процессами. Так, Борис Панинян подчеркивает, что искать аутсорс‑команду стоит, когда нет уверенности, что продукт долгосрочный. Например, в компании запускают MVP, и непонятно, как он будет развиваться дальше. А найм команды занимает минимум полгода, и за это время новый продукт может стать неактуальным.

Другой кейс — когда нужно быстро сделать новое внутреннее решение, а инхаус‑команда занимается приоритетными задачами. С такой ситуацией столкнулась компания Smartway Travel Group — лидер бизнес‑тревел сегмента в РФ. Компании нужно было уходить с коробочного зарубежного решения Intercom и создавать свое.

Инхаус‑команда занималась основным продуктом, и разработка заняла бы больше года. Тогда заказчики решили делегировать задачу на аутсорс. Продукт был готов меньше чем за 9 месяцев, включая релиз. В проекте участвовало более 20 человек.

Почему инхаус‑команды не всегда справляются

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

Кроме того, внутренние IT‑отделы обычно заточены под поддержку и развитие текущих продуктов. Команды годами работают в рамках одного продукта и технологической культуры. Их задачи однородные и предсказуемые. Сотрудники становятся экспертами в своей узкой области, но могут испытывать нехватку навыков для решения новых задач.

Настя Уткина, CPO B2B в Lamoda, также отмечает момент, когда «появляется зависимость от одного‑двух разработчиков». Это называется bus factor. Он показывает, насколько проект зависит от важных сотрудников, так как они владеют не только навыками, но и контекстом продукта.

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

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

Сигналы, что разработку стоит передать на аутсорс

Обратимся к опыту руководителей и посмотрим, какие признаки они выделяют.

Настя Уткина, CPO B2B в Lamoda, упоминает два сигнала. Когда бэклог растет быстрее, чем его успевают разбирать, и критические функции висят в работе месяцами. Александр Качурин, CTO в DocMa, тоже делает акцент на скорости, но рассматривает другой аспект — сроки.

Игорь Мелех, CPO в Skillbox holding, также выделяет давление по срокам и добавляет еще 3 сигнала:

• нужна экспертиза, которой нет внутри;
• бизнес планирует запуск второстепенного проекта;
• внутренние процессы делают запуск в три‑четыре раза длиннее, чем он мог бы быть.

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

Аутсорсинг дает компаниям 4 преимущества:

1. Скорость старта. Аутсорсинг поможет обойти бюрократию и цепочку согласований, характерные для крупных компаний. Команда подключится к проекту в течение 1‑2 недель.
2. Доступ к специализированным знаниям. Можно привлечь команду с опытом в узких областях, чтобы закрыть задачи, для которых нет компетенций внутри компании.
3. Фокус на core‑продукте. Компания не перегружает инхаус‑команду и концентрируется на развитии продуктов, которые приносят основной доход.
4. Снижение затрат. Компания платит за время, потраченное на разработку, и результат. Не нужно выделять бюджет на найм дополнительных сотрудников и регулярно платить зарплату.

Игорь Мелех, CPO в Skillbox holding, выделяет преимущество скорости как основное: «Вы можете не ждать месяцами, пока наймете команду, а включить «второй двигатель» здесь и сейчас. Иногда это про запуск нового продукта, иногда про усиление текущего или ускорение масштабирования».

Как выстроить работу с аутсорс‑командой

Здесь можно выделить 6 шагов.

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

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

Обеспечьте полный доступ к материалам проекта: трекерам задач, папкам с файлами, репозиториям кода и документации. Договоритесь использовать общую доску для отслеживания прогресса. Это предотвратит задержки и поможет каждому участнику видеть общую картину и чувствовать себя частью одной команды.

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

Внедрите цикл встреч: ежедневные созвоны для синхронизации внутри команд, еженедельные викли с заказчиком. Так вы сможете поддерживать ритм работы и прозрачность.

Когда проект завершается, нужно подготовить его к передаче в инхаус.

Запросите у подрядчика документацию: доступы, экраны и UI‑kit, описание багов и тест‑кейсы. Проведите онбординг‑созвоны для своей команды с участием аутсорс‑специалистов для передачи знаний. Организуйте временный чат для поддержки.

Типичные ошибки при передаче на аутсорс

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

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

Александр Качурин, CTO в DocMa считает, что выбор подрядчика без подходящего опыта — главная ошибка. В этом случае заказчик фактически оплачивает обучение чужой команды. Спикер сравнивает это с выбором прораба и бригады для строительства дома.

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

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

Ошибка 3. Нечеткие требования. Отсутствие четкого видения проекта приводит к бесконечным правкам, несовпадению ожиданий и результата. Это, в свою очередь, ведет к перерасходу бюджета и срыву сроков. Вы получите не то, что хотели, а то, что понял подрядчик. При этом «полировать» ТЗ до мельчайших деталей тоже не стоит.

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

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

Вывод

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