Команда — это не приложение к алгоритмам

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

Я вырастил команду персонализации в Звуке с нуля до 100+ человек за 2,5 года. Это был один из самых сложных и одновременно самых ценных опытов в моей карьере. В этой части — конкретные принципы, ошибки и уроки.

Кого нанимать первым: DS, DE или PM?

Это вопрос, который мне задают на каждой консультации. И ответ всегда один: зависит от того, что у вас уже есть.

Сценарий 1: Нет ничего (стартап или greenfield)

Первый найм: Full-stack ML Engineer. Не Data Scientist, не Data Engineer, а именно ML Engineer — человек, который может и обучить модель, и задеплоить её, и написать пайплайн данных. На ранней стадии вам не нужна специализация — нужна скорость до первого результата.

В Звуке моим первым наймом был ML-инженер, который за 6 недель поднял первую рекомендательную модель. Не идеальную, но работающую. Это было критично — нам нужно было доказать концепцию, прежде чем нанимать команду.

Сценарий 2: Есть данные, нет ML

Первый найм: Data Scientist + ML Engineer. DS проектирует модели, MLE деплоит. Дуэт, который может работать автономно. Плюс PM — хотя бы на 50% — чтобы приоритизировать задачи и общаться с бизнесом.

Сценарий 3: Есть ML, нет Data Platform

Первый найм: Data Engineer. Если ваши модели работают на плохих данных — никакой DS не поможет. Инвестируйте в фундамент. В Звуке мы долго откладывали этот найм — и заплатили за это переработкой моделей, когда данные наконец почистили.

Структура: от 5 до 100 человек

Стадия 1: 5 человек (месяцы 1–6)

  • 1 ML Engineer — модели + деплой
  • 1 Data Engineer — пайплайны данных
  • 1 Data Scientist — эксперименты, анализ
  • 1 Backend Developer — интеграция с продуктом
  • 1 PM — приоритизация, стейкхолдеры

Это минимальная жизнеспособная команда. Она может запустить 1–2 RecSys-продукта, построить базовый пайплайн и доказать ценность персонализации.

Ключевой принцип: на этой стадии все делают всё. DS пишет код в продакшен, DE помогает с фичами, PM сам анализирует A/B-тесты. Специализация — враг скорости на старте.

Стадия 2: 15–25 человек (месяцы 6–12)

Когда доказали ценность, начинается специализация:

  • RecSys-команда (5–7 человек): DS, MLE, backend — строят рекомендательные продукты
  • Data Platform-команда (4–6 человек): DE, platform engineers — строят и поддерживают данные
  • ML Platform-команда (3–4 человек): MLOps, infra — training, serving, monitoring
  • Analytics (2–3 человека): аналитики, A/B-тесты, метрики
  • PM + Design (2–3 человека): продуктовое видение, UX

На этой стадии появляется tech lead в каждой подкоманде и Head of ML/Personalization над всем.

Стадия 3: 50–100 человек (год 2+)

Полноценное подразделение с несколькими продуктовыми командами:

  • Рекомендации — несколько команд по RecSys-продуктам
  • Поиск — отдельная команда (поиск — это свой мир)
  • CVM — retention, push, offers
  • Data Platform — масштабируется вместе с данными
  • ML Platform — shared services для всех ML-команд
  • Analytics & Experimentation — централизованная экспертиза в A/B и метриках
  • Management — VP/Director, Heads of, PMs, Scrum Masters

В Звуке к этой стадии у нас было 6 продуктовых команд, каждая с полным стеком (DS + MLE + BE + PM + Analyst), и 3 платформенные команды (Data, ML, A/B). Плюс management layer.

Роли: ML Engineer vs Data Scientist vs Analytics Engineer

Одна из частых проблем — путаница ролей. Вот как мы их разграничивали:

Data Scientist:
- Формулирует задачу в ML-терминах
- Проектирует и обучает модели
- Проводит офлайн-эксперименты
- Анализирует результаты A/B-тестов
- Не деплоит модели в продакшен (но может прототипировать)

