Роли
Зачем нужны роли в портфеле ИИ-продуктов
Во многих компаниях ИИ внедряется через отдельные инициативы и пилоты. Под каждый кейс создаётся отдельное решение, отдельная интеграция, отдельная команда и отдельный процесс согласований.
На раннем этапе это нормально: компания экспериментирует, ищет применимость ИИ и проверяет гипотезы.
Но при масштабировании возникает проблема:
- пилоты начинают дублировать друг друга;
- разные команды решают похожие задачи разными инструментами;
- продукты появляются без владельцев;
- никто не отвечает за развитие внутреннего ИИ-ландшафта;
- бизнес не понимает, какой инструмент использовать для своей задачи;
- ИТ и безопасность перегружаются разовыми запросами;
- эффект от ИИ сложно масштабировать.
Поэтому компании нужен отдельный контур управления портфелем ИИ-продуктов.
Его задача — не просто запускать инициативы, а формировать набор внутренних ИИ-возможностей, которые можно переиспользовать в разных бизнес-сценариях.
Что такое ИИ-продукт в этой модели
ИИ-продукт — это не разовый пилот и не отдельная автоматизация под одну команду.
ИИ-продукт — это переиспользуемая внутренняя возможность, через которую разные подразделения могут решать типовые задачи с помощью ИИ.
Примеры ИИ-продуктов:
- корпоративная LLM;
- RAG-сервис для поиска по базе знаний;
- агенты (Hermes, OpenCode);
- оркестраторы агентов (Multica, Paperclip);
- code agent для разработки;
- ML-платформа;
- библиотека готовых ИИ-компонентов и интеграций.
ИИ-продукт становится полноценным продуктом только тогда, когда у него есть:
- владелец;
- пользователи;
- сценарии применения;
- правила подключения;
- жизненный цикл;
- метрики;
- поддержка;
- понятная роль в портфеле.
Ключевые роли
1. Руководитель продуктового портфеля
Руководитель продуктового портфеля отвечает за все ИИ-продукты компании.
Его задача — не управлять каждым продуктом руками, а обеспечить, чтобы портфель развивался осознанно: какие продукты нужны компании, какие уже есть, какие стоит пилотировать, какие масштабировать, а какие закрывать.
Зона ответственности:
- формирует стратегию портфеля ИИ-продуктов;
- определяет, какие классы продуктов нужны компании;
- управляет дорожной картой портфеля;
- помогает выбирать, какие продукты запускать, покупать, развивать или выводить из эксплуатации;
- следит за тем, чтобы продукты не дублировали друг друга;
- связывает продуктовый портфель с портфелем ИИ-инициатив;
- отвечает за прозрачность: какие продукты доступны, для каких задач, на каком этапе зрелости;
- участвует в приоритезации продуктовых пилотов и доработок;
- согласует развитие продуктов с инфраструктурой, безопасностью, архитектурой и бизнесом.
Главный вопрос роли:
Какие ИИ-продукты должны быть в компании, чтобы бизнес быстрее и безопаснее запускал ценные ИИ-инициативы?
2. Владелец ИИ-продукта
Владелец ИИ-продукта отвечает за конкретный продукт внутри портфеля.
Например, за корпоративную LLM, RAG-платформу, code agent, ML-платформу, сервис транскрибации встреч и т.д.
Это ключевая роль, потому что без владельца продукт быстро превращается в «инструмент, который кто-то когда-то развернул».
Зона ответственности:
- описывает назначение продукта;
- определяет целевых пользователей;
- формирует продуктовую гипотезу;
- управляет бэклогом;
- собирает потребности от бизнес-команд;
- организует пилоты;
- анализирует обратную связь;
- принимает решения о развитии продукта;
- отвечает за adoption продукта;
- следит за пользовательской ценностью;
- участвует в расчёте эффекта от использования продукта;
- готовит материалы для обучения и онбординга пользователей.
Главный вопрос роли:
Для кого этот ИИ-продукт, какие задачи он решает и почему бизнес должен им пользоваться?
3. Технический владелец ИИ-продукта
Технический владелец отвечает за то, чтобы продукт был не только полезным, но и технически устойчивым.
Он отвечает за архитектуру, интеграции, качество, безопасность, производительность, эксплуатацию и техническую реализуемость продуктовых решений.
В небольших командах эта роль может быть совмещена с руководителем инфраструктуры или senior-разработчиком. В зрелой модели это отдельная зона ответственности.
Зона ответственности:
- определяет техническую архитектуру продукта;
- отвечает за интеграции с корпоративными системами;
- управляет требованиями к данным;
- отвечает за качество и стабильность;
- участвует в выборе технологического стека;
- оценивает технические риски;
- контролирует соблюдение требований безопасности;
- обеспечивает готовность продукта к промышленной эксплуатации;
- помогает владельцу продукта оценивать сложность доработок;
- участвует в разборе инцидентов и технических ограничений.
Главный вопрос роли:
Можно ли этот продукт безопасно, стабильно и масштабируемо использовать внутри компании?
4. Владелец пилота
Владелец пилота отвечает за проверку ИИ-продукта на конкретной бизнес-команде или конкретном наборе сценариев.
Например, компания пилотирует RAG-сервис в юридическом департаменте, code agent в ИТ-команде, Multica/Paperclip-подобный инструмент в ИИ-функции, а платформу автоматизации — в операционном блоке.
Владелец пилота соединяет продуктовую команду, бизнес-пользователей и критерии успеха.
Зона ответственности:
- определяет цель пилота;
- выбирает пилотную команду;
- фиксирует гипотезу ценности;
- описывает сценарии проверки;
- согласует критерии успеха;
- организует сбор обратной связи;
- фиксирует ограничения и риски;
- готовит выводы по итогам пилота;
- предлагает решение: масштабировать, доработать, повторить пилот или закрыть.
Главный вопрос роли:
Доказал ли пилот, что продукт полезен, применим и готов к следующему этапу?
5. Бизнес-владелец сценария
Бизнес-владелец сценария отвечает за конкретную бизнес-задачу, на которой проверяется или используется ИИ-продукт.
Он не владеет самим продуктом, но владеет проблемой, процессом, пользователями и ожидаемой ценностью.
Например:
- юридический блок хочет искать похожие договоры;
- риск-блок хочет находить похожие события операционного риска;
- HR хочет автоматизировать обработку резюме;
- ИТ-команда хочет ускорить разработку через code agent;
- поддержка хочет автоматизировать ответы пользователям.
Зона ответственности:
- формулирует бизнес-проблему;
- описывает текущий процесс;
- предоставляет предметную экспертизу;
- помогает определить критерии качества;
- выделяет пользователей для пилота;
- участвует в тестировании;
- подтверждает или опровергает ценность;
- помогает оценить эффект;
- принимает решение о готовности сценария к внедрению в своём контуре.
Главный вопрос роли:
Решает ли ИИ-продукт реальную бизнес-задачу лучше, быстрее или дешевле, чем текущий способ работы?
6. Команда сопровождения
Команда сопровождения отвечает за то, чтобы ИИ-продукт продолжал работать после пилота и внедрения.
Это важная роль, потому что многие ИИ-решения умирают не на этапе разработки, а после первого запуска: нет поддержки, нет владельца изменений, нет процесса обновлений, нет реакции на инциденты, нет контроля качества.
Зона ответственности:
- поддерживает продукт в промышленной эксплуатации;
- обрабатывает пользовательские обращения;
- фиксирует инциденты;
- следит за доступностью и стабильностью;
- участвует в обновлениях;
- контролирует деградацию качества;
- поддерживает базу знаний по продукту;
- помогает новым пользователям подключаться к продукту;
- передаёт владельцу продукта обратную связь и запросы на развитие.
Главный вопрос роли:
Может ли бизнес стабильно использовать этот продукт каждый день без ручного героизма команды запуска?
Распределение ответственности по жизненному циклу продукта
| Этап | Основная роль | Поддерживающие роли |
|---|---|---|
| Идея продукта | Руководитель продуктового портфеля | Бизнес, руководитель инфраструктуры, архитектура |
| Оценка необходимости | Руководитель продуктового портфеля | Владельцы инициатив, бизнес-владельцы сценариев |
| Выбор решения | Руководитель продуктового портфеля | Технический владелец, безопасность, ИТ |
| Запуск пилота | Владелец ИИ-продукта | Владелец пилота, бизнес-владелец сценария |
| Проверка ценности | Владелец пилота | Бизнес-владелец сценария, владелец продукта |
| Масштабирование | Владелец ИИ-продукта | Руководитель продуктового портфеля, технический владелец, обучение |
| Передача в эксплуатацию | Технический владелец | Команда сопровождения, владелец продукта |
| Развитие продукта | Владелец ИИ-продукта | Пользователи, бизнес, техническая команда |
| Закрытие продукта | Руководитель продуктового портфеля | Владелец продукта, архитектура, безопасность |
Как роли взаимодействуют с портфелем ИИ-инициатив
Портфель ИИ-продуктов и портфель ИИ-инициатив — это два связанных, но разных контура.
Портфель ИИ-продуктов отвечает на вопрос:
Какие ИИ-возможности есть в компании и как они развиваются?
Портфель ИИ-инициатив отвечает на вопрос:
Какие бизнес-задачи мы решаем с помощью ИИ-продуктов и какой эффект получаем?
Одна ИИ-инициатива может использовать один или несколько ИИ-продуктов.
Например:
- инициатива по ускорению разработки может использовать code agent и RAG по внутренней базе знаний;
- инициатива по обработке документов может использовать OCR, LLM и оркестраторов агентов;
- инициатива по автоматизации бизнес-процесса может использовать LLM, RAG и интеграции с корпоративными системами.
Поэтому владельцы ИИ-продуктов должны участвовать в маршрутизации инициатив.
Их задача — помочь понять:
- какой продукт подходит под задачу;
- есть ли уже готовая возможность;
- нужен ли новый продукт или доработка существующего;
- можно ли решить задачу через уже существующий функциональный блок;
- какие ограничения есть у продукта;
- какой delivery-трек нужен для реализации.
Антипаттерны
1. Продукт без владельца
Инструмент развернули, пилот провели, но дальше никто не отвечает за развитие, пользователей, качество и эффект.
Результат: продукт постепенно умирает или используется хаотично.
2. Пилот вместо продукта
Команда делает решение под один кейс и называет его продуктом.
Результат: появляются десятки непереиспользуемых решений, которые сложно поддерживать и масштабировать.
3. Владелец продукта без полномочий
У продукта есть формальный ответственный, но он не может управлять бэклогом, приоритетами, пилотами и развитием.
Результат: роль есть на бумаге, но продуктом фактически никто не управляет.
4. Бизнес не участвует в пилоте
ИИ-функция сама придумывает сценарии, сама тестирует продукт и сама делает выводы о ценности.
Результат: продукт технически работает, но бизнес не внедряет его в реальный процесс.
5. Нет связи между продуктами и инициативами
ИИ-продукты живут отдельно, инициативы живут отдельно.
Результат: каждая новая инициатива снова проходит путь выбора инструмента, согласований, архитектуры и пилотирования с нуля.
Правильная модель
Правильная модель — когда каждый ИИ-продукт в компании имеет:
- владельца;
- технического ответственного;
- понятную целевую аудиторию;
- список поддерживаемых сценариев;
- правила подключения;
- жизненный цикл;
- метрики adoption и эффекта;
- процесс пилотирования;
- процесс передачи в эксплуатацию;
- место в общем портфеле ИИ-продуктов.
Тогда ИИ-функция перестаёт быть командой, которая вручную запускает отдельные пилоты, и становится системой, которая развивает внутренние ИИ-возможности компании.