Почему компании работают с аутсорс-командами по 5–10 лет и не переносят задачи внутрь
Средняя длительность проекта в ADV — 4,5 года. И если вы задавались вопросом, почему бизнес работает с аутсорс-командами по 5–10 лет и не переносит эти задачи инхаус, то ответ вы найдёте в этой статье. Рассказываем, что заставляет компании работать с одними и теми же подрядчиками годами.
Представим, что существует фастфуд-сеть «Хурма-Шаурма». Чтобы развивать бизнес и продавать ещё больше вкусной шаурмы с бараниной, курицей, овощами и не только, сети ресторанов нужно выйти в онлайн. А значит, перед компанией стоит задача сделать приложение с возможностью доставки. Хотя у фастфуд-сети и есть своя большая IT-команда, которая сделала сайт с тем же функционалом, «Хурма-Шаурма» всё равно обращается к аутсорсу.
Почему «Хурма-Шаурма» нанимает аутсорс-команду на долгий проект
Когда бизнесу нужен сложный цифровой продукт, вроде доставки «Хурмы-Шаурмы», ему важна не только экспертиза подрядчика, но и способность команды пройти длинный путь без потери качества. А здесь уже не работает логика «если что — сменим исполнителя». И это легко подтверждается двумя основными факторами.
Долгий и сложный проект, на котором тяжело менять людей
Только на MVP кастомного приложения уйдёт 4–6 месяцев, а если говорить о полноценном запуске продукта, то по времени это занимает не меньше, чем полтора года. На таких дистанциях не получится менять людей в процессе. Любая замена — это откат назад на недели или месяцы, остановка работы, потеря контекста и повторная настройка процессов. Команда, которая начала проект, неизбежно нарабатывает знания о бизнесе, пользовательских сценариях и всех подводных камнях. А ещё — генерит новые задачи в процессе работы.
Говорить о замене команды можно только тогда, когда продукт полностью переходит на поддержку: когда всё построено, стабильно работает, а задачи становятся предсказуемыми и рутинными. На этапе активной разработки менять команду — всё равно что менять пилотов посреди перелёта. То есть в теории это возможно, но на практике проблематично и дорого.
Найм и онбординг — это тоже деньги
Аутсорс-команды забирают много головной боли у клиента. Например, «Хурме-Шаурме» под создание приложения для доставки нужно было бы нанять минимум 30 специалистов. А «нанять» значит: отсобеседовать, заонбордить и подождать, пока новые люди вкатятся в продукт, а возможно и в новую для себя сферу.
А когда бизнес приходит к аутсорс-команде, то объясняет только задачу: что хочет сделать и какой результат получить. Всё остальное — работа подрядчика.
Но эти факторы не говорят о том, что компания не может прекратить работу с подрядчиком, например, через полгода. Может — и у такого решения обычно похожие с другими проектами причины — рассказываем о них дальше.
Из-за чего «Хурма-Шаурма» может прекратить работу с аутсорс-командой
Если подрядчик не срывает сроки, не пропадает, следует договорённостям и делает обещанные задачи, то на долгом и сложном проекте объективных причин его менять нет. Но «Хурма-Шаурма» может это сделать, если произойдёт следующее:
- Сокращение бюджета. Если у «Хурмы-Шаурмы» резко падает выручка, дорожает сырьё или инвесторы требуют урезать расходы, аутсорс — первый под ударом: это предсказуемая строка расходов, которую можно быстро уменьшить. Это не про плохую работу аутсорса, а про управляемость. Возможность относительно безболезненно регулировать численность команды или вовсе отключить её на время — важное преимущество внешних команд. И именно эта гибкость всё чаще становится решающим аргументом в пользу аутсорса.
- Изменение внутреннего контекста у заказчика. В «Хурму-Шаурму» может прийти новый директор по цифровому развитию и привести свою команду — с ней комфортнее работать, он знает, какой результат от них ждать и это нормально.
Во многом эти две причины упираются в жизненный цикл компании. «Хурма-Шаурма», как и любой другой бизнес, развивается волнообразно: есть периоды, когда всё идёт в гору, а бывает и череда проблем, когда нужно чем-то жертвовать. Из-за этого проект могут передать более бюджетной команде или вовсе прекратить. Аутсорсу тоже нужно быть готовым к этому и понимать, как работать с проектами на длинной дистанции.
Как аутсорс-командам работать с ожиданиями заказчика на длинной дистанции
Очевидно, что в многолетних проектах меняется всё: задачи, приоритеты, сотрудники. И есть факторы, на которые ни одна аутсорс-команда повлиять не может — это, например, сокращение бюджетов. Но есть и то, что зависит от подрядчика даже в плохие времена. И вот, что можно сделать, кроме молитв, чтобы идти в ногу с условиями бизнеса:
- Быть в контексте и понимать, какие задачи стоят перед бизнесом. На длинных проектах со стороны заказчика меняются люди, роли, приоритеты — вчера продуктом занимался один человек, а сегодня приходит новый со своим видением и списком «срочно переделать». Аутсорсу важно не просто продолжать пилить задачи, а успевать подхватывать смену фокуса: ловить логику нового человека, быстро считывать, что для него важно, и перестраивать работу под обновлённый курс. Если команда и её цели остаются «вчерашними», то разрыв неизбежен. Поэтому подрядчику важно держать руку на пульсе, знать, что сейчас болит у клиента, и показывать, что вы решаете именно его текущие проблемы, а не пилите функционал по инерции.
- Иметь обкатанный план действий на случай, если что-то идёт не так. А иногда и никакая адаптация не помогает: например, когда никто не может договориться с новыми людьми. В этот момент важна не импровизация, а заранее подготовленный алгоритм: что делать, если всё идёт вразнос. Например, у нас в ADV это решается через управленческие встречи и более жёсткий контроль наших процессов для заказчика.
В общем, волшебной палочки, которая сделает так, что «Хурма-Шаурма» и другие клиенты будут оставаться с подрядчиками долго и счастливо — нет. Все кейсы разные и зависят от условий бизнеса и человеческого фактора. Зато аутсорс-команды точно могут совершенствовать то, что зависит от них: экспертизу и партнёрские отношения с проектом.
Над материалом работали директор по проектированию продуктов Алексей Шмелёв и операционный директор Михаил Парфенюк.