Продуктомания Сергея Полиненко

ИИ в работе продакта: работа с требованиями

В прошлый раз писал про то, как LLM помогают готовиться к интервью: проверять вопросы и смотреть на гипотезу глазами разных участников цепочки принятия решения. Теперь следующий слой- работа с требованиями.

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

А вместе с деньгами приезжает набор хотелок:
- «нам нужен такой отчет»;
- «добавьте такую кнопку»;
- «сделайте как в Jira / старой системе»;
- «без этой функции мы не сможем внедриться»;
- «это требование от бизнеса / ИБ / архитектуры».

На первый взгляд все звучит убедительно. Особенно если это говорит крупный клиент. Но за одной формулировкой могут стоять разные вещи: реальная боль пользователя, особенность процесса конкретной компании, попытка воспроизвести старую систему, политический компромисс, ограничение ИБ или разовая хотелка, которая не масштабируется на рынок.

Если такое требование сразу положить в backlog или roadmap, можно быстро прийти не к развитию продукта, а к заказной разработке.

Поэтому на этапе discovery важно не только собирать требования, но и прожаривать их:
- что на самом деле стоит за запросом;
- насколько требование продуктово;
- можно ли его обобщить;
- какие риски мы берем;
- не уходим ли мы в кастом.

LLM здесь полезна как предварительный ревьюер требований: инструмент, который помогает задать правильные вопросы до старта разработки.

Я обычно прогоняю спорные требования через 4 проверки.

1. Что здесь проблема, а что уже решение?

Клиент часто формулирует запрос сразу в виде решения.

Например:

«Нам нужна выгрузка в Excel».

Но за этим могут стоять разные проблемы: нет доверия к данным, нужен регулярный отчет, неудобен текущий дашборд, данные нужны для другой системы или пользователи просто привыкли работать в Excel.

LLM можно попросить:

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

2. Для кого это требование?

В large enterprise одно требование может по-разному выглядеть для пользователя, руководителя, ИБ, архитектора, эксплуатации, закупки или владельца бюджета.

LLM можно попросить:

Посмотри на это требование глазами разных ролей. Для каждой покажи ценность, вопросы и возможные блокеры.

3. Это продуктовая функция или кастом?

Не каждое важное клиентское требование должно становиться продуктовой функцией.

Иногда это рыночная боль. Иногда - особенность процесса конкретной компании. Иногда - компромисс для сделки. Иногда - кастом, который потом придется годами поддерживать.

LLM можно использовать как оппонента:

Это похоже на продуктовую функцию или кастом под одного заказчика? Дай аргументы за и против. Как можно обобщить требование для рынка?

4. Какие вопросы нужно задать до старта разработки?

Моя любимая ловушка: требование в одну строку, которое кажется понятным и оценивается в 5 дней, а по итогу превращается в 50.

LLM можно попросить:

Сформулируй вопросы, без ответов на которые это требование нельзя брать в работу. Отдельно выдели 5 критичных вопросов.

Главная польза не в том, что ИИ «напишет user story». А в том, что он помогает глубже понять проблему клиента, отделить продуктовую функцию от кастома и не тащить в roadmap лишнее.

Если лучше понять задачу, точнее определить границы решения и заранее увидеть риски, команда за тот же объем времени может создать больше value - не просто закрыть хотелку одного клиента, а усилить продукт в целом.

Общий промпт для такой прожарки требований вынесу в комментарий ниже.

Делитесь, как вы используете LLM на ранних этапах проектирования фичи или продукта. Как лучше делать короткие посты здесь или писать более развернуто на vc.ru?

Читать про продукты в b2b

Про использование ИИ в discovery для large enterprise

По результатам опроса победил блок про discovery, требования, roadmap и стратегию. Начать решил с discovery.

Одна из главных проблем discovery в B2B для large enterprise - ограниченный доступ к респондентам. В цепочке принятия решения может быть множество участников: пользователи, руководители функций, ИТ, ИБ, архитектура, эксплуатация, закупки, финансы и непосредственно ЛПР. При этом добраться до каждого из них сложно, а 3 – 5 качественных интервью - это уже хороший результат.

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

