Стресс-тест продуктовых гипотез с помощью агентных ИИ-систем
Спикер: Сергей Синяков
Откровенно плохие идеи обычно отсеиваются быстро. А правдоподобные совпадают со стратегией, нравятся команде и звучат логично. Если добавить данные, мнения пользователей и убедительную формулировку от ИИ, гипотеза начинает выглядеть почти доказанной.
Мы привыкли защищать идеи: искать аргументы в их пользу и постепенно влюбляться в собственную конструкцию. А можно действовать наоборот — подвергать гипотезу нагрузке до того, как она попадет в разработку, чтобы отсеивать нерелевантные и брать в работу лишь те, которые принесут большую пользу бизнесу.
Проверять гипотезу через призму доказательств, ролей и противоречий можно тремя способами:
1. Вручную собирать и связывать всю имеющуюся информацию — качественно, но дорого.
2. Передать весь контекст модели одним большим запросом — удобно, но недостаточно проверяемо.
3. Разделить анализ на этапы с помощью агентного конвейера — надежно и обоснованно.
Почему одного большого промпта недостаточно?
Проблема большого запроса в его непрозрачности: мы получаем уверенный ответ, но не видим, на чем он основан. В агентной системе стресс-тест гипотезы на каждом этапе создает отдельный проверяемый результат, поэтому исследование можно проверить или перезапустить с любого шага.
Стресс-тест проходит через четыре слоя:
гипотеза → роли → рынок → синтез
Технически каждый этап оформлен как отдельный скилл. Это позволяет не смешивать роли, факты и рыночные данные раньше времени, а решение о запуске гипотезы оставить за человеком.
Кейс: очередь сканирования в анализаторе кода
Представим, что мы — вендор информационной безопасности и делаем продукт для безопасной разработки: анализатор исходного кода. Пользователи загружают в него проекты, которые необходимо проверить. Пропускная способность конвейера ограничена, поэтому проекты попадают в очередь и ждут сканирования.
С системой работают инженеры по безопасности, директор по информационной безопасности и разработчики. У каждой роли свои цели и критерии их достижения. При этом в бэклог постоянно поступают запросы на доработку, а ограниченные ресурсы нужно направлять на изменения, которые принесут бизнесу наибольшую пользу.
Наша исходная гипотеза звучит так:
Если инженер по безопасности сможет вручную приоритизировать проекты, бизнес-критичные проекты будут сканироваться первыми, а время обнаружения уязвимостей высокого риска сократится.
Дальше гипотеза проходит через несколько скиллов:
—
hypothesis-input-validation проверяет корректность формулировки и не пропускает дальше невалидную гипотезу;
—
hypothesis-facilitator рассматривает гипотезу с позиций разных ролей и фиксирует различия в их выводах;
—
local-knowledge-retrieval формирует предварительный обзор, извлекает отдельные факты и находит связанные артефакты;
—
business-context-value-check определяет, кто заинтересован в гипотезе с точки зрения бизнеса и какую ценность она может принести;
—
hypothesis-market-layer изучает внутреннюю документацию, а затем обращается к внешним источникам;
—
hypothesis-synthesis сопоставляет собранные данные и формулирует выводы;
—
customer-discovery-planning превращает найденные пробелы в план интервью, чтобы закрыть их с помощью новых данных;
—
human-report-export собирает понятный человеку отчет со ссылками на все необходимые артефакты.
Что показал стресс-тест?
После всех этапов выяснилось, что гипотеза в первоначальной формулировке не приносит ожидаемой пользы.
Настоящая задача — не просто быстрее обнаружить риск, а сократить время от появления критичной находки до конкретного действия по ней.
Стресс-тест сделал идею честнее и проверяемее.
Когда такой подход оправдан
Полноценный стресс-тест нужен не каждой гипотезе. Его стоит запускать, когда решение:
— дорого реализовать;
— трудно откатить;
— займет несколько спринтов;
— нельзя проверить одним быстрым экспериментом.
Если ошибка стоит меньше спринта, проще провести короткий тест, чем запускать исследовательский космолет.
@productsense