ML Engineer:
- Переводит модели DS в production-quality код
- Строит inference-пайплайны (real-time и batch)
- Оптимизирует производительность (latency, throughput)
- Настраивает мониторинг и алерты
- Работает с ML Platform

Analytics Engineer:
- Строит data pipelines и dbt-модели
- Создаёт и поддерживает feature store
- Обеспечивает качество и доступность данных для DS
- Строит дашборды и отчёты

Data Engineer:
- Проектирует и строит Data Platform
- Real-time и batch пайплайны
- Масштабирование, надёжность, SLA
- Интеграция источников данных

Антипаттерн: нанять 5 Data Scientist'ов и ни одного ML Engineer'а. DS создают модели, которые никто не может задеплоить. Через полгода — фрустрация, увольнения, ноль impact. Я видел это дважды, второй раз — у нас самих, пока не исправили баланс.

Культура data-driven decision making

Технические навыки найти можно. Культуру — нужно строить. Вот принципы, которые мы внедряли:

1. «Данные побеждают мнения»

Любое решение о продукте должно быть подкреплено данными. Не «я думаю, пользователям понравится», а «A/B-тест показал +5% retention». Это не значит, что интуиция не важна — но интуиция формулирует гипотезу, а данные её проверяют.

2. «Быстрые эксперименты > идеальные модели»

Мы ценили скорость итерации выше качества отдельного эксперимента. Лучше запустить 10 экспериментов в месяц и найти 2 победителя, чем 3 месяца полировать один эксперимент.

3. «Fail fast, learn faster»

Неудачный эксперимент — это не провал, а информация. Мы вели «кладбище экспериментов» — базу знаний о том, что НЕ работает и почему. Это экономило недели работы будущих команд.

4. «Прозрачность результатов»

Все результаты A/B-тестов — публичные внутри компании. Любой сотрудник мог посмотреть, какие эксперименты запущены, какие результаты. Это строило доверие и вовлечённость.

5. «ML-грамотность для всех»

Мы проводили внутренние лекции и воркшопы для PM'ов, маркетологов, руководителей. Не чтобы они стали Data Scientist'ами, а чтобы понимали возможности и ограничения ML. PM, который понимает, что такое cold start, ставит более реалистичные задачи.

Как я строил команду в Звуке — ошибки и уроки

Ошибка 1: Нанимал слишком медленно

Первые полгода я пытался доказать ценность маленькой командой из 3 человек. Мы доказали — но потеряли 4 месяца, которые могли бы использовать для масштабирования. Урок: начинайте нанимать до того, как покажете результат — на основе плана, а не ретроспективно.

Ошибка 2: Не инвестировал в Data Platform сразу

Первый год мы строили модели на «сырых» данных — с пробелами, дублями, задержками. Каждая модель тратила 40% времени на preprocessing. Когда наконец вложились в Data Platform, продуктивность ML-команды выросла вдвое. Урок: Data Platform — до первой модели, а не после.

Ошибка 3: Нанял 5 DS, 0 MLE

Классика жанра. Пять талантливых DS, каждый обучает модели в Jupyter notebooks. Ни одна модель не в продакшене. Потребовалось 3 месяца, чтобы нанять MLE и разгрести технический долг. Урок: баланс ролей важнее количества людей.

Ошибка 4: Недооценил PM-функцию

«ML-команде не нужен PM, мы сами знаем, что делать.» Нет. Без PM команда оптимизирует технически интересные задачи, а не бизнес-импакт. PM — это переводчик между ML и бизнесом, и без него команда изолируется.

Что сработало

  • Hiring bar: мы не снижали планку, даже когда позиция была открыта 3 месяца. Один сильный инженер > три средних.
  • Onboarding: каждый новый сотрудник в первую неделю проводил A/B-тест (пусть простой) — сразу погружался в культуру экспериментов.
  • Ротация: DS из RecSys-команды на 3 месяца переходил в CVM-команду — это давало кросс-опыление идей и предотвращало бункеризацию.

Что дальше

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

Нужна помощь в построении ML-команды? Запишитесь на консультацию — помогу определить оптимальную структуру и нанять ключевых людей.