Я использую LLM как спарринг-партнёра перед реальными интервью. Например, с её помощью можно:
* прогнать гипотезу на «синтетическом ЛПР»;
* проверить вопросы перед интервью;
* посмотреть на продукт глазами разных участников цепочки принятия решения;
* подготовиться к разговору со скептически настроенным респондентом;
* разобрать проведённое интервью и найти пробелы.

Важно: LLM не заменяет реального респондента и не подтверждает продуктовую гипотезу. Она помогает прийти на интервью лучше подготовленным и не потратить редкий доступ к ЛПР на вопросы, которые можно было проверить заранее.

В Telegram всё не поместилось, поэтому подробный разбор со скриншотами, примерами промптов и пошаговым сценарием работы опубликовал на VC:

ИИ в работе продакта: discovery в B2B-продуктах для large enterprise

Расскажите в комментариях, как вы используете LLM в discovery и про какие сценарии вам было бы интересно прочитать дальше. Про прототипирование помню 🙂.

И отдельно буду благодарен за обратную связь по формату. Было ли полезно? Что стоило бы добавить, убрать или разобрать глубже? Стоит ли и дальше публиковать полные версии на VC (возможно где-то еще) или удобнее прикреплять PDF прямо сюда?

Если материал показался полезным - поделитесь им с коллегами и друзьями 🙂

Читать про продукты в b2b

Про использование ИИ в работе продакта

Последнее время мы активно развиваем платформу Сфера в сторону ИИ.

Сфера - для тех, кто не знает, - это платформа для автоматизации процессов разработки и эксплуатации ПО. Поэтому основной фокус применения ИИ у нас закономерно лежит на SDLC: разработке, тестировании, DevOps, сопровождении, работе с требованиями, знаниями и инженерными процессами.

Параллельно ИИ начинает менять и наш собственный процесс разработки. Сейчас уже сложно представить современную инженерную работу без ИИ-инструментов: как встроенных в платформу, так и внешних по отношению к ней.

Но есть важный перекос.

Когда говорят про ИИ в разработке ПО, чаще всего смотрят на роль разработчика: генерация кода, code review, тесты, анализ дефектов, документация, агенты в IDE и так далее. Иногда говорят про тестировщиков, реже - про аналитиков. А вот про менеджеров в разработке - продуктовых и проектных - говорят заметно меньше.

Хотя, на мой взгляд, именно в работе продакта ИИ уже сейчас может давать очень сильный эффект даже на стандартных инструментах, доступных почти всем. Не потому что ИИ «заменяет продакта», а потому что резко ускоряет путь от сырой мысли к рабочему управленческому артефакту: гипотезе, письму, презентации, расчету, структуре исследования, переговорной позиции, описанию пилота или плану действий.

За последнее время у меня накопилось довольно много личных наблюдений и практических кейсов использования ИИ в продуктовой работе. Хочу сделать серию постов на эту тему - не в формате абстрактной теории, а через реальные управленческие примеры.

Предварительный список тем такой:

1. ИИ как второй контур мышления продакта. Структурирование проблем, поиск противоречий, проверка логики и подготовка решений.
2. ИИ для управленческих писем и эскалаций. Как превращать сырой черновик в понятную коммуникацию для руководства, команды или заказчика.
3. ИИ для презентаций и комитетов. Как собирать логику выступления, структуру слайдов и ключевые сообщения.
4. ИИ для продуктовой стратегии. Рынок, сегменты, конкуренты, гипотезы, ограничения и варианты движения продукта.
5. ИИ для переговорной позиции. Интересы сторон, предмет торга, жесткий, компромиссный и минимально приемлемый варианты позиции.
6. ИИ для пилотов и продуктовых экспериментов. Цель, scope, KPI, критерии успеха и управленческое решение по итогам пилота.
7. ИИ для сложных разговоров. Подготовка к разговору с сотрудником, стейкхолдером или партнером: без ярлыков, но с четкой управленческой позицией.
8. ИИ как редактор и оппонент. Как улучшать тексты, проверять логику, находить слабые места и не превращать материал в безликий «нейротекст».
9. ИИ для discovery и детализации требований B2B-заказчика. Интервью, боли, требования, кастомизация и риск ухода в заказную разработку.
10. ИИ для roadmap и приоритизации. Как сравнивать инициативы и защищать приоритеты.
11. ИИ для presale и работы с клиентами. Подготовка к встречам, follow-up, value proposition и аргументация для разных ролей у клиента.
12. ИИ для анализа обратной связи и поддержки. Как кластеризовать обращения, отделять баги от хотелок и находить системные проблемы продукта.

