Разработка продукта: инхаус vs. аутсорс

Что лучше: нанять стороннюю команду разработчиков или собрать свою? Ответ на этот вопрос зависит от множества переменных. И независимо от того, что вы выберете, придется идти на компромиссы. Предлагаем разобраться в вопросе, двигаясь от простого к сложному.

Что такое инхаус и аутсорс в разработке

Инхаус и аутсорс — два разных подхода к разработке программного обеспечения. 

Инхаус — внутренняя разработка

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

Аутсорс — внешняя разработка

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

На какие вопросы нужно ответить до того, как выбирать между инхаусом и аутсорсом

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

Кто вы?

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

Какой продукт хотите создать?

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

Какой бюджет готовы потратить?

Ответьте себе честно: какую сумму вы готовы вложить в разработку продукта? Если финансовые ресурсы ограничены, аутсорс может быть более предпочтительным вариантом, так как позволит сэкономить на зарплатах внутренней команды разработчиков, тимлида и HR (не говоря уже о временных затратах на найм и раскачку команды). Если же вы располагаете достаточным бюджетом, чтобы покрыть расходы и на создание продукта, и на содержание команды, есть смысл дальше смотреть в сторону инхауса. 

Есть ли у вас команда разработки?

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

Есть ли у вас менеджер для управления командой разработки?

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

Инхаус и аутсорс: преимущества и недостатки

С базовыми вопросами разобрались, настало время подробнее разобраться в плюсах и минусах обоих вариантов. 

Чем хорош инхаус

У компаний, которые решили пойти по пути создания собственной команды разработки, есть объективные преимущества:

• Полный контроль над командой. Есть четкое понимание, что команда работает над задачами конкретного продукта, нет конкуренции в приоритетах с сопутствующими проектами.

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

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

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

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

Что не так с инхаусом

Если говорить о недостатках разработки силами своей команды, то они тоже довольно весомые:

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

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

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

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

• Отложенный результат. Если отдел разработки приходится создавать с нуля, потребуется время, чтобы работа встала на ровные рельсы. Готовьтесь платить зарплату HR в течение пары-тройки месяцев, не сильно рассчитывая на набор. И даже когда вы наймете разработчиков, командой они станут не сразу. Им нужно будет сработаться, научиться выстраивать процессы и распределять ответственность внутри команды.

Чем хорош аутсорс

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

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

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

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

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

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

Что не так с аутсорсом

Свои особенности в работе с командой подрядчика тоже есть:

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

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

• Передача информации третьим лицам. Нужно соблюдать дополнительную осторожность в работе с конфиденциальной информацией и интеллектуальной собственностью, передаваемой сторонним разработчикам. При составлении контракта стоит согласовать условия NDA (соглашения о неразглашении информации).

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