Инхаус-команда "зажралась": когда бизнесу нужна выделенная команда разработчиков

Игорь Бахарев

Генеральный директор Creonit Антон Макаров рассказал, в каких случаях бизнесу нужна аутсорс-команда разработки, от каких головных болей она избавит, каким образом ускорит процесс разработки и кому такая модель работы не подойдёт. Показываем на четырёх реальных примерах из сферы e-commerce.

Компания Creonit разрабатывает цифровые сервисы и работает с крупными заказчиками, такими как: ВТБ, НСПК (СБП), FixPrice, Faberlic и другими. Мы видели многие продуктовые проблемы изнутри, а также помогали их решать. В статье собрали топ проблем, с которыми сталкиваются крупные компании при разработке и развитии продуктов. Возможно, наш опыт убережет вас от ошибок и поможет определиться, когда стоит выкупать аутсорс-команду, а когда есть смысл расширять инхаус-команду.

Что такое выкуп команды и какие у него плюсы

Выкуп команды - это формат работы, когда одна компания выкупает команду разработки у другой для решения бизнес-задач. 

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

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

Плюсы такого взаимодействия: 

- выстроенные процессы разработки и менеджмента и умение ими управлять;

- быстрая поставка фич в продакшн;

- снятие головной боли с заказчика по поиску и содержанию команды.

На примере наших клиентов рассмотрим несколько самых популярных проблем, которые можно решить с помощью выкупа аутсорс-команды. 

Пример 1: инхаус команда "зажралась" и работает медленно

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

В компании возникла проблема с медленной поставкой новых фич в продакшн. Ситуация усложняла запуск новых сервисов и развитие работающих. 

Заказчик обратился к нам с запросом выкупа команды разработки. Мы работали в своём обычном темпе, но скорость выполнения задач была на 40% выше, чем у инхаус-команды. Это позволило ускорить запуск новых проектов.

Почему инхаус-команды могут работать менее эффективно, чем аутсорс

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

1. Ограниченный опыт инхаус-команды. У аутсорс-команды более широкий кругозор и опыт в разработке за счет разнообразия проектов. Инхаус-команда ограничена проектами своей компании.

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

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

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

Пример 2. Запуск нового продукта: нет времени или ресурсов искать инхаус-команду, редкий стек 

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

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

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

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

Заказчику не нужно париться, будут ли у подрядчика, например, php-специалисты, будут ли они увольняться, болеть, уходить в отпуск. Не нужно размещать вакансии и следить за удовлетворенностью сотрудников. Всё делает подрядчик. Заказчик всегда получает результат, а подрядчик отвечает за HR, компетентность своих сотрудников и процесс разработки.

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

· Выстроенный процесс разработки и менеджмент. Не нужно никого обучать: команда приходит и сразу после получения информации может начать работу - нужно только обеспечить доступы.

· Стек и заимствованная экспертиза. Есть не очень популярные технологические стеки. Во многих случаях сложно искать и нанимать разработчиков. 

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

Ещё пример: в неизвестный или малоизвестный стартап тяжело найти команду специалистов. Люди хотят стабильности, за выход в стартап часто приходится сильно переплачивать. А у нас хорошо отстроен найм, есть большая команда для решения задач.

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

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

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

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

Когда скорость играет решающую роль в выходе на рынок и лидерстве продукта - выделенная команда разработки может стать лучшим решением.  

Пример 3: когда нужно больше, чем FixPrice

Герой нашей третьей истории - маркетплейс авторского контента. После февраля 2022 на платформе кратно вырос трафик, что потребовало большего вовлечения команды, чем работа в формате FixPrice.  

Сначала мы работали по модели FixPrice и делали задачи итерационно. Последние полтора года работаем по модели выкупа команды. Бизнес набрал обороты, небольшой проект вырос в устойчивый продукт. Стало понятно, что у него есть потенциал, в который можно вкладывать деньги. Для выполнения задач понадобилась аутсорс-команда.

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

Выделенная команда нужна была, чтобы: 

·         сократить сроки поставки фич в продакшн;

·         выстроить плотную коммуникацию бизнеса с командой разработки;

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

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

Например, заказчик покупает 10 задач в месяц у подрядчика на 50 часов. Задачи внесены в планы, разработчики распределены также на другие проекты и задачи. 

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

В остальном плюсы те же самые - заказчику не нужно набирать самостоятельно команду и заниматься ее поддержкой и менеджментом. 

Формат работы выделенной команды - версионная разработка

На проекте с маркетплейсом авторского контента мы организовали версионную разработку. 

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

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

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

Пример 4: когда устраивает выделенная команда и нет смысла нанимать инхаус

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

Заказчик принял решение не собирать инхаус команду для продолжения развития проекта, а оставить текущую аутсорс-команду разработчиков. Она уже знакома с проектом и эффективно управляется менеджером. Клиент продолжает следить за продуктовыми метриками, проводить тестирование гипотез, вносить изменения в бэкофис. При этом заказчик уверен, что задачи по веб-сервису будут реализованы в срок, общая дорожная карта проекта не "уедет". 

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

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

Итого

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

Выделенная команда разработки подойдет в следующих случаях: 

·         У вас много задач, а внутренние команды не справляются с нагрузкой. 

·         Вы запускаете новое направление, пилотный или сайд-проект.

·         Вам нужно максимально быстро решать задачи и масштабироваться.