После этого поста запущу отдельный опрос и попрошу выбрать, какую тему разобрать первой.

Буду признателен, если в комментариях добавите свои кейсы: где вы уже используете ИИ в продуктовой, управленческой или аналитической работе. Или подскажете темы, которые тоже стоит разобрать.

Соберу обратную связь и на ее основе начну серию.

Читать про продукты в b2b

Про ответственность исполнителя в эпоху AI

В последнее время мне всё чаще приносят результаты работы, в которых очень хорошо виден ChatGPT, Claude, DeepSeek или какая-нибудь другая LLM. Презентации. Аналитика. Концепции. Требования. Стратегии. Письма.

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

Начинаешь задавать вопросы:
• Откуда эта цифра?
• Почему сделали такой вывод?
• Почему выбрали именно этот вариант?
• Какие альтернативы рассматривали?

И выясняется, что человек знает о собственном материале примерно столько же, сколько и ты. Это действительно раздражает и формирует негативный флёр вокруг любого материала, где есть хоть какой-то след AI.

При этом отказаться от AI - совершенно не вариант. Хотя наиболее агрессивная часть движения луддитов в ИТ меня не поддержит. Наоборот, я считаю, что мы должны использовать его везде, где он позволяет быстрее анализировать, писать, проектировать, искать варианты или собирать материалы.

Но есть одно важное правило, которое, кажется, нам всем придётся принять:

AI может делать работу за тебя, но ответственность за результат его работы - на тебе.

Если ты принёс материал на встречу - это уже не результат ChatGPT. Это твой результат. Ты должен быть готов ответить за каждую цифру, каждое утверждение и каждый вывод в нём.

Понимать, откуда это взялось.
Проверить факты.
Отбросить галлюцинации.
Иметь собственную позицию.
И суметь защитить её без открытия чата с Claude.

Проблема не в том, что человек сделал презентацию за 5–10 минут вместо двух дней. Если она хорошая - прекрасно.

Проблема начинается тогда, когда вместе с работой мы незаметно делегируем модели построение причинно-следственных связей, которые привели нас к таким выводам, и ответственность за результат.

А вот этого, кажется, делегировать нельзя.

Интересно, как у вас? Сколько раз в день вам прилетают презентации, документы и аналитика, в которых ChatGPT или Claude видно с первого взгляда? И как вы к таким материалам относитесь?

Читать про продукты в b2b

Пора перестать точить топор

У моего руководителя в далёком-далёком прошлом на стене висел постер с фразой «Точи топор!». Смысл был достаточно прост: прежде чем начинать работу, нужно хорошо подготовиться. Тупым топором за одно и то же время ты срубишь меньше деревьев, чем острым, даже если потратишь часть времени на заточку.

Этот принцип глубоко мне запал. Я долгое время им руководствовался - и во многом руководствуюсь до сих пор. Уникальные знания, которые ты накапливал, давали преимущество. Чем больше ты читал, исследовал, разбирался и думал, тем быстрее и качественнее мог действовать потом.

Но кажется, что с появлением генеративного ИИ этот принцип начал работать немного иначе.

Бесконечный процесс проработки идеи всё чаще заменяет активную фазу действия. Современные модели буквально затягивают в бесконечное исследование. Всегда можно задать ещё один вопрос, найти ещё один источник, попросить ещё десять вариантов, дополнительно разобрать риски, сравнить подходы, ещё немного докрутить концепцию.

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

Но на практике на этом моменте всё и останавливается: «На сегодня хватит, я же так хорошо проработал план». А на следующий день ты снова возвращаешься к его доработке, как будто именно в этом и заключается основная работа.

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

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

