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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 1. Инхаус команда «зажралась» и работает медленно

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

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

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

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

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

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

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

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

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

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

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

  • Заказчик снимает с себя головную боль по поиску и сбору команды. Клиент покупает услугу выкупа команды и полностью делегирует процесс подбора и вывода подрядчику. Подрядчик отвечает за то, чтобы в команде всегда хватало специалистов, может быстро расширить или уменьшить размер команды. Выделенный менеджер координирует работу команды и работает по своим внутренним процессам, которые может интегрировать к заказчику. Заказчику не нужно париться, будут ли у подрядчика, например, php-специалисты, будут ли они увольняться, болеть, уходить в отпуск. Не нужно размещать вакансии и следить за удовлетворенностью сотрудников. Всё делает подрядчик. Заказчик всегда получает результат, а подрядчик отвечает за HR, компетентность своих сотрудников и процесс разработки.
  • Быстрый выход команды. Выделенная команда разработки может стартовать проект сразу: все необходимые процессы уже выстроены, есть менеджер, который контролирует работу команды и занимается всеми текущими задачами по проекту. У менеджера продукта или руководителей на стороне заказчика есть возможность заниматься более важными стратегическими задачами.
  • Выстроенный процесс разработки и менеджмент. Не нужно никого обучать: команда приходит, проводит брифинг и аналитику, а сразу после получения информации может начать работу — нужно только обеспечить доступы.
  • Стек и заимствованная экспертиза. Есть не очень популярные технологические стеки. Во многих случаях сложно искать и нанимать разработчиков.

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

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

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

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

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

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

Пример 3. Когда нужно больше, чем Fixed Price

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее про этот кейс можно почитать по ссылке на сайте.

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

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

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

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

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

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

Итого

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

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

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

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

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

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

Больше контента с интересными кейсами, решениями, лайфхаками и материалами о ведении проектов в IT можно прочитать в нашем телеграм-канале.

3131
24 комментария

Жила-была аутсорс-команда разработчиков из сопредельных стран, фигачила тонны кода, выкатывала фичи. А тут 24 февраля, аутсорсеры технично сливаются.

Инхаус-команда, перекинутая на тот проект, была в полном шоке от мириад тонн говна и костылей, которыми аутсорсеры закидали продукт. SOLID, KISS, DRY - шутка чи шо? Инхаусу требовалось гораздо больше времени на реализацию функциональности, на который аутсорсеры не закладывались. С точки зрения бизнеса это как раз выглядит, что инхаус зажрался, нужно возвращать тех прекрасных аутсорсеров или искать новых.

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

7

Полностью согласен, особенно с последним тезисом)
Но я про другое писал: когда инхаус очень долго делает фичи и дело не в стандартах кодинга, а в том, что нет кого-то, кто пушит команду по срокам.

1

Да и мы часто встречаем такое, когда проект от одного аутсорсера переходит к другому, а там всё что вы описали...

Проект продукту рознь. Договоренность на "берегу" по требованиям со стороны СТО, составление проектной документации, выборочное кодревью лидом со стороны клиента — и нет проблем. Погонщик тратит минимум времени

1

А если подрядчик зажрался и любит накидывать х2 часов на простейшие задачи?

4

Вы работаете по FixPrice?

а вы как заказчик или подрядчик интересуетесь?)

1

Поменяйте подрядчика))