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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

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

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

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

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

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

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

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

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

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

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