Я много писал о том, что время ИИ - это не время уникальных знаний. Знания становятся доступными почти всем. Мне кажется, это скорее время людей, которые способны быстро переходить к действию. И если смотреть на это с точки зрения вероятностей, то больше шансов оказывается у тех, кто раньше начинает делать, а не у тех, кто дольше и глубже исследует.

Впрочем, как всегда.

Что думаете об этом? Насколько детально вы прорабатываете планы с LLM?

Почему через несколько лет большинство интерфейсов придется перепроектировать?

На прошлой неделе был на Agentic DevCon. Кажется, там собрались практически все, кто сегодня определяет развитие агентного подхода в России. Практически все разговоры были вокруг технологий. Какой оркестратор лучше? Какой harness использовать? Как организовать взаимодействие между агентами? Какие модели выбирать? Очень много архитектуры, деталей реализации и обсуждения фреймворков.

Но всю конференцию меня не покидала одна мысль.

Мы обсуждаем фундамент, на котором будем строить. А настоящее изменение произойдет уровнем выше.

Эта мысль только укрепилась после того, как я внимательно разобрал отчет Contentsquare и AWS про Customer Experience.

Последние двадцать лет мы проектировали продукты вокруг интерфейса. Думали, как лучше показать информацию, провести пользователя по экранам, расположить кнопки, меню, формы и дашборды. Но сам принцип оставался неизменным: пользователь двигался по заранее спроектированному пути.

С агентами все становится по другому.

Теперь задача системы - не показать нужный экран, а понять, какую цель хочет достичь пользователь, уточнить контекст, подобрать оптимальный сценарий и привести человека к результату. Причем значительную часть работы система сможет выполнить самостоятельно, и доля этой работы будет только расти.

Мы перестаем проектировать интерфейсы.

Мы перестаем проектировать пользовательские сценарии.

Мы начинаем проектировать решения, которые система принимает вместо пользователя.

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

А интерфейс становится следствием этих решений. Он перестает быть чем-то, что дизайнер однажды нарисовал в Figma Pixso. Он начинает динамически собираться под конкретную задачу пользователя.

Пользователю больше не нужно знать, где находится нужная функция или какую кнопку нажать. Он формулирует цель. Дальше агент сам собирает минимально необходимый интерфейс из типовых блоков, показывает только то, что действительно нужно в текущем контексте, и ведет человека к решению.

Два пользователя с одинаковой задачей вполне могут прийти к одному результату совершенно разными маршрутами. Потому что контекст разный.

Потому что ценность теперь не в типизированном пользовательском сценарии.

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

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

Если эта гипотеза верна, то из нее следует еще несколько интересных вещей:

1. Например, понятие «главный экран» постепенно потеряет смысл. Если интерфейс каждый раз собирается под конкретную задачу, постоянная точка входа в систему просто перестает быть необходимой.
2. Изменится и профессия UX-дизайнера. Проектировать придется уже не столько интерфейсы, сколько поведение системы и правила взаимодействия человека с агентом.
3. Через несколько лет мы, возможно, будем выбирать продукты уже не по количеству функций. А по тому, сколько работы они способны выполнить без нашего участия.

У нас в enterprise это уже начинается. Мы сами постепенно приходим именно к такой модели проектирования продуктов. Если посмотреть на то, что сегодня делают Atlassian, GitLab, ServiceNow и другие крупные игроки, становится заметно, что они двигаются примерно в ту же сторону.

Если интересно, могу отдельно разобрать, как enterprise-вендоры перестраивают свои продукты под агентный пользовательский опыт.

Читать про продукты в b2b

Про автопротоколы встреч

Кажется, все уже успели распробовать мощь ИИ в рабочих процессах. Но сегодня хочется поговорить о неожиданной побочке.

Я терпеть не могу автопротоколы встреч.

Да, знаю, сейчас в меня, возможно, полетят камни. Всем же продают ИИ как способ повышения эффективности, а автопротоколы - как одно из самых наглядных подтверждений этого. Современные сервисы делают их почти идеально. Во всякмо случае наш Dion - это делает великолепно. Состав участников, темы обсуждения, принятые решения, ответственные, задачи - всё аккуратно разложено по полочкам. После часовой встречи получается 3 – 4 страницы подробного текста.

Кто-нибудь вообще это читает?

