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

Поэтому считать стоит не “сколько стоит разработчик”, а “сколько стоит довести задачу до продакшена”. Для этого и нужен TCO (total cost of ownership): полная стоимость владения командой, процессом или внешним контуром разработки.

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

Почему ставка разработчика ничего не объясняет

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

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

TCO появляется как раз между “купили часы разработчиков” и “получили работающую фичу в продакшене”. В расчет попадают дополнительные расходы:

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

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

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

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

Базовая формула такая:

TCO разработки = прямые расходы + управление + запуск + простои + риски + передача знаний.

Где:

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

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

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

Формула может быть такой:

TCO инхауса = зарплата + налоги + инфраструктура + найм + онбординг + управление + простой + риск замены

• Зарплата и налоги можно посчитать сразу. Остальное часто всплывает позже. Разработчику нужны ноутбук, монитор, доступы, IDE, таск-трекер, облачные сервисы, тестовые стенды и корпоративные инструменты. 
• Найм тоже входит в TCO. Вакансию нужно описать, кандидатов найти, провести скрининг, техническое интервью, тестовое задание и согласование оффера. 
• После выхода человека начинается онбординг. Разработчик разбирается в кодовой базе, архитектуре, локальном окружении, правилах ревью и деплоя. Первые недели он часто требует больше внимания, чем отдаёт команде пользы. Это нормальная часть штатной разработки, её просто нужно считать заранее.
• Отдельная статья расходов — текучка. Когда разработчик уходит, компания теряет часть контекста. Потом нужно снова искать человека, вводить его в проект и ждать, пока он выйдет на нормальную скорость.

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

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

Как считать TCO аутсорса

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

Формула может быть такой:

TCO аутсорса = стоимость договора + подготовка требований + управление со стороны заказчика + приёмка + изменения цели + передача результата

• Стоимость договора обычно включает работу команды, PM, тестирование, инфраструктуру подрядчика и его маржу. Маржа в этой модели нормальна: подрядчик держит команду, управляет загрузкой, закрывает внутренние риски и отвечает за процесс на своей стороне.
• Главная точка роста стоимости — требования. Когда финальная цель понятная, подрядчик быстрее оценивает задачу, планирует этапы и показывает результат. 
• Заказчику всё равно нужно управлять проектом со своей стороны. Подрядчик не знает продуктовый контекст по умолчанию. Ему нужны ответы на вопросы, доступы, обратная связь и приёмка промежуточных результатов.
• В TCO аутсорса стоит сразу закладывать передачу результата. В договоре нужно зафиксировать права на код. Документация должна позволять поддерживать проект другой команде. Деплой, окружения и API тоже лучше описать до финальной приёмки. 

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

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

Как считать TCO выделенных команд

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

Формула может быть такой:

TCO выделенных команд = ставка специалиста + подбор + онбординг + управление + ревью + коммуникация + риск замены

• Ставка специалиста даёт доступ к человеку, а готовый результат всё равно собирает ваша команда. Подрядчик может помочь с подбором, оформлением, заменой и административной частью. Заказчик отвечает за ежедневную работу специалиста.
• Самая важная статья расходов здесь — время техлида. Он проводит техническое интервью, вводит человека в проект, объясняет архитектуру и проверяет решения.
• Онбординг в аутстаффинге обычно короче, чем в инхаусе: компания не проходит полный цикл найма и оформления, но контекст проекта всё равно нужно передать.
• В TCO нужно заложить коммуникацию с провайдером. Если специалист заболел, не подошёл по уровню или проекту нужна замена, порядок действий должен быть понятен заранее. 

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

Где здесь место внешней команды

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

Здесь помогает простой вопрос: что сейчас нужно купить. Часы специалистов, готовый контур разработки или помощь с постановкой задачи. Centicore Group работает с выделенными командами IT-специалистов, заказной разработкой и IT-консалтингом. Поэтому формат можно подбирать под ситуацию: усилить свою команду, передать отдельную часть разработки внешней команде или начать с анализа требований и архитектуры.

Посмотреть услуги Centicore Group

Чек-лист перед выбором модели

Перед выбором модели проверьте три вещи: управление, срок проекта и требования.

1. Сначала — управление. Если внутри есть CTO, техлид или сильный PM с техническим бэкграундом, можно рассматривать аутстаффинг и гибридную модель. Если управленца нет, аутстаффинг быстро станет проблемой. В этом случае безопаснее смотреть на аутсорс, где управление разработкой берёт на себя подрядчик.
2. Дальше — срок проекта. Для задачи на несколько месяцев инхаус часто слишком дорогой: найм, адаптация и настройка процессов могут занять больше времени, чем сама разработка. Для продукта на долгосрок, наоборот, стоит заранее думать о своём техническом ядре.
3. Третий пункт — требования. Чем понятнее сценарии, интеграции, ограничения и критерии готовности, тем проще считать TCO аутсорса. Если требования ещё меняются, в бюджет нужно сразу закладывать аналитику, дополнительные итерации и переприёмку.

Перед решением ответьте на несколько вопросов:

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

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

Итого

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

• Инхаус подходит для долгих продуктов, где важны контроль, архитектура и накопление экспертизы внутри команды.
• Аутсорс удобен для MVP, интеграций, миграций и отдельных сервисов с понятными границами. Здесь важно заранее считать требования, приёмку, документацию и передачу результата.
• Аутстаффинг помогает быстро усилить команду, если внутри уже есть техлид, бэклог, ревью и нормальный процесс разработки.
• Гибридная модель нужна, когда продукт проходит разные этапы. На старте можно подключить внешнюю команду, после проверки гипотезы собрать своё ядро, а пиковую нагрузку закрывать аутсорсом или аутстаффингом.

Капитанский вывод, но полезный: считайте не ставку разработчика, а стоимость релизов.