·         Вы хотите заменить команду разработки и пока не готовы к полноценному инхаусу.  

Преимущества выделенной команды разработки: 

·         Быстро выводим команду на проект. 

·         Расширяем или уменьшаем состав команды по необходимости.

·         Отвечаем за результат, а не просто предоставляем ресурсы. 

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

·         Работаем с другими командами. Встраиваемся в существующие процессы, взаимодействуем с заказчиками в едином пространстве. 

·         Строим процессы работы с нуля. Передаем в инхаус по мере роста проекта и необходимости.

Материал по теме

Системы MDM в российских реалиях: чек лист и несколько рекомендаций

Материал по теме

Нейросети в продажах. Как ИИ решает задачи продавцов на маркетплейсах

Материал по теме

Как сделать прогноз эффективности трафика из соц. сетей на товарные карточки Ozon

Подписаться на новости

Актуальное сейчас

Приглашаем позавтракать с АЭРО!

Друзья, за последний год мы нередко проводили вечера вместе на митапах и решили, что пришло время вывести наши отношения на новый уровень и... вместе позавтракать! 28 июня мы с Rubbles приглашаем вас на би...

Запрос общества на развитие маркетплейсов: аналитика

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

Тенденции рынка eCommerce 2024: мнения экспертов

Участники конференции Supply&Demand Planning Conference (Сколково) из "Пятерочки", "Магнита", "Яндекс.Маркет", "Объединенных пивоварен", NielsenIQ, "Юнилевер Русь" и других компаний-лидеров рынка представили св...

"Мы хотим создать экосистему-маркетплейс для развивающихся стран": Линар Хуснуллин (ex-KazanExpress) о своём новом проекте

1 августа в Казахстане стартует новый маркетплейс Teez, созданный основателем KazanExpress Линаром Хуснуллиным. Бизнесмен дал интервью, в котором рассказал о подробностях проекта.  Teez позиционирует...

Логистика для онлайн-магазинов: рейтинг по стоимости доставки

Основатель проекта Main Transport Роман Судоргин опубликовал результаты ежегодного рейтинга стоимости перевозки сборных грузов весом от 1 до 150 кг по России. Базой для рейтинга являются цены на доставку по 3,9...

Как информация о товарах драйвит доверие к селлерам: аналитика НАФИ

Аналитический центр НАФИ составил рейтинг факторов, формирующих доверие продавцам товаров и услуг  в интернет-магазинах и на маркетплейсах. Основой вывод исследования: оказалось, что возможность получить полную...

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

×

Физическое лицо, оставляя заявку на веб-сайте e-pepper.ru через форму «Обсудим ваш проект» и форму подписки на e-mail рассылку, действуя свободно, своей волей и в своем интересе, а также подтверждая свою дееспособность, предоставляет свое согласие на обработку персональных данных (далее — Согласие) Обществу с ограниченной ответственностью «АЭРОКОМ» (ООО «АЭРОКОМ») (ИНН 9705136776, info@aeroidea.ru, +7(495)120-12-38, +7 968 900-23-45), которому принадлежит веб-сайт https://e-pepper.ru и которое зарегистрировано по адресу 111024, г. Москва, вн.тер.г.муниципальный округ Лефортово, ул. Авиамоторная, д.50, стр.2, этаж 2, помещ.XI, комната 25, офис А79, на обработку своих персональных данных со следующими условиями:

  1. Данное Согласие дается на обработку персональных данных, как без использования средств автоматизации, так и с их использованием.
  2. Согласие дается на обработку следующих моих персональных данных: персональные данные, не относящиеся к специальной категории персональных данных или к биометрическим персональным данным: адрес электронной почты (e-mail); имя; сведения о месте работы; номер мобильного телефона.
  3. Цель обработки персональных данных: обсуждение возможного проекта.
  4. В ходе обработки с персональными данными будут совершены следующие действия: сбор; запись; систематизация; накопление; хранение; уточнение (обновление, изменение); извлечение; использование; передача (предоставление, доступ); блокирование; удаление; уничтожение.
  5. Третьи лица, обрабатывающие персональные данные по поручению ООО "Аэроком” для указанной в согласии цели:
    • АО "АМОЦРМ", 21205, г. Москва, вн.тер.г. Муниципальный Округ Можайский, Тер Сколково Инновационного Центра, б-р Большой, д. 42 стр. 1
    • ООО "Яндекс", 119021, г. Москва, ул. Льва Толстого, д. 16
  6. Персональные данные обрабатываются в течение 30 дней с момента отказа в дальнейшем обсуждении проекта или с момента принятия решения о заключении договора на проект в соответствии с ч. 4 ст. 21 152-ФЗ, смотря что произойдет раньше.
  7. Согласие может быть отозвано вами или вашим представителем путем направления ООО "Аэроком” письменного заявления или электронного заявления, подписанного согласно законодательству Российской Федерации в области электронной подписи, по адресу, указанному в начале Согласия.
  8. В случае отзыва вами или вашим представителем Согласия ООО "Аэроком” вправе продолжить обработку персональных данных без него при наличии оснований, указанных в пунктах 2 — 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 Федерального закона № 152-ФЗ «О персональных данных» от 27.07.2006 г.
  9. Настоящее согласие действует все время до момента прекращения обработки персональных данных, указанных в п. 6 и п. 7 Согласия.