До автопротоколов была другая традиция: «Поставьте, пожалуйста, встречу на запись». Обычно эта фраза звучала второй или третьей на каждой встрече. Все просили запись, но почти никто её потом не смотрел. По большинству встреч, которые я записывал, было... ноль просмотров.

С автопротоколами происходит ровно то же самое. Мы будто бы решили проблему фиксации договорённостей, но на самом деле просто заменили часовое видео четырьмя страницами текста, которые тоже почти никто не читает. И про исполнение договорённостей речь тоже не идёт - невозможно выполнить то, о чём ты даже не знаешь 🙂.

А ведь цель встречи, как мне кажется, совсем не в том, чтобы сохранить каждое произнесённое слово. Цель - договориться и зафиксировать обязательства.

Поэтому я по-прежнему больше всего люблю обычные минутки встречи. Четыре строки. Три тезиса. Пять конкретных договорённостей.

Когда человек сам пишет минутки, он не просто переписывает сказанное. Он пропускает разговор через себя, выделяет главное, принимает договорённости и показывает другим, что именно считает важным. И для меня это намного ценнее идеально оформленного автопротокола.

При этом я не считаю, что автопротоколы бесполезны. Наоборот. Думаю, их главная ценность проявится совсем скоро (а для кого-то уже проявилась). Но не для людей, а для ИИ-агентов. Именно агент сможет прочитать десятки таких протоколов, найти ответственных, собрать решения, проверить выполнение договорённостей и подготовить руководителю короткую выжимку. Вот здесь подробность действительно становится преимуществом.

А человеку, как и раньше, чаще всего достаточно нескольких осмысленных строк. Поэтому отдельное спасибо всем, кто после встречи находит пять минут и пишет человеческие минутки.

Каждый раз, когда я вижу такое письмо, я понимаю: с другой стороны человек не просто присутствовал на встрече - он действительно понял, о чём мы договорились.

Что думаете?

Любите автопротоколы? Перечитываете их?

👍 - если перечитываете автопротоколы.

❤️ - если считаете, что хорошие минутки встречи ценнее.

Читать про продукты в b2b

Про пессимизм менеджера

На этой неделе поймал себя на одной мысли. Чем выше уровень руководителя, тем сильнее фокус работы смещается на разрешение кризисных ситуаций. При этом сложность этих ситуаций тоже растет - почти как в игре 🙂. Все чаще приходится заниматься кризисными проектами, искать выход из ограничений, разбирать сложные управленческие ситуации и помогать другим менеджерам вытаскивать их проекты. Со временем появляется определенная насмотренность.

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

Важно, что я сейчас не про игнорирование проблем. Наоборот. Опытный руководитель обязан видеть риски, слабые места и возможные последствия своих решений. Но есть принципиальная разница между тем, чтобы видеть ограничения, и тем, чтобы внутренне принять, что результат недостижим.

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

Не потому, что «все будет хорошо». А потому, что без этой внутренней уверенности очень сложно принимать тяжелые решения, искать нестандартные ходы и вести за собой команду. Если руководитель сам уже поставил проекту диагноз, команда очень быстро это почувствует.

Более того, вера руководителя влияет не только на его собственные решения. Она определяет качество решений всей команды. Люди редко вкладываются в проект сильнее, чем это делает их руководитель.

При этом любой проект неоднозначен.

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

И наоборот, даже в самом успешном проекте всегда можно найти десятки причин, почему все плохо.

Факты одни и те же. Отличается то, вокруг каких фактов менеджер строит свою картину происходящего.

Из этого для меня следует еще один вывод.

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

Я вижу два возможных пути.

Первый - найти в своем проекте то, ради чего действительно стоит бороться. Не закрывать глаза на проблемы, а сознательно выбрать, на что опираться, чтобы двигаться вперед.

Второй - честно признать, что это не ваше, и заняться чем-то другим.

Но здесь есть ловушка. Если не изменить отношение к работе, а просто сменить проект или компанию, через некоторое время история, скорее всего, повторится. Вы снова найдете то самое темное пятно, вокруг которого построите всю картину происходящего. И снова окажетесь в состоянии, когда проект кажется обреченным, команда - слабой, а руководство - источником всех проблем.

