Как оценивается результат работы продакта
Работа продакта в AI-продуктах оценивается не через процесс и «ощущение порядка», а через управляемость и эффект на уровне продукта. Ключевой вопрос, который я задаю себе и коллегам: можно ли по данным понять, что продукт движется в нужную сторону и за счет каких рычагов?
На практике фокус смещается на внешние метрики: финансовый результат, удержание, повторное использование, скорость достижения пользовательского результата. В продуктах с AI-агентами добавляется отдельный слой показателей:
- самый важный — точность;
- результативность сценариев (задача решена / не решена);
- надежность (ошибки, инциденты качества, деградации);
- экономика (стоимость закрытия запроса, латентность, нагрузка на поддержку).
Именно этот набор, на мой взгляд, превращает продукт из «работающего решения» в управляемую систему, где понятно, что масштабируется, а что ломается.
KPI
В разных компаниях свои наборы, у нас такие:
- Количество покупок и новых пользователей по отношению к текущей аудитории.
- Маржинальность — фактический объем продаж сравнивают с плановыми показателями.
- Активные пользователи — оценивают, сколько людей ежедневно используют продукт.
- Customer Retention Rate (CRR) — коэффициент удержания новых пользователей, ведь важен не только прирост, но и количество оставшихся людей.
- ROI — показатель рентабельности доходов по отношению к рекламным расходам. Демонстрирует, окупились вложенные средства или нет (показатель должен быть больше 100%).
- Сроки разработки, успешность запуска пилотной версии продукта и т. п.
- Качество работы AI-компонентов. Для решений с машинным обучением наши заказчики часто фиксируют метрики качества, в частности F1-score — интегральный показатель точности, учитывающий как полноту, так и точность модели. На практике целевое значение F1 ≥ 90% является стандартным требованием для продакшен-решений (например, при извлечении данных из документов — распознавание номеров телефонов, ИНН, сумм и других критичных полей).
- Для AI-агентов (если они часть продукта) — успешность выполнения задач, доля запросов без эскалации на оператора/менеджера, средняя стоимость закрытия запроса, скорость ответа, число инцидентов качества/безопасности.
Ок, KPI показывают результат. Но чтобы к нему прийти, продакту нужен набор навыков, который помогает одновременно держать стратегию, процесс и коммуникации.
Какими навыками должен обладать менеджер продукта
Построение коммуникаций
Для меня ключевой результат этого навыка — полная информационная прозрачность и единое понимание реализации проекта.
Мы с командой всегда стараемся, чтобы все участники — в том числе и клиент — одинаково понимали, как именно будет реализовываться продукт, какие вопросы остаются открытыми, какие решения уже приняты, в какие сроки и с какими ограничениями ведется работа.
Отдельная часть нашей работы — управление ожиданиями клиента: прогнозы редко бывают сформулированы явно, поэтому их приходится либо осознанно формировать, либо корректировать, если они не совпадают с реальностью проекта.
В AI-проектах, помимо привычных коммуникаций с разработчиками, дизайнерами и маркетингом, появляются ML/LLM-инженеры, ИБ, юристы и комплаенс, владельцы данных и бизнес-процессов — и всем этим ролям важно одинаково понимать, что считается «хорошим результатом» и по каким признакам он оценивается. На практике я вижу, что это часто ломается из-за перегруженных стейкхолдеров.
На одном из моих проектов ключевой продуктовый владелец со стороны заказчика четко понимал, каким должен быть результат, но операционное взаимодействие делегировал дальше. Доступ к человеку, который реально принимает продуктовые решения, был ограничен, а вопросы по реализации копились. В итоге рабочим решением стали заранее зафиксированные синки — регулярные слоты, поставленные на месяцы вперед. Мы с командой приходили на них уже с проработанными вариантами и конкретными вопросами и синхронизировались по ходу, а не задним числом. Это позволило удерживать общее понимание проекта и не накапливать расхождения в ожиданиях.
В другом проекте ситуация была обратной. Со стороны заказчика существовало формальное ТЗ, составленное руководителем, — документ был корректным с точки зрения структуры и требований, но по факту не отражал, какие задачи итоговый продукт должен решать для тех, кто будет с ним работать каждый день. Причиной этого стала нарушенная коммуникация на клиентской стороне.
Конечные исполнители, не имея представления о возможностях корпоративного портала, верхнеуровнево сформулировали задачу для своего руководителя. Руководитель, в свою очередь, интерпретировал цель разработки по-своему и составил техническое ТЗ, исходя из собственного видения, а не из реальных операционных сценариев.
В результате исходная постановка задачи для конечных пользователей была искажена, а смысл решения утерян. Сам руководитель не был глубоко погружен в операционные процессы и, по сути, не до конца понимал, как именно продукт должен использоваться на практике.
Но на этапе реализации входным звеном коммуникации оставался именно руководитель: он принимал промежуточные результаты и уже затем транслировал их команде.
После нескольких случаев непонимания решили ситуацию так: инициировали прямую коммуникацию с конечными внутренними заказчиками. Это позволило и быстро выявить реальные задачи, и перевести их в технически корректную и применимую реализацию.
В процессе работы стало понятно, что буквальное следование ТЗ приведет к формально сданному, но бесполезному решению. Мы вышли на прямую коммуникацию с конечными пользователями, разобрали реальные сценарии, ограничения и ожидания — и в том числе скорректировали ожидания заказчика относительно того, каким должен быть результат проекта.
В итоге продукт был спроектирован и реализован под реальные задачи команды и закрыл ее потребности на 100%. При этом первоначальное ТЗ в итоговом решении выполнено не было — и это было осознанный ход, потому что ценность оказалась важнее формального соответствия документу.
Планирование
В AI-проектах база по распределению задач по времени и формированию общей дорожной карты дополняется контуром данных и качества (пилот → мониторинг → улучшения → масштабирование). Мне важно видеть взаимосвязи между работами, понимать, какие этапы зависят друг от друга и где возникают узкие места. Это позволяет вовремя фиксировать риски срыва сроков, сигнализировать о них команде и стейкхолдерам плюс осознанно запараллеливать работы там, где это возможно.
Отдельной частью планирования становится работа с рисками: их нужно заранее формулировать, оценивать влияние и закладывать способы снижения или обхода еще на этапе планирования. К тому же их необходимо регулярно пересматривать.
Стратегическое мышление
В 2026 году AI-агенты становятся массовым направлением: компании экспериментируют и начинают масштабировать агентные системы. И тут по опыту скажу, что продакту важно уметь выбирать процессы под агентность, проектировать многошаговые сценарии, ограничения и контроль.
Сюда же можно отнести проектирование Human-in-the-Loop как нормы, а не «костыля»: где и когда нужен человеческий контроль/валидация вывода модели (особенно это важно в чувствительных кейсах: юридические документы, медицина, стратегическое планирование и т. д.).
Нацеленность на бизнес-результат
AI-продакт должен уметь переводить AI в P&L-метрики: фиксировать цель как бизнес-результат (рост выручки, удержание, ускорение цикла, снижение издержек), а не как «улучшим точность» — и уже затем выбирать метрики модели как инструмент контроля достижения этой цели.
Важно, чтобы в планировании сразу появлялись измеримые KPI «до/после», гипотеза влияния на деньги, контур данных и качества и изменения в процессе, потому что эффект дает не «встроили LLM», а перестроенный workflow. И по данным McKinsey Global Survey, компании, которые извлекают наибольшую ценность от AI, чаще ставят growth/innovation вместе с efficiency, а не ограничиваются задачей «просто сократить затраты».
Ведение документации
Помимо стандартных проектных артефактов, на своих проектах я фиксирую логику работы AI-компонентов так, чтобы система оставалась управляемой после запуска и при изменениях.
Ключевые элементы такой документации включают описание сценариев использования: какие задачи делегируются агенту, в каком контексте, с какими ограничениями и ожидаемым результатом, а также условия эскалации на человека. Это позволяет избежать «расползания» функциональности и неконтролируемых решений модели.
Отдельно фиксирую эталонный набор данных — примеры корректных входов и ожидаемых выходов системы. Он используется для обучения, валидации и калибровки поведения AI, а также задает ориентир того, как обязан выглядеть «правильный результат» и каким требованиям он должен соответствовать.
Плюс описываю источники данных и правила работы с ними: откуда агент получает информацию, какие данные являются доверенными, какие — вспомогательными, как обновляется контекст и что считается допустимым для использования в ответах. В этот же блок входит описание разметки данных — объяснение того, что представляют собой данные, какие сущности и признаки в них выделяются и как модель должна с ними работать. Это напрямую влияет на качество вывода, воспроизводимость результатов и соответствие требованиям безопасности.
Документирую архитектуру системы — как на логическом, так и на техническом уровне: какие компоненты участвуют в работе решения, какие данные и в какой последовательности передаются между ними, где находятся точки принятия решений и контроля. Такая фиксация позволяет сохранять целостность системы при доработках и упрощает сопровождение.
Фиксирую модель доступов и ролей: какие действия агент может выполнять, к каким системам обращаться, какие операции запрещены и где требуется подтверждение со стороны человека. В агентных системах это критично, поскольку ошибка в правах доступа быстро превращается в инцидент.
Кроме того, фиксирую набор инструментов агента (API, внутренние сервисы и внешние системы, которые он может вызывать) с описанием целей, ограничений и допустимых сценариев использования. Это упрощает контроль интеграций, аудит и последующую доработку.
Отдельным элементом документации задаю критерии качества и точности работы AI. Для ML- и AI-решений заказчики часто фиксируют целевые метрики, в частности F1-score как интегральный показатель точности.
Наконец, отдельным блоком составляю правила безопасности и ограничения — требования к логированию, мониторингу качества, обработке ошибок, защите данных и реагированию на инциденты. Такая документация задает «границы допустимого» и позволяет масштабировать AI-решение без потери доверия со стороны бизнеса, ИБ и регуляторов.
Работа с подрядчиками
В AI-проектах работа с подрядчиками очень влияет на ключевые продуктовые показатели: качество вывода, стоимость сценариев, скорость масштабирования и уровень рисков. Я участвую в выборе поставщиков моделей, инфраструктуры и специализированных AI-команд, оценивая не столько «точность» или бренд, сколько поведение модели в реальных сценариях, требования к данным, экономику инференса и ограничения на эксплуатацию.
При этом ключевым фактором успеха становится не только выбор подрядчиков, но и организация совместной работы. В проектах, где один подрядчик отвечает за AI-компоненты, а другой — за бэкенд или интеграции, они неизбежно зависят друг от друга и должны работать как единая временная команда. Любые изменения в логике агента, формате данных, цепочках вызовов или сценариях напрямую влияют на обе стороны.
Моя ключевая зона ответственности тут — обеспечить эту связку: подрядчики должны быть в одном информационном поле, понимать принятые технические решения, ограничения и открытые вопросы. Без этого возникают расхождения в реализации, задержки и эффект «мы сделали правильно, но не так, как ожидалось».
Отдельной зоной моей ответственности остается управление TCO AI-компонентов: стоимость одного запроса, влияние контекста и длины цепочек рассуждений на цену, требования к инфраструктуре (GPU/CPU), возможности оптимизаций (кеширование, маршрутизация, fallback-модели) и предсказуемость затрат при росте нагрузки. При проектировании и реализации системы важно заранее заложить оптимальное расходование токенов (управлять объемом контекста, количеством вызовов модели и «тяжестью» запросов), чтобы итоговое решение не оказалось чрезмерно дорогим в эксплуатации. Для агентных систем это особенно критично, так как стоимость растет не линейно с числом пользователей, а с числом действий агента.
Кроме того, я должен следить за архитектурной совместимостью подрядных решений с продуктом и бизнес-процессами: как модель или агент интегрируется в существующую систему, какие инструменты и API он может вызывать, где проходят границы автономности и как реализуется Human-in-the-Loop. Ошибки на этом уровне приводят либо к неконтролируемым действиям агента, либо к деградации качества при обновлениях.
Наконец, контролирую контур данных и безопасности: где хранятся данные, используются ли они для дообучения, какие есть ограничения по передаче и логированию, как обеспечивается воспроизводимость и аудит решений модели. В Enterprise-среде это часто становится решающим фактором при выборе между облачными и on-prem-подходами.
Системность в оценке качества
Для AI-продукта «качество» — это не одно число в отчете. Его нужно проверять регулярно через оценку качества на тестах (evals): заранее переводим ожидания от продукта в понятные критерии, по которым можно проверить ответы модели, отслеживаем, не стало ли хуже после обновлений (регрессии), и опираемся не на «среднюю температуру», а на реальные проблемные примеры из жизни пользователей (ошибочные/провальные случаи, где система дает неверный или опасный результат).
Вместо вывода
AI-продукты приносят деньги не потому, что в них «есть модель» или «встроили LLM», а потому, что они оптимизируют бизнес-процессы и помогают компании экономить ресурсы.
Например, банковские чаты: вы задаете вопрос — бот сразу направляет по нужной теме. Если ответа недостаточно, подключается специалист.
Или сценарий, где ручной труд частично заменяется AI-агентом, а человек только сверяет результат. Это экономит человеко-часы — и, соответственно, деньги.
Именно поэтому роль AI-продакта — не управление бэклогом, а сборка целостной системы, где бизнес-цель, данные, workflow и метрики связаны между собой.
Опыт дал мне понять, что без прозрачных коммуникаций, зафиксированных критериев качества и правил работы с данными продукт остается формально рабочим, но не масштабируемым. И наоборот: когда результат измерим, качество контролируется (включая F1 и агентные метрики), а TCO и риски учитываются заранее, AI становится управляемым активом.
В этом и заключается суть AI-продакт-подхода: переводить технологию в бизнес-результат, а неопределенность — в процессы и цифры. Тогда AI перестает быть экспериментом и становится продуктом, который можно развивать и защищать перед бизнесом.
