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

Представьте себе «сферического коня в вакууме» — технологию вроде распознавания речи или сегментации фона. У неё есть:

• технические метрики (бенчмарки),

• рабочие стенды,

• примеры использования.

Но как превратить это в реальную пользу для клиента и бизнеса?

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

Почему управлять такой командой — трудная задача?

DS-инженеры живут в мире исследований, экспериментов и долгосрочных циклов. Они умеют глубоко погружаться в модель, оптимизировать её месяцами и годами. Благодаря этому появляются GPT, DeepSeek, Qwen и другие инновации.

Но когда за спиной стоит бизнес со своими ожиданиями, сроками и требованиями — возникает напряжение (несовпадение взаимных ожиданий) между мирами исследований и реализации.

И между ними — ваша команда. И задача — не просто «перевести» одно в другое, а создать процесс, в котором обе стороны достигают целей.

Вот два ключевых вопроса, которые я задал себе

Вопрос 1. Нужно ли знание ИИ, чтобы управлять ИИ-командой?

Ответ: Да, но не обязательно быть экспертом в математике или погружаться в код модели.

Важнее понимать:

• что такое обучение, эксперимент, инференс;

• базовые области: LLM, NLP, ASR, CV;

• как эти технологии могут влиять на продукт.

Не знать, как выводить формулу из статьи по конференции NeurIPS, но зато понимать, зачем команда делает то, что делает, и как это связано с бизнес-целями.

Что можно сделать для этого:

• организовать обучение: курсы, подкасты, внутренние доклады;

• задавать правильные вопросы: «Зачем мы сейчас оптимизируем точность на 2%, если пользователь этого не заметит?».

Цель — не сделать из всех экспертов, а дать достаточно контекста, чтобы команда могла принимать осознанные решения.

Вопрос 2. Как управлять такими проектами?

Рассмотрим на примере двух кейсов.

Кейс 1. Большая задача, высокая неопределённость.

Ситуация:

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

• Не было чётких требований — нужно было просто сделать хорошо (что такое хорошо? как это понять?).

• Команда только начинала работу (что происходит? где мы?).

• ML-лаборатория уже провела длительное исследование, и подготовила модель с ожидаемо более высоким качеством.

• За месяц до релиза выяснилось, что модель не готова, точнее готова, но качество такое же, как и в существующем в Толке решении от Google MediaPipe.

Что произошло:

• Технические метрики модели соответствовали минимальным требованиям.

• Продуктовые метрики — отсутствовали, потому что ими не занимались.

• Обе команды не понимали, как модель повлияет на пользовательский опыт. Плюс фича не влияла на критический путь пользователя.

Что мы сделали:

1. Уточнили критерии успешного релиза.  

Собрали все ожидания: от ML-инженеров, бизнеса и пользователей.

2. Приняли решение запускать MVP.  

Модель была не идеальной, но давала первый опыт взаимодействия.

3. Собрали пирамиду метрик. 

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

4. Сменили фокус: стало ясно, что нужно улучшать не модель, а её инференс.  

Занялись оптимизацией инфраструктуры, распределением нагрузки между CPU/GPU.

Что нам это дало:

• первые данные о поведении модели в реальных условиях;

• гипотезы влияния ИИ-фичи на продукт;

• возможность планировать следующие этапы развития.

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

Кейс 2. Рост масштаба и сложности внедрения ИИ-фич.

Ситуация:

• Команда уже внедрила несколько ИИ-фич.

• Процессы наладились.

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

• Ожидания от качества и скорости начали расти.

Проблема:

• Как правильно сформулировать требования к новым или существующим моделям?

• Как понять, что действительно важно улучшать?

• Какие новые технологии использовать: DeepSeek, Dify или что-то ещё?

Что помогло:

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

• Он стал «узлом компетенции» и помогает:

 -  оценивать качество моделей;

 -  проверять актуальность новых решений;

 -  планировать roadmap ИИ-направления;

 -  участвовать в постановке целей и OKR.

Результат:

• Продакт и аналитик начали лучше понимать, что возможно, а что нет.

• Команда получила инструмент для валидации идей.

• Появилась способность быстро оценивать новые технологии и принимать решения.

Практические рекомендации по управлению ИИ-командой

1. Управляйте коммуникацией.

• ML-разработчики часто сосредоточены на своих исследованиях. Ваша задача — обеспечить обратную связь и понимание общей цели.

• Не допускайте «накопленной недоговорённости». Обсуждайте всё: от метрик до ожиданий от релиза.

2. Формулируйте требования.

• Избегайте крайностей: слишком общие или слишком жёсткие формулировки одинаково опасны. Приведу примеры по обоим вариантам.

Общие. Например, нужно понять, что люди делают на видео во время видеоконференции. Цель: собрать датасет для тестирования качества модели виртуального фона.

И тут сразу возникают вопросы:

• Какие это действия? Не определён список целевых действий (человек сидит, бежит, поднимает руку, закатывает глаза).

• В каком контексте? Один человек в кадре или много? Реальное время или обработка архивов?

• Что на выходе? В датасете нужна разметка всего видео или таймстампы для каждого действия.

Жёсткие. Например, на видео в реальном времени нужно сделать кожу человека гладкой как пластик, чтобы цвет был идеально ровным, убрать все морщины, увеличить глаза на 15%.

И сразу возникают вопросы:

• Потеря текстуры и естественности: «Абсолютно гладкая кожа» и «идеально ровный цвет» уничтожают все текстуры, делая человека похожим на восковую фигуру?

• Единые проценты для всех? Увеличение глаз на 15% и сужение лица на 10% для каждого человека будет выглядеть неестественно, особенно на людях с крупными чертами.

• Игнорирование индивидуальности: алгоритм не адаптируется к уникальным чертам лица.

• Лучше всего работают гибкие требования с возможностью корректировки на основе данных.

3. Распределяйте ответственность.

• Чётко разграничьте зоны ответственности внутри команды и между командами.

• Убедитесь, что ML-разработчик не работает в одиночку, а встроен в общий процесс.

4. Развивайте контекст в команде.

• Давайте ресурсы для обучения, организуйте внутренние демо, обсуждения.

• Связывайте ИИ-задачи с бизнес-метриками: «Это улучшение повысит NPS на X%» — гораздо мощнее, чем «точная сегментация фона».

5. Приносите обратную связь от пользователей в команду. «Спасибки» всегда мотивируют, а критика заставляет задуматься, что ещё можно улучшить.

Заключение

Работа с ИИшной-командой — это не только про «внедрить технологию», но и про выстраивание процессов, управление неопределённостью, настройку коммуникации и принятие решений в условиях ограниченных данных.

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

Делитесь в комментариях своими лайфхаками работы со сложными технологиями, а ещё расскажите, был ли опыт управления подобной командой, как у меня. ?