Мне кажется, пессимизм - это серьезное профессиональное ограничение для менеджера.

Интересно, согласны ли вы с этой мыслью?

Только давайте без крайностей. Я не говорю про менеджера, который всегда улыбается, игнорирует проблемы и бесконечно мыслит позитивно. На мой взгляд, сильный руководитель как раз очень хорошо видит проблемы. Вопрос лишь в том, помогают ли они ему искать решение или становятся причиной отказаться от борьбы еще до того, как она началась.

Читать про продукты в b2b

Про то, что вам никогда не пригодится. Но это не точно

Весь прошлый год сын с большим внутренним достоинством объяснял мне, что обществознание ему в жизни не пригодится. Спорить было трудно - я сам когда-то думал примерно так же.

Философию в институте не любил. Русский в школе тоже не входил в число любимых. А отдельное место в моём личном музее учебных страданий занимает теория планирования экспериментов - её пришлось осваивать перед защитой диссертации. Тогда все эти факторные планы, матрицы экспериментов, оценка влияния параметров казались мне инструментом для усложнения жизни аспирантам, не более.

Проходит много лет. Сейчас мы разрабатываем методику тестирования и отладки интеллектуальных функций в слое AI-агентов в Сфере. И в какой-то момент возникает очень практический вопрос: при большом числе параметров - как понять, какие из них реально влияют на результат? Что менять в первую очередь? Как параметры взаимодействуют между собой? И как за минимальное число шагов выйти на целевой уровень качества?

И тут из тёмного угла памяти выходит та самая теория планирования экспериментов. Слегка пыльная. И говорит: «Ну что, пригодилась?»

Потому что задача - ровно про это. Есть набор входных параметров. Есть целевая метрика качества. И нужно не хаотично дёргать настройки, а системно понять, какие факторы влияют на результат и в каких сочетаниях.

Я точно не ожидал, что однажды с благодарностью вспомню эту часть обучения. Но она взяла и пригодилась. И теперь у меня есть ещё один аргумент для разговора с сыном: никогда не угадаешь заранее, какая именно школьная или университетская «скука» вдруг окажется рабочим инструментом.

А у вас такое было? Что из казавшегося бесполезным - философия, культурология, обществознание, статистика - потом внезапно сработало в работе или жизни?

Делитесь примерами. Мне крайне необходимо собрать доказательную базу для семейной дискуссии.

Читать про продукты в b2b

Про подходы к качеству при разработке AI-агентов

Основное отличие классического продукта от продукта на базе AI-агента - это неоднозначность трактовки результата. В случае с LLM мы всегда имеем дело с вероятностной природой взаимодействия с моделью. Даже если параметры «температуры» (креативности модели) выкручены в ноль, модель все равно может давать разные ответы на один и тот же вопрос, особенно если он задан чуть по-другому.

Сам агент, в зависимости от ответов модели, может по-разному интерпретировать задачу, строить план ее выполнения, выбирать доступные ему инструменты и выполнять разные действия для решения задачи. На многих из этих шагов он взаимодействует с LLM, и каждый такой шаг вносит свое вероятностное влияние на итоговый результат. Например, если поставить агенту задачу: «Проанализируй требования и сгенерируй тест-кейсы», то в трех разных прогонах агент может выдать разное количество тест-кейсов с разным уровнем покрытия.

Поэтому подход к тестированию таких продуктов должен кардинально отличаться от классического. Мы уже немного походили по граблям, когда пытались проверять AI-агентов привычными методами, и сейчас постепенно выстраиваем другой процесс: не просто смотрим на отдельный ответ модели, а оцениваем поведение агента в повторяемых сценариях. Для этого нужно:
• определять и тестировать типовые сценарии работы агента;
• для каждого сценария собирать датасет, содержащий типовые и сложные случаи, плохие формулировки, неполные данные и другие нестандартные ситуации. В целом рекомендуют чтобы в наличиии было 100+;
• для каждого сценария определять критерии качества: что именно оцениваем - точность, полноту, соблюдение инструкции, формат ответа и так далее;
• настраивать механизм оценки. Здесь могут использоваться разные методы: экспертная оценка, сравнение с эталонным ответом, использование LLM в роли оценщика и другие подходы;
• для каждого сценария настраивать механику сбора метрик по выбранным критериям качества.

