Разработка IT-инструментов для бизнеса: аутсорс или инхаус?

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

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

В правом углу ринга — руководитель разработки в «Яндексе» Игорь Аскаров. В левом — руководитель проектной группы в arcsinus Андрей Головин.

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

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

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

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

При этом наём команды с нуля — непростая задача. Рынок перенасыщен джунами, а за более опытными разработчиками идёт настоящая охота. А ещё стоимость разработчиков постоянно растёт — крупные игроки выставляют высокую зарплатную планку. Стоит заложить дополнительные ресурсы на обучение и формирование команды — инженерам потребуется время, чтобы начать быстро понимать друг друга.

Собственная разработка может оказаться дороже аутсорса: это зависит от размера и сложности проекта.

Подрядчика, в отличие от разработчиков в штате, не нужно интегрировать в корпоративную культуру компании — это экономит время на онбординг, выстраивание коммуникации и процессов. У аутсорса есть готовые команды, которые можно быстро подключить к проекту, а если потребуется — так же быстро «отцепить».

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

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

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

Часто команде не хватает экспертизы в новом направлении и времени, чтобы разобраться в технологии, — бэклог забит на несколько месяцев вперёд. В этом случае проще и дешевле поручить задачу внешним разработчикам.

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

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

Если будущее продукта не определено, и бизнес хочет проверить гипотезу, ограничившись разработкой MVP, заказать проект у подрядчика дешевле, чем собирать под него команду.

Оба подхода к организации разработки имеют свои преимущества и недостатки.

Инхаус-разработка скорее подойдёт:

Аутсорс-команды помогают ускорить работу и оптимизировать издержки, когда: