Как будем считать

Не секрет, что зарплата, которую получает на руки штатный разработчик — лишь часть затрат компании. Если, конечно, она не платит «в конверте». За каждого сотрудника работодатель также вносит страховые взносы и НДФЛ*, дает ему отпуска, оплачивает праздничные дни и больничные. В результате каждые 10 000 рублей зарплаты сотрудника превращаются примерно в 17 500 рублей затрат компании. А есть еще дополнительные накладные расходы: стоимость найма сотрудника, аренда офиса, обучение персонала, печеньки в офисе и корпоративы.


* Де-юро этот налог удерживается из зарплаты сотрудника. Но так уж сложилось в IT, что сотрудники ожидают получить на руки сумму, на которую они договаривались при найме. Поэтому де-факто работодатель берет эти затраты тоже на себя. Все наши расчеты учитывают этот нюанс.

За основу расчетов можно взять среднерыночную стоимость часа работы IT-специалистов из исследования рекрутингового агентства NewHR. Но в случае с инхаус-командой к этим цифрам нужно прибавить упомянутые выше дополнительные выплаты работодателя. В результате получаем вот такой «прайс»:

Небольшой проект (например, интернет-магазин с базовой функциональностью) может выполнить команда из четырех специалистов: проджект-менеджер, iOS- и Android-разработчики, бэкенд- или фуллстек-разработчик. Правда, часть ролей им придется совмещать — кому-то понадобится сделать предпроектную аналитику или выполнить тестирование продукта.

Однако на более серьезных проектах (там, где требуется изучение предметной области и интеграция с другими системами) совмещать задачи будет сложно. Команду придется расширить и включить в нее аналитика, тестировщика и желательно тимлида. А над большим проектом может трудиться до 10-15 разных специалистов, причем половина из них будет занята лишь частично. Рационально ли это для внутренней команды — вопрос спорный.

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


Небольшой проект

Срок: 3-4 месяца

Команда: 4 человека

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

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

В случае с аутсорсом заказчик, наоборот, не полностью оплачивает занятость отдельных узкопрофильных специалистов (например, архитектора, проджект-менеджера или тестировщика), поскольку они участвуют в проектах part-time.

Средний проект

Срок: 5-9 месяцев

Команда: 5-8 человек

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


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

Крупный проект

Срок: от 12 месяцев

Команда: 10-15 человек

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

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

Что нужно учесть при выборе

Оцените сложность вашего проекта и время, которое займет разработка. Помните о законе Дугласа Хофштадтера — «любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера».


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

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

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

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


Какой вариант выбрать?

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

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

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

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

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

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

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

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