Такой подход позволяет отслеживать эволюцию качества разных версий агента и не проваливаться в одних сценариях, подтягивая качество в других.

Мы сейчас сами проходим становление этих процессов step by step. И, кажется, идти в разработку агентов с классическим подходом к управлению качеством - так себе затея. Не рекомендую :). Иначе легко уйти в бесконечный цикл прохождения ПСИ, когда случайный человек на встрече просит вас выполнить что-то нетиповое с использованием агента, а результат начинает восприниматься как доказательство того, что «агент не работает».

Плюс отсутствие четких критериев качества и их целевых значений очень подрывает веру в AI, особенно после двух-трех неудачных циклов тестирования.

Друзья, кто делает агентов не просто для автоматизации рутины, а как часть продукта, особенно на локальных LLM, расскажите про свои впечатления в части управления качеством. Сталкиваетесь с недоверием к работе агентов?

Читать про продукты в b2b

Вакансия продакта

На днях с коллегами обсуждали, что сейчас мало хороших вакансий на рынке и у нас внезапно появилась позиция в ИИ платформу (https://t1-ai.ru/products/scibox). Могу смело порекомендовать позицию: направление живое и продукт считается очень перспективным. Кажется здесь можно создать что-то чем потом можно будет гордиться. По всем вопросам пишите в личку Диме Власенкову.

Наблюдения про вайбкодинг в Enterprise

Последние пару недель обсуждаем с крупным enterprise-заказчиком покупку и внедрение наших продуктов. Речь идет о контракте на миллионы рублей. И в какой-то момент коллеги показывают нам внутреннюю разработку и говорят примерно следующее:

“Смотрите, вот это мы сделали сами. Один опытный разработчик, около трех недель работы и примерно 700 долларов на токены”.

Причем речь шла о части функциональности одного из наших продуктов. Естественно, мы пошли разбираться глубже, что именно у них получилось. И результат, если честно, удивил.

Коллеги реализовали практически всю необходимую им бизнес-функциональность. Причем не на уровне “демки для презентации”, а в формате реально работающего решения под свои сценарии. Плюс сделали интеграции и в целом получили вполне рабочую систему. Важно понимать - это не выглядело как пет проект или попытка отдельных энтузиастов доказать, какие они инновационные. Это была вполне серьезная внутренняя инициатива крупной компании. С понятной бизнес-логикой: попробовать решить задачу самостоятельно, быстрее и дешевле.

Конечно, там были кривые интерфейсы.
Да, архитектура местами спорная.
Да, огромное количество вопросов по ИБ, надежности, масштабированию, эксплуатации и поддержке оставалось открытым.

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

Еще несколько лет назад подобная история в enterprise выглядела бы почти невозможной. Тяжелые процессы, длинные циклы согласований, огромная стоимость изменений, зависимость от вендоров и интеграторов - весь рынок десятилетиями строился вокруг этого. А сейчас начинают проявляться контуры новой реальности.

Меня в этой истории зацепило сразу несколько вещей.

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

Сообщение для рынка здесь довольно простое: часть задач, которые раньше почти автоматически шли к вендору, клиент теперь пробует решить внутри.

Во-вторых, скорость уже никого особенно не удивляет.

Кажется, рынок довольно быстро принял новую реальность: AI действительно радикально ускоряет разработку, особенно когда речь идет о создании новых систем с нуля.

И в-третьих - это, наверное, самое важное.

Похоже, в ближайшие годы мы начнем конкурировать не только с другими вендорами. Мы начнем конкурировать со связкой “AI + внутренняя команда заказчика”.

И мне кажется, это может очень сильно изменить весь как рынок заказной enterprise разработки, так и рынок продуктов, ориентированный на enterprise сегмент. Особенно в сегменте обычных бизнес-приложений.

Еще совсем недавно идея о том, что небольшая внутренняя команда сможет за пару недель собрать что-то, сопоставимое по ценности с enterprise-решением, казалась довольно фантастической. Сейчас такие истории начинают появляться все чаще. И кажется, дальше их будет становиться только больше.


Похоже, enterprise начинает входить в эпоху, где выигрывать будут не только самые большие, но и самые быстрые. Да и средние чеки, кажется, тоже постепенно начнут снижаться.

Что думаете по этому поводу? Встречали уже такие кейсы?

Читать про продукты в b2b

Как менялось мое отношение к AI

Когда сейчас говорят про AI, вижу, что у многих создается ощущение, будто технология появилась внезапно пару лет назад и сразу перевернула мир. У меня ощущение ровно противоположное. Для меня AI - это личная история почти 20-летнего постепенного изменения отношения к технологии.

Первое столкновение с нейронными сетями у меня было где-то в 2008-2009 году, во время работы над диссертацией. Тогда мы пытались использовать нейросети для разметки эксплуатационной и ремонтной документации. Задача заключалась в том, чтобы автоматически формировать содержание документации и определять перечень узлов, которые необходимо обслуживать для новых машин и механизмов. На практике это был почти научный космос. Нельзя было нормально собрать обучающую выборку, не было инфраструктуры, вычислений, готовых моделей и библиотек. Даже получение хоть какого-то осмысленного результата требовало огромного количества усилий. AI тогда воспринимался скорее как экзотический исследовательский инструмент, а не как что-то прикладное.

Потом было еще много попыток “прикрутить AI” к разным задачам. Например, computer vision для распознавания узлов и агрегатов техники на производстве. Идея была достаточно понятной - камера определяет объект, система идентифицирует его, а дальше можно оптимизировать процессы обслуживания и ремонта. Рядом с этим были и технологии дополненной реальности. По сути они очень близки к computer vision: сначала нужно понять, что находится перед камерой, а уже потом привязать к объекту виртуальную сцену, инструкции или интерфейс.

Но даже тогда все это выглядело как набор нишевых технологий. Да, интересных. Да, перспективных. Но не меняющих фундаментально подход к работе, управлению или созданию продуктов. Долгое время AI в моем мировосприятии оставался чем-то “где-то рядом”. Все слышали про нейронные сети, computer vision и ML-модели, но для большинства это были технологии из исследований, больших корпораций или очень узких профессиональных областей. Практического понимания, как использовать их в ежедневной работе, почти ни у кого не было.

А потом появились большие языковые модели. И это уже была совсем другая реальность.

Что интересно, лично меня очень долго фреймил предыдущий опыт. Даже после появления LLM казалось, что все это где-то далеко. Что технология еще “не созрела”. Что до реального влияния на продукты и процессы еще много лет. Если честно, еще примерно полтора года назад я относился к этому довольно осторожно и не до конца понимал масштаб изменений.

Но буквально за последний год произошло очень быстрое переосмысление. От ощущения “это экспериментальная технология” мы пришли к изменению подходов к разработке продуктов, процессов работы команд и даже продуктовой стратегии платформы целиком.

Сейчас у нас проработана стратегия развития AI-функций платформы, архитектурные подходы, сценарии внедрения и модель взаимодействия AI с продуктами и с внешними системами. Кстати, если интересно, могу отдельно написать пост о том, как мы к этому подходили и к каким выводам пришли. И чем дальше, тем сильнее кажется, что изменения будут значительно глубже, чем просто “новый удобный инструмент”.

Похоже, что мы постепенно уходим от привычной модели интерфейсов. От форм, кнопок, сложных экранов и навигации. К голосовым интерфейсам, чатам, агентским режимам и в целом к AI как посреднику между человеком и системой. Даже в продуктах для large enterprise. И это все произойдет не когда-нибудь потом, а уже в течение 6-12 месяцев начнется реальный переход на эти способы работы, а через 2-3 года это станет стандартом.

Наверное, в каких-то B2C-продуктах это уже стало стандартом. Но для решений, ориентированных на large enterprise, где до сих пор встречаются интерфейсы в духе Windows 95, всё это выглядит как настоящая революция и какая-то космическая скорость изменений.

Возможно, через несколько лет интерфейсы в привычном понимании вообще покажутся странным рудиментом.

Расскажите, как менялось ваше восприятие AI? Сразу поверили, что это действительно всё изменит?

Читать про продукты в b2b