Вопрос «нанять своих или взять подрядчика» обычно решают сравнением ставок: разработчик в штате стоит столько-то, час подрядчика столько-то. Это сравнение почти всегда ошибочно, потому что сравнивает не то. Разберём, из чего складывается каждый вариант на горизонте двух лет и при каких условиях выигрывает тот или другой.
Что на самом деле стоит своя команда
Минимальный работающий состав для ИИ-задач — это не один человек. Нужны специалист по машинному обучению, инженер данных и разработчик, который доводит модель до сервиса в проде. Один универсал закрывает всё это только на игрушечных задачах.
К фонду оплаты труда добавляется то, что в ставке не видно: налоги и накладные, оборудование и GPU, лицензии и облако, обучение и конференции, время руководителя на управление, а также простой между проектами. Полная стоимость сотрудника обычно выходит в полтора-два раза выше оклада.
Скрытая статья: время до первого результата
Найм ML-специалиста в России занимает месяцы, а не недели: рынок узкий, и сильные кандидаты редко ищут работу активно. Дальше выход на продуктивность — ещё несколько месяцев на понимание домена и данных. До первого работающего решения проходит от полугода, и всё это время команда уже стоит денег.
Скрытая статья: риск ухода
Уход единственного ML-специалиста означает потерю не только рук, но и понимания, почему модель устроена именно так. Если знание не зафиксировано в документации и коде, восстановление стоит как половина проекта заново. Это аргумент не против своей команды, а за требования к тому, как она работает.
Что на самом деле стоит подрядчик
Здесь стоимость выглядит прозрачнее — она в договоре, — но и тут есть части, которые не видны в смете.
- Ваше время на постановку задачи и приёмку. Подрядчик не знает вашего процесса, и погружение — это часы ваших людей, а не только его.
- Разметка данных, если она на вас. Это человеко-недели специалистов, понимающих предмет, и их время дороже времени разработчика.
- Сопровождение после сдачи — оно либо в договоре, либо станет неприятным открытием через полгода.
- Риск зависимости, если по итогам проекта у вас не остаются код, веса модели и документация.
Пункт про принадлежность результата — не формальность. Модель, от которой зависит рабочий процесс, не должна зависеть от того, продолжаете ли вы работать с подрядчиком. Проверьте это в договоре до подписания, а не при расставании.
Сравнение по существу
Скорость до первого результата
Подрядчик выигрывает уверенно: команда собрана, инструменты есть, похожие задачи решались. Прототип реален за две недели против полугода на найм и погружение. Если задача проверяется гипотезой, ждать своей команды бессмысленно.
Стоимость на длинной дистанции
Здесь картина переворачивается, но не сразу и не всегда. Своя команда становится дешевле, когда у неё есть постоянный поток задач: не один проект в год, а непрерывная работа с моделями, данными и их качеством. При потоке в один-два проекта в год штат простаивает, и его содержание дороже разовой покупки.
Знание вашего домена
Преимущество своей команды, и существенное. Понимание процесса накапливается и работает на все следующие задачи. Подрядчик каждый раз погружается заново — частично это компенсируется опытом похожих проектов, но не полностью.
Устойчивость решения
Модель в проде требует присмотра постоянно, а не проектно. Здесь своя команда объективно удобнее — реакция быстрее и мотивация другая. Подрядчик закрывает это договором на сопровождение, и качество зависит от того, насколько внятно этот договор написан.
Когда выбор очевиден
Берите подрядчика, если
- Вы ещё не уверены, что задача решается: платить полгода за проверку гипотезы силами найма — дорогой способ узнать «нет».
- Проектов немного и они разовые: система контроля качества на одну линию не требует постоянной команды.
- Нужен результат в этом квартале, а не в следующем году.
- Задача типовая для рынка, но новая для вас: распознавание документов, поиск по базе, прогноз спроса.
Стройте свою команду, если
- Модели становятся частью продукта, а не вспомогательным инструментом.
- Данные и требования меняются постоянно, и переобучение нужно регулярно, а не раз в год.
- Домен сложный и специфичный настолько, что погружение занимает месяцы, — тогда его стоит оплачивать один раз.
- Есть внятный поток задач минимум на год вперёд, а не одна.
Третий путь, который обычно работает лучше
На практике чаще всего выигрывает не выбор, а последовательность. Первые проекты делаются с подрядчиком: быстро, с проверкой гипотез и без риска содержать команду под задачу, которая может не подтвердиться. Параллельно в компании появляется человек, который отвечает за направление изнутри — не обязательно ML-специалист, скорее владелец задачи, понимающий, что именно вы покупаете.
Когда становится ясно, что ИИ — постоянная часть работы, а не эксперимент, команда собирается вокруг уже работающих решений и понятного потока задач. Это принципиально проще, чем нанимать вслепую под ненайденную задачу: понятно, кого искать и чем он будет занят с первого дня.
Что важно потребовать от подрядчика при таком сценарии: код, веса модели, документацию по обучению и воспроизводимый процесс. Без этого передача внутрь превратится в переделку, и переход обойдётся дороже, чем весь выигрыш от него.
Как проверить решение цифрами
- Посчитайте полную стоимость команды на два года: фонд оплаты труда с налогами и накладными, оборудование, облако, обучение, время руководителя.
- Прибавьте стоимость периода до первого результата — это месяцы, когда затраты идут, а отдачи ещё нет.
- Посчитайте стоимость тех же задач у подрядчика, включая сопровождение и ваше время на постановку и приёмку.
- Сравните при реальном числе задач, а не при желаемом. Именно здесь чаще всего разваливается план собственной команды: задач оказывается вдвое меньше, чем предполагалось.
- Отдельно оцените риск: что будет, если ключевой человек уйдёт, и что будет, если подрядчик перестанет работать. Оба сценария должны иметь ответ.
Гибридные схемы, которые встречаются на практике
Чистых вариантов почти не бывает. На практике складываются несколько устойчивых конфигураций, и полезно знать их заранее.
Свой владелец задачи, внешняя разработка
Самая частая и, пожалуй, самая здоровая схема на старте. Внутри компании есть человек, который понимает процесс, отвечает за результат и умеет ставить задачу. Разработка идёт снаружи. Такой владелец не обязан быть ML-специалистом — важнее, чтобы он понимал, что именно покупает и как проверит.
Своя команда, внешняя экспертиза точечно
Команда есть, но упирается в незнакомый класс задач: впервые понадобилось компьютерное зрение или развёртывание модели в закрытом контуре. Подрядчик привлекается не на весь проект, а на конкретный участок с передачей знаний. Дешевле, чем нанимать специалиста под разовую задачу.
Внешняя разработка, своя эксплуатация
Подрядчик строит решение и передаёт его вместе с процессом обучения и мониторингом. Дальше внутренняя команда сопровождает. Работает, только если передача была спроектирована заранее: код, веса, документация, воспроизводимое обучение. Иначе через полгода придётся звать обратно.
Как нанимать, если сами не из ML
Отдельная сложность своей команды: если внутри нет ML-экспертизы, оценить кандидата трудно. Резюме выглядят похоже, а разница в реальной пользе — кратная. Несколько вопросов, которые различают уровень без необходимости самому разбираться в алгоритмах.
- Расскажите про проект, который не получился, и почему. Сильный специалист отвечает содержательно и без защиты. Ответ «все проекты были успешными» означает либо отсутствие опыта, либо отсутствие рефлексии.
- Как вы проверяли, что модель работает? Ответ должен содержать отложенную выборку и метрику, связанную с задачей. Если звучит только «точность» без уточнения, на чём мерили, — тревожный знак.
- Что вы делали, когда данных не хватало? Практический опыт слышен сразу: аугментация, перенос с похожей задачи, сужение постановки. Теоретический ответ звучит иначе.
- Как вы выводили модель в эксплуатацию и что было дальше? Многие сильны в обучении и не имеют опыта эксплуатации. Для корпоративных задач вторая часть важнее первой.
- Что бы вы сделали первым делом у нас? Хороший кандидат начнёт с вопросов о процессе и данных, а не с предложения архитектуры.
Если внутренней экспертизы нет совсем, разумно привлечь внешнего специалиста на техническое интервью. Это несколько часов работы, которые страхуют от ошибки найма стоимостью в годовой фонд оплаты труда.
Ошибки при переходе к своей команде
- Нанимать до того, как появились задачи. Специалист, полгода искавший, чем заняться, уходит — и уносит с собой то, что успел понять.
- Начинать с одного человека и ждать полного цикла. Один ML-специалист без инженера данных и разработчика упрётся в подготовку данных и вывод в прод, а не в модели.
- Не забрать у подрядчика воспроизводимый процесс обучения. Веса модели без возможности её переобучить — актив, который стареет и не обновляется.
- Считать, что своя команда снимает потребность в процессе. Мониторинг, приёмка версий и разбор ошибок нужны независимо от того, кто делает работу.
Проверка решения через год
Какой бы вариант вы ни выбрали, полезно заранее договориться, как поймёте через год, что выбор был верным. Несколько признаков, что схема работает: задачи проходят полный путь от постановки до эксплуатации, а не застревают на прототипах; модели в проде мониторятся и переобучаются по регламенту, а не по жалобам; знание зафиксировано в документации, и уход одного человека не парализует направление.
Если через год большинство проектов остались демонстрациями, дело обычно не в исполнителях, а в отсутствии владельца и внятного критерия успеха. Смена подрядчика или найм своей команды этого не лечат.
Что меняется по мере роста компании
Ответ на вопрос о команде смещается вместе с масштабом, и полезно понимать, на каком вы этапе, чтобы не решать задачу следующего.
На первом этапе ИИ — это гипотеза. Никто внутри не знает, окупится ли направление, и правильное действие — проверить дёшево и быстро. Здесь любая собственная команда преждевременна: вы платите за содержание специалистов, пока сами не понимаете, какие задачи им ставить.
На втором этапе появляются первые работающие решения и вместе с ними — эксплуатация. Модели надо мониторить, переобучать, разбирать ошибки. Именно здесь возникает потребность в постоянном человеке внутри, но не обязательно в ML-разработчике: чаще нужен инженер, который умеет поддерживать сервисы и понимает, что происходит с моделью.
На третьем этапе задач становится достаточно для полноценной команды, и появляется своя специфика, которую внешнему исполнителю каждый раз объяснять дороже, чем накопить внутри. Здесь найм оправдан, и к этому моменту вы уже точно знаете, кого искать.
Ошибка, которая встречается чаще всего, — прыжок с первого этапа на третий. Компания без единого работающего решения нанимает команду из трёх человек и полгода ищет им применение. Обратная ошибка тоже бывает: компания с десятком моделей в эксплуатации продолжает всё отдавать наружу и платит за передачу контекста больше, чем стоила бы команда.
Коротко
- Сравнивать ставки бессмысленно: у своей команды главная статья — время до первого результата, у подрядчика — ваше время на постановку и приёмку.
- Подрядчик выигрывает на скорости и на проверке гипотез, своя команда — на потоке задач и знании домена.
- Переломная точка — не размер компании, а наличие постоянного потока задач минимум на год.
- Рабочая последовательность: сначала подрядчик и проверенные гипотезы, потом команда вокруг работающих решений.
- В любом договоре с подрядчиком требуйте код, веса и документацию — иначе переход внутрь будет стоить как проект заново.