Модуль p.11 · Урок 3
Урок 3: Команда AI-программы — роли, компетенции, где искать
Содержание
- Чему вы научитесь
- Два уровня команды: пилот и зрелая программа
- Что обязательно должно быть в pilot team
- KPI ролей: как понять, что человек действительно тянет программу
- Что держать внутри, а что можно отдать наружу
- Три организационные модели, которые реально работают
- 1. Внутренняя команда с сильной управленческой мобилизацией
- 2. Partner-led запуск
- 3. Гибрид: внутренний core + внешний execution
- Где искать людей
- Какой ритм работы должен быть у команды
- Красные флаги в найме
- Как растёт зрелая программа
Чему вы научитесь
- Собирать минимальную pilot team так, чтобы бизнес, данные, эксплуатация и внедрение были закрыты без лишнего найма
- Отличать команду первого пилота от зрелой AI-программы, где уже появляются platform engineers, security, procurement и change lead
- Привязывать KPI ролей не к абстрактной «инновационности», а к shipping velocity, uptime, adoption и улучшению business metric
- Выбирать организационную модель: свой core team, гибрид с подрядчиком или partner-led запуск
- Нанимать первую волну людей без типовой ошибки «сначала купим дорогого senior ML, а бизнес потом подтянется»
Команда AI-программы почти никогда не разваливается из-за нехватки «талантливых ML-людей» в вакууме. Она разваливается потому, что никто не держит бизнес-метрику, никто не отвечает за data path, никто не проектирует внедрение в реальный workflow, а ML-инженер неожиданно оказывается и product owner, и аналитиком, и архитектором, и дежурным по инцидентам.
Поэтому команду надо проектировать так же, как вы проектируете архитектуру. А начинать — не с самой модной роли, а с самой дефицитной. Для пилота это почти всегда Product Owner с правом принимать решения в процессе. Про stakeholder map полезно перечитать урок p.4/05, а про ИБ- и DPO-роли — урок p.3/08.
Два уровня команды: пилот и зрелая программа
| Уровень | Типовой состав | Что делает | Главный риск |
|---|---|---|---|
| Pilot team | 4–6 ключевых ролей | Проверяет один use case на реальном процессе и выводит его в controlled production | Слишком много ответственности висит на 1–2 людях |
| Mature AI program | 15–30+ человек | Ведёт портфель use cases, общую платформу, MLOps, закупки, ИБ, change и тиражирование | Превращается в «AI-департамент ради себя», если теряет связь с P&L |
Что обязательно должно быть в pilot team
| Роль | Зачем нужна | Что нельзя на неё перекладывать |
|---|---|---|
| Product Owner с KPI из EBITDA | Держит приоритет, экономику и решение по scope | Нельзя превращать его в секретаря встречи и человека «согласовать с бизнесом потом» |
| Domain expert / главный инженер / технолог | Знает процесс, ограничения и реальный критерий полезности | Нельзя использовать его только как «подтвердить гипотезу в конце» |
| ML Engineer | Строит и стабилизирует модельный слой | Нельзя заставлять его в одиночку придумывать бизнес-кейс |
| Data Engineer | Достаёт, нормализует и подаёт данные | Нельзя ожидать, что этим «временно займётся аналитик» |
| DevOps / MLOps | Готовит среду, деплой, observability, rollback | Нельзя подключать только на последней неделе |
| UX / operator console owner | Делает интерфейс полезным мастеру и оператору | Нельзя считать, что «дашборд BI и так сойдёт» |
Это не значит, что вам нужно нанять всех в штат в первый месяц. Для пилота часть ролей может быть закрыта подрядчиком. Но функции должны существовать в любом случае.
На этом месте многие команды совершают дорогую ошибку: им кажется, что если одну роль временно никто не закрывает, её «как-нибудь потянет» соседняя функция. Так обычно Product Owner начинает руками добывать данные, ML Engineer пишет боевой deployment, а DevOps объясняет технологу физику процесса. Первый месяц проект на этом ещё едет. Дальше — нет.
KPI ролей: как понять, что человек действительно тянет программу
| Роль | Базовый KPI | Второй KPI | Как понять, что роль закрыта плохо |
|---|---|---|---|
| Product Owner | Улучшение целевой бизнес-метрики | Adoption rate и time-to-decision | Все обсуждают модель, но никто не может сказать, как меняется KPI участка |
| ML Engineer | Model performance в production, а не на ноутбуке | Shipping velocity новых версий | Есть хороший notebook, но нет устойчивого production inference |
| Data Engineer | SLA data pipeline и полнота данных | Time-to-availability новых источников | Любой новый датасет — ручной подвиг на две недели |
| DevOps / MLOps | Uptime и deployment frequency | Mean time to recovery | После первого drift все ждут «когда автор модели освободится» |
| Domain expert | Точность domain rules и acceptance criteria | Скорость закрытия спорных кейсов | Команда неделями спорит о том, что считать ошибкой или успехом |
| UX / operator console owner | Время до понятного решения для пользователя | Доля рекомендаций, дошедших до действия | Система technically работает, но оператор ей не пользуется |
Эти KPI кажутся разными, но все они сводятся к одной мысли: AI-команда существует ради изменения процесса, а не ради отдельной модели.
Что держать внутри, а что можно отдать наружу
| Функция | Лучше держать внутри | Можно временно отдать подрядчику | Почему |
|---|---|---|---|
| Business ownership | Да | Нет | Внешний подрядчик не управляет вашим P&L |
| Domain expertise | Да | Нет | Знание процесса и ограничений нельзя арендовать на квартал |
| Data engineering | Желательно | Да, на старте | Подрядчик может быстро собрать пайплайн, но владение источниками должно остаться у вас |
| ML / CV / LLM implementation | Не обязательно на первом пилоте | Да | Это самая удобная часть для controlled outsourcing |
| MLOps / deployment | Частично | Да | На старте нужен speed, но runbook и доступы должны быть внутренними |
| ИБ / DPO / контур | Да | Нет | Регуляторный риск остаётся на предприятии, а не на поставщике |
Эта матрица полезна для одного решения: не пытайтесь аутсорсить то, что составляет управленческое ядро программы. Снаружи удобно покупать скорость. Внутри надо оставлять право на решение, данные, контур и знания о процессе.
Три организационные модели, которые реально работают
1. Внутренняя команда с сильной управленческой мобилизацией
Кейс Татнефти полезен именно здесь. 38 топ-менеджеров и 28 ML-специалистов, которые совместно проработали 150+ идей, — это не история «нашли одного гениального ML-архитектора», а история системной мобилизации функций вокруг AI (Napoleon IT, 09.02.2023).
Когда подходит: у вас крупный холдинг, несколько активов, длинный горизонт и готовность растить внутреннюю capability.
2. Partner-led запуск
Aker BP показывает модель, где сильный внешний партнёр помогает быстро перевести industrial data и AI в рабочий контур. По данным Aker BP и обзора Cognite Impact 2025, компания сократила время root cause analysis на 97% — с недель до часов — благодаря связке с Cognite Atlas AI (Aker BP, 16.09.2025; ARCweb, 2025).
Когда подходит: у вас есть бизнес-owner и инженерная команда, но нет зрелого внутреннего AI-стека.
3. Гибрид: внутренний core + внешний execution
Для российского завода это чаще всего лучший путь. Внутри остаются:
- Product Owner
- Domain expert
- ИБ / DPO / контурные роли
- ML / Data lead, который потом сможет забрать сопровождение
Снаружи на пилот приходят:
- интегратор
- ML- и data-исполнитель
- MLOps / deployment expertise
- иногда UX и change support
Именно эту модель проще всего наращивать до зрелой программы.
У Shell этот гибридный путь в итоге пришёл к фабрике моделей на корпоративной платформе вместе с C3 AI (C3 AI, 07.03.2022). То есть внешний партнёр может быть ускорителем, но не должен становиться единственным носителем программы.
Где искать людей
Внутри предприятия. Самый недооценённый источник — инженеры, технологи и аналитики, которые уже понимают процесс и готовы расти в data/AI-роль. Часто это быстрее и дешевле, чем искать «готового единорога».
Университеты и исследовательские центры. МФТИ, ИТМО, МГУ, ВШЭ и другие площадки с AI-направлениями полезны не только для найма джунов, но и для стажировок, совместных проектов и отбора Research ML. Про исследовательские центры и льготы — в p.3/07.
Профессиональные сообщества. Habr, профильные Telegram-каналы, конференции по MLOps, CV, OT/ИТ-интеграции и отраслевые мероприятия дают людей с production-опытом, а не только с academic-портфелем.
Подрядчики и вендоры. Для пилота это часто обязательный слой. Но уже на старте фиксируйте, какие знания и артефакты остаются внутри предприятия.
Какой ритм работы должен быть у команды
У зрелой команды есть не только роли, но и cadence. Минимальный ритм пилота выглядит так:
- еженедельный business review: sponsor, Product Owner, owner метрики
- еженедельный data and model review: Data + ML + domain expert
- еженедельный architecture and risk review: архитектор, ИБ, DevOps/MLOps
- ежемесячный steering committee: решение по бюджету, scope и блокерам
Если этот ритм не задан, программа почти всегда начинает жить в режиме «кто свободен, тот и решает».
Красные флаги в найме
| Красный флаг | Почему это опасно | Что делать вместо этого |
|---|---|---|
| «Kaggle-only» кандидат без production-опыта | Хорошо решает benchmark, но может не понимать деплой, drift, контур и operational ownership | Для senior-ролей ищите опыт вывода в эксплуатацию и жизни после пилота |
| Сильный PhD без индустриального опыта на роль практического лидера | Может прекрасно строить модель, но не держать срок, контур и коммуникацию с цехом | Оставляйте такие профили на research/advanced role, а не на единственного owner execution |
| Вакансия «full-stack AI engineer» на всё сразу | Обычно это попытка одной ставкой заменить Product, Data, ML, DevOps и change | Разделяйте функции, даже если людей поначалу немного |
| Найм ML раньше Product Owner | Получаете сильный код без задачи и без права отказать бизнесу | Сначала закрывайте ownership и domain |
Как растёт зрелая программа
Когда пилоты начинают превращаться в production, добавляются новые роли:
- Platform Engineer
- Security / DPO / compliance roles
- Procurement / vendor manager
- Change management lead
- Research ML для сложных кейсов
- Documentation / enablement owner
Это не значит, что в первый год надо строить отдел на 30 человек. Это значит, что AI-программа — это не только ML. И если вы долго этого не признаёте, программа всё равно это покажет через инциденты и сорванные сроки.