Карточка ИИ-продукта
Назначение
Карточка ИИ-продукта — это единая запись о переиспользуемом ИИ-продукте в портфеле. Она показывает, какой класс задач продукт закрывает, кто за него отвечает, какие инициативы через него проходят, на каком этапе зрелости он находится и какие ограничения нужно учитывать.
Карточка нужна не для описания технологии. Она помогает принять управленческое решение: запускать продукт, пилотировать, масштабировать, развивать, объединять с другим продуктом или выводить из портфеля.
Когда используется
Карточка нужна, когда:
- повторяющийся класс задач претендует на отдельный ИИ-продукт;
- инициативы маршрутизируются в существующий продукт;
- продукт переводится из пилота в управляемый контур;
- нужно понять, какие продукты дублируют друг друга;
- продукт пересматривается на ритуале портфеля ИИ-продуктов;
- команда готовит решение на контрольной точке жизненного цикла продукта.
Кто отвечает
Основной владелец карточки — владелец ИИ-продукта. Он отвечает за назначение продукта, целевую аудиторию, поддерживаемые сценарии, метрики, ограничения и развитие.
Поддерживающие роли:
- руководитель продуктового портфеля — следит за местом продукта в портфеле и отсутствием дублей;
- технический владелец — отвечает за архитектуру, интеграции, качество, безопасность и эксплуатационную готовность;
- владельцы сценариев применения — подтверждают, что продукт решает реальные задачи;
- сопровождение — фиксирует модель поддержки, инциденты и ограничения;
- ИИ-офис — контролирует полноту карточки и решения на контрольных точках.
Входные данные
Для заполнения карточки нужны:
- повторяющиеся запросы бизнеса или набор инициатив;
- описание класса задач;
- предполагаемые пользователи;
- выбранный или предполагаемый деливери-трек;
- требования к данным, безопасности и интеграциям;
- результаты пилота или проверки гипотезы;
- первичные метрики использования, качества и эффекта;
- решение владельцев о следующем шаге.
Структура карточки
| Блок | Что фиксируется | Зачем нужно |
|---|---|---|
| Идентификация | название, тип продукта, статус зрелости, дата создания, ссылка на каталог | Чтобы продукт был видим как отдельная сущность портфеля |
| Класс задач | какие повторяемые задачи закрывает продукт и какие не закрывает | Чтобы не превращать продукт в универсальный инструмент для всего |
| Целевая аудитория | роли, команды, подразделения, типовые пользователи | Чтобы понять, кто должен пользоваться продуктом |
| Владельцы | владелец ИИ-продукта, технический владелец, сопровождение, смежные функции | Чтобы было понятно, кто принимает решения и кто поддерживает продукт |
| Сценарии применения | поддерживаемые сценарии, пилотные сценарии, запрещённые сценарии | Чтобы инициативы маршрутизировались в продукт осознанно |
| Деливери-трек | маршрут подключения или развития, артефакты, участники, контрольные точки | Чтобы продукт не жил отдельно от деливери инициатив |
| Риск-профиль | данные, доступы, влияние на решения, интеграции, регуляторные ограничения | Чтобы контроль был пропорционален риску |
| Готовность | статус пилота, инструкции, поддержка, мониторинг, правила подключения | Чтобы продукт можно было безопасно масштабировать |
| Метрики | использование, качество, стоимость, эффект, повторное использование | Чтобы продукт оценивался по фактам, а не по наличию доступа |
| Решения | запуск, масштабирование, доработка, объединение, вывод из портфеля | Чтобы история управления продуктом была прозрачной |
Статусы зрелости
| Статус | Что означает | Следующее решение |
|---|---|---|
| Кандидат | Есть повторяющийся класс задач, но продукт ещё не оформлен | Запустить пилот, расширить существующий продукт или отклонить |
| Пилот | Проверяется применимость продукта на ограниченных сценариях | Масштабировать, доработать, повторить пилот или закрыть |
| В контуре | У продукта есть владелец, правила использования, поддержка и место в портфеле | Подключать инициативы и измерять использование |
| Масштабирование | Продукт подключается к новым командам и сценариям | Закрепить модель поддержки и метрики эффекта |
| Развитие | Продукт регулярно дорабатывается по спросу и обратной связи | Обновить дорожную карту и приоритеты бэклога |
| Объединён / выведен | Продукт больше не нужен как отдельная сущность | Перенести пользователей, закрыть риски и зафиксировать решение |
Контрольные точки карточки
| Контрольная точка | Что проверяется | Возможное решение |
|---|---|---|
| Есть ли продуктовая гипотеза | Повторяемость класса задач, целевая аудитория, владелец, отличие от существующих продуктов | Запустить продукт-кандидат или реализовать как отдельную инициативу |
| Подтверждён ли пилот | Реальное использование, качество результата, ограничения, первые метрики, обратная связь пользователей | Масштабировать, доработать, повторить пилот или закрыть |
| Готов ли продукт к масштабированию | Поддержка, инструкции, безопасность, правила подключения, метрики, техническая устойчивость | Включить в управляемый контур или вернуть на доработку |
| Нужен ли продукт в портфеле | Активное использование, подтверждённая ценность, стоимость поддержки, дублирование, технологическая актуальность | Оставить, объединить, заменить или вывести из портфеля |
Минимальный набор полей
Минимальная карточка должна отвечать на десять вопросов:
- Какой класс задач закрывает продукт?
- Какие сценарии применения поддерживаются?
- Для каких команд и ролей продукт предназначен?
- Кто владелец ИИ-продукта?
- Кто технический владелец и кто сопровождает продукт?
- Какой деливери-трек используется для подключения инициатив?
- Какие данные, доступы и интеграции нужны?
- Какие ограничения и риски известны?
- Какие метрики показывают использование, качество и эффект?
- Какое решение принято на последней контрольной точке?
Что делает карточку качественной
Хорошая карточка:
- описывает продукт через класс задач, а не через название технологии;
- показывает владельца, пользователей и правила подключения;
- связана с инициативами, которые уже используют продукт;
- содержит риск-профиль и ограничения применения;
- фиксирует метрики использования, качества, стоимости и эффекта;
- хранит решения о пилоте, масштабировании, развитии или закрытии.
Плохая карточка:
- описывает только инструмент или вендора;
- не показывает, какие инициативы через него проходят;
- не имеет владельца или технического ответственного;
- не фиксирует ограничения и запрещённые сценарии;
- не показывает, используется ли продукт в реальной работе;
- не помогает решить, развивать продукт или выводить из портфеля.