Прежде чем нанимать первого ML-инженера, стоит разобраться в архитектуре самого продукта. Понимание того, как работают современные LLM-модели и AI-агенты, напрямую влияет на то, какие специалисты вам нужны и в какой последовательности их нанимать. Без этого фундамента команда рискует собраться хаотично — с дублирующимися компетенциями и пробелами в критических местах.
Почему AI-команда отличается от классической продуктовой
В обычном продуктовом стартапе достаточно фронтенд- и бэкенд-разработчиков, дизайнера и менеджера. AI-продукт требует другой матрицы компетенций. Здесь пересекаются исследовательская работа, инженерия данных, MLOps и прикладная разработка — и каждое из этих направлений требует отдельного специалиста или хотя бы человека с осознанным пересечением навыков.
Ошибка, которую совершают многие команды на старте: нанимают «ML-инженера» и ждут, что он закроет всё — от разметки данных до деплоя модели в продакшн. Это нереалистично. ML-инженер, который умеет всё сразу, либо делает каждое направление посредственно, либо выгорает за полгода.
Базовый состав команды AI-продукта
Минимальный боеспособный состав для запуска AI-продукта выглядит так:
- ML-исследователь — отвечает за выбор архитектуры модели, эксперименты, оценку качества. Это человек, который понимает математику за алгоритмами и умеет читать научные статьи.
- ML-инженер — переводит исследования в работающий код, оптимизирует инференс, занимается интеграцией модели в систему.
- Data Engineer — строит пайплайны сбора, хранения и обработки данных. Без качественных данных даже лучшая модель бесполезна.
- MLOps-инженер — управляет инфраструктурой: мониторинг моделей, CI/CD для ML, версионирование артефактов.
- Продуктовый менеджер с AI-экспертизой — понимает ограничения технологии и умеет переводить бизнес-задачи в технические требования.
- Бэкенд-разработчик — строит API и сервисный слой вокруг модели.
На ранних стадиях некоторые роли можно совмещать — например, ML-исследователь и ML-инженер в одном человеке. Но совмещение Data Engineer и MLOps обычно создаёт узкое горлышко, потому что эти задачи конкурируют за время одного специалиста в самые критичные моменты.
Где ломается найм в AI
Рынок ML-специалистов перегрет. Спрос на исследователей уровня senior значительно превышает предложение, а джуниоры с дипломом по data science и джуниоры, реально умеющие строить модели — это разные люди. Несколько закономерностей, которые стоит учитывать:
- Хорошие ML-исследователи редко сами ищут работу — их переманивают или они переходят по рекомендациям внутри профессионального сообщества.
- Оценить кандидата без технической экспертизы в команде практически невозможно — стандартное HR-интервью не выявит реальный уровень.
- Задания на дом работают хуже, чем в обычной разработке: сильный специалист не будет тратить 8 часов на тестовое для компании, о которой ничего не знает.
- Конкурировать зарплатой с крупными технологическими компаниями сложно — нужно предлагать интересные задачи, автономию и стек без технического долга.
Посмотрите на пример формирования AI-команды для технологического продукта — там разобрана реальная последовательность найма от первого исследователя до полноценной команды с распределёнными ролями.
Как оценивать ML-специалистов без технической команды
Если в компании ещё нет технических людей, которые могут провести экспертное интервью, есть несколько рабочих подходов. Первый — нанять технического консультанта на почасовую оплату для участия в собеседованиях. Второй — привлечь рекрутинговых партнёров с доменной экспертизой: они могут сделать первичную квалификацию кандидатов по техническим критериям. Третий — попросить кандидата разобрать его собственный прошлый проект: как выбиралась архитектура, какие были компромиссы, что пошло не так.
Последний подход особенно информативен. Человек, который реально делал работу, легко объясняет решения и ошибки. Кандидат, который приукрашивал резюме, начинает давать размытые ответы уже на втором уточняющем вопросе.
Редкие экспертизы: когда стандартный найм не работает
Некоторые позиции в AI требуют не просто опыта, а специфической комбинации навыков — например, исследователь, который одновременно разбирается в компьютерном зрении и медицинской диагностике, или специалист по reinforcement learning с опытом в робототехнике. Такие люди не появляются на стандартных job-бордах.
Детальный кейс поиска ML-исследователя с редкой экспертизой показывает, как выстраивается процесс: от составления профиля через академические базы и конференции до выхода на кандидата, который не искал работу активно.
Структура команды на разных этапах
Состав меняется по мере роста продукта. На стадии MVP достаточно двух-трёх человек с широкими компетенциями. После первых продаж начинается специализация — появляются выделенные роли под данные, инфраструктуру, исследования. На стадии масштабирования добавляются команды под отдельные модели или функциональности.
Одна из частых ошибок на этапе роста — задержка найма MLOps. Команда долго обходится ручными процессами, пока технический долг в инфраструктуре не начинает тормозить всю разработку. Нанимать MLOps-инженера лучше чуть раньше, чем кажется необходимым — это окупается в скорости деплоя и стабильности продакшн-среды.
AI-команда работает эффективно, когда роли чётко разделены, а коммуникация между исследователями и инженерами не требует посредников. Если ML-исследователь и ML-инженер не говорят на одном языке — это первый признак, что процесс разработки будет медленным и дорогим.