Как читать полную версию.
Эта статья — расширенная версия публикации на Хабре. Основная логика и ключевые выводы в обеих версиях совпадают, но здесь подробнее разобраны экономика полного цикла проверки гипотез, архитектура Product Intelligence Plane и Discovery Harness, уровни и горизонты агентной автономии, распределение ответственности и практический переход от рекомендательного режима к ограниченному автономному контуру. В полной версии также приведены дополнительные модели, критерии, примеры и исследовательские источники.
Если вы уже читали короткую версию, начинать сначала необязательно. Первая крупная часть, которой в ней нет, — «Когда падение конверсии у гипотез экономически оправдано?». Если хотите сосредоточиться именно на новом материале, после неё особенно рекомендую разделы «Пример архитектуры через модульный подход к продуктовому Discovery» и «Автономия: полномочия, охват и последствия ошибки».
Если короткую версию вы не читали, продолжайте по порядку, первые разделы вводят модель полного цикла ценности и терминологию, на которых строится дальнейший разбор.
Почему утроение разработки не утраивает эффективность бизнеса?.
Представим, что компания проверяет 100 гипотез в квартал. Предположим, что 20 из них подтверждаются и заметно двигают бизнес-метрики. После внедрения в процесс разработки AI-агентов, стоимость ее реализации снижается, а цикл от намерения до работающей фичи сокращается. Допустим, теперь компания, с теми же ресурсами, может проверять уже не 100, а 300 гипотез в квартал.
На первый взгляд, бизнес должен радоваться, ведь производительность выросла втрое. Но Discovery, качество данных, экспериментальная инфраструктура и управленческое внимание не выросли втрое. Первые 100 гипотез могут сохранить прежнюю конверсию в 20%, а следующие двести — дать, например, по 5%. Получится 30 успешных гипотез вместо 20. Производственный output вырос втрое, а количество положительных результатов — только на 50%. Расчёт иллюстративный, но вопрос финансового директора по итогам года вполне реален:
«Мы утроили производительность. Почему бизнес-результат не утроился?»
Ответ на него — не в разработке.
Сняв ограничение в Delivery, узкое место по Теории ограничений не исчезает, а переезжает. Организация обнаруживает следующие ограничения: достаточно ли у неё сильных гипотез, достоверных доказательств, качественных экспериментов, управленческого внимания и способности довести выпущенное изменение до принятия клиентом и роста бизнес-результата? Именно с этой точки я предлагаю посмотреть на whitepaper Сбера AI-Disrupt PDLC.
Если кто ещё не знаком с ним, настоятельно рекомендую ознакомиться, потому что далее я буду опираться на изложенную в нем архитектуру, структуру и терминологию: вот исходные документы, обновлённые в июне, — короткая версия и длинная, за авторством Кирилла Меньшова, старшего вице-президента и главы блока «Технологии» Сбера. На Хабре уже есть разбор для тех, кто пишет код, поэтому я не буду подробно пересказывать содержание документа, но затрону несколько ключевых для данной статьи идей.
Опираясь на более чем двенадцатилетний опыт развития продуктов и процессов Discovery в крупнейших экосистемах (Яндекс, Тинькофф, МТС, Сбер), я смотрю на цикл PDLC со стороны человека, которому потом приходится объяснять, зачем организация так быстро и качественно произвела то, что оказалось никому не нужно.
В этой статье я предлагаю продуктовую архитектуру полного цикла ценности — модель, которая связывает качество продуктового знания, принятие решений, реализацию и подтверждение результата в одну управляемую систему.
Две связанные архитектуры одного продуктового цикла.
AI-Disrupt PDLC исходит из того, что системный эффект возникает не от локального внедрения ИИ, а от перепроектирования операционной модели разработки. В его архитектуре человек формулирует намерение, агентная среда превращает его в реализацию, а валидация и управление встроены в сам процесс.
Если сильно упростить, архитектурное ядро AI-Disrupt PDLC образуют четыре связанных контура.
Петля намерения
Отвечает на вопрос «что именно мы хотим изменить, для кого и зачем?»
Петля реализации
Отвечает на вопрос «как превратить это решение в работающее изменение?»
Validation Spine
Сквозная система валидации. Проверяет не только то, работает ли код, но и то, соответствует ли результат исходному намерению, не ухудшились ли важные метрики и не возникли ли новые риски.
Governance Mesh
Система правил и полномочий. Определяет, какие действия агент может выполнять самостоятельно, где требуется участие человека, какие ограничения нельзя нарушать, кто отвечает за решение и как система должна действовать при ошибке.
Эта конструкция уже шире классического SDLC, потому что в нём есть Discovery, петля намерения, продуктовая валидация, эксплуатация и риск-адаптивная автономия. Но основной фокус этой архитектуры находится на переходе от сформулированного намерения к управляемой реализации.
Предлагаемая мной продуктовая архитектура работает с двумя соседними переходами:
- вверх по потоку создания ценности — от рыночного, клиентского, технологического, регуляторного или операционного сигнала к доказательствам и обоснованному намерению;
- вниз по потоку создания ценности — от релиза к принятию продукта клиентом, устойчивому бизнес эффекту и решению о дальнейшей судьбе инициативы.
У этих архитектур разные точки завершения. Для контура от намерения к реализации результатом становится работающее и эксплуатируемое изменение. Для продуктового — подтверждённый бизнес-эффект (изменение поведения клиента, экономики продукта, состояния портфеля или других целевых показателей). Поэтому, полный цикл, как система связанных контуров, выглядит так:
Продуктовая архитектура сочетается с теми же принципами AI-Disrupt PDLC: контекстом, прослеживаемостью, встроенной валидацией, управляемыми полномочиями и аудитом. В результате три перехода — от сигнала к намерению, от намерения к реализации и от реализации к ценности — становятся частями одной управляемой системы.
Когда Delivery ускоряется, старый фильтр исчезает
Медленная и дорогая разработка выполняла ещё одну функцию — она была неявным фильтром входящего потока идей. Инициативы конкурировали за инженерную мощность, поэтому до реализации доходила лишь часть идей. Этот фильтр был дорогим, медленным и часто несправедливым. Но он заставлял организацию хотя бы частично отбирать гипотезы до начала разработки.
Когда стоимость реализации резко снижается, этот механизм перестаёт работать. Плохо исследованную идею становится проще реализовать, чем всерьёз проверить. Спецификацию — проще сгенерировать, чем разобраться в качестве исходного намерения. Эксперимент — проще запустить, чем определить, какое решение должен изменить его результат.
«Слабая идея, выпущенная за две недели, остаётся слабой идеей.»
Организация начинает проверять больше гипотез. И возникает проблема, когда производительность растёт быстрее способности обеспечивать эти гипотезы доказательствами и своевременными решениями.
Разницу между этими двумя скоростями я называю разрывом доказательной ёмкости — Hypothesis Dilution Gap (это авторская аналитическая конструкция, а не общепринятая метрика).
При росте этого разрыва, количество экспериментов и релизов увеличивается, но среднее качество оснований для изменений снижается. Таким образом портфель начинает разбавляться. Организация быстрее превращает предположения в работающие решения, не успевая пропорционально улучшать качество отбора. Поэтому, после ускорения Delivery, роль фильтра должна перейти к качеству доказательств, ценности получаемой информации, скорости принятия решений и экономике инициативы.
Цель такой системы — повышать ценность портфеля изменений относительно его полной стоимости и риска.
Когда падение конверсии у гипотез экономически оправдано?.
Вернёмся к примеру из начала.
Ключевое слово — «полная».
Дешевле стала не вся проверка гипотезы, а прежде всего её производственная часть. Под проверкой здесь я понимаю полный путь от основания гипотезы до решения по результату, а не только запуск эксперимента. В стоимость проверки входят Discovery, подготовка данных, дизайн эксперимента, запуск, аналитика, интерпретация, управленческое решение, коммуникация с клиентом, обслуживание, возможный откат и восстановление после неудачного изменения.
Даже положительный результат ещё не равен ценности. Он должен пройти через запуск, принятие клиентом, операционную готовность и проверку устойчивого эффекта. Поэтому вопрос звучит не «Какая у нас конверсия гипотез?», а
«Сколько стоит один положительный результат и как меняется стоимость следующего?»
Иногда снижение конверсии оправдано. Например, если стоимость проверки резко упала, а успешные результаты дают больше ценности. Тогда организация может позволить себе исследовать более дальние и неопределённые зоны. Но иногда снижение конверсии означает, что система начала масштабировать слабые решения быстрее, чем научилась получать надёжное знание.
Поэтому важно диагностировать полный цикл ценности и определять, на каком этапе у нас сейчас узкое место.
Четыре способности полного продуктового цикла.
Для диагностики полного цикла ценности я предлагаю различать четыре способности организации. Эта модель сочетается с архитектурой AI-Disrupt PDLC — ее контуры показывают, как организован переход от намерения к реализации, а четыре способности помогают определить, на каком участке система теряет пропускную способность.
Способность получать надёжное знание
Способность получать и проверять своевременное и пригодное для принятия решения продуктовое знание.
Способность принимать решения
Способность превращать полученное знание в решение.
Способность реализовывать решения
Способность превращать принятое решение в работающее изменение.
Способность доводить изменения до результата
Доводить выпущенное изменение до принятия клиентом, устойчивого операционного исполнения и измеримого результата.
Способность получать надёжное знание складывается из исследований, качества данных, экспериментальной инфраструктуры, аналитической компетенции и системы накопления знаний. Это не объём данных в корпоративной базе знаний или базах данных. Петабайты информации бесполезны, если исследования не связаны с гипотезами, гипотезы — с экспериментами, эксперименты — с решениями, а решения — с результатом.
Способность принимать решения нужно измерять отдельно. Если результат эксперимента две недели ждёт человека, который имеет право остановить инициативу, изменить бюджет или разрешить масштабирование, узкое место находится уже не в аналитике, а в управленческой системе.
Способность реализовывать решения определяет, насколько быстро и надёжно принятое решение превращается в спецификацию, код, работающий продукт и управляемый релиз.
Способность доводить изменения до результата определяет, способна ли организация превратить релиз в реальную ценность. В неё входят сегмент, позиционирование, канал, коммуникация, активация, поддержка, обучение сотрудников, инфраструктурная мощность, наблюдение результата после запуска и способность вовремя масштабировать, изменить или закрыть решение. Именно эта способность объясняет, почему релиз может технически состояться, а бизнес-результат — нет. Если клиент не понял ценность, не получил доступ, столкнулся с неподготовленной поддержкой или перестал пользоваться продуктом после первого контакта, способность реализовывать решения отработала, а способность доводить изменения до результата — нет.
Эти способности связаны, но не возникают автоматически одна из другой. Организация может быстро проводить исследования, но месяцами не принимать по ним решений. Может быстро выбирать направление, но медленно его реализовывать. Может выпускать изменения ежедневно, но не обеспечивать их принятием клиентом и устойчивым результатом. Поэтому скорость полного цикла определяется не самой развитой, а самой ограниченной из четырёх способностей. И чтобы локальное ускорение не принималось за системный результат, метрики производительности необходимо ставить в пары:
| Что обычно измеряют | С чем нужно сопоставлять |
|---|---|
| Количество гипотез и скорость исследований | Время до достаточного основания для решения и ценность полученной информации |
| Количество проведённых экспериментов | Время от результата эксперимента до управленческого решения |
| Time-to-Market и стоимость разработки | Время от решения до релиза и стоимость подтверждённого положительного результата |
| Количество релизов | Принятие продукта, нагрузку на поддержку и устойчивый клиентский или экономический эффект |
На уровне всего портфеля итоговой метрикой становится ценность произведенных изменений, относительно полной стоимости и риска.
Такие метрики позволяют увидеть, где именно возникло новое ограничение — в получении знания, принятии решения, реализации или доведении изменения до результата. Один из наиболее незаметных разрывов возникает между экспериментом и управленческим решением.
От эксперимента к решению.
Эксперимент не является решением. Он уменьшает неопределённость и показывает, насколько надёжно можно судить о гипотезе. Решение определяет, что организация будет делать дальше: продолжать инвестиции, менять направление, масштабировать или останавливать инициативу. Вместе с этим оно распределяет капитал, ответственность и риск. Поэтому качество экспериментального контура нельзя оценивать только количеством проведённых проверок или долей подтвердившихся гипотез. Для модели полного цикла я предлагаю различать четыре исхода:
| Исход | Что означает | Экономический смысл |
|---|---|---|
| Положительный результат | Гипотеза получила достаточное подтверждение, эффект практически значим, guardrail-метрики не ухудшились | Можно рассматривать масштабирование |
| Информативный отрицательный результат | Гипотеза не получила подтверждения, но эксперимент надёжно сузил направление дальнейших действий | Позволяет не инвестировать в слабое направление или изменить подход |
| Неубедительный результат | Данных, длительности, мощности выборки или качества измерения не хватило | Деньги потрачены, неопределённость почти не уменьшилась |
| Невалидный результат | Эксперимент был спроектирован или проведён с ошибкой | Создаёт ложное знание и может привести к неверному решению |
Все четыре исхода стоят денег. Первые два могут создавать ценность. Третий почти не уменьшает неопределённость. Четвёртый создаёт правдоподобный, но ложный вывод — и именно поэтому особенно опасен. Отсюда следует, что гипотезы нужно приоритизировать не только по ожидаемому эффекту, но и по ценности информации — способности результата изменить последующее решение.
Проверка имеет высокую ценность, если её результат действительно может повлиять на распределение бюджета, выбор сегмента, способ реализации, масштабирование или закрытие инициативы. Если организация заранее не готова изменить принятое направление, эксперимент превращается в обычный ритуал.
«Право закрыть слабую инициативу — такой же управленческий актив, как право масштабировать сильную.»
В этой части продуктовая архитектура использует тот же принцип встроенной валидации, который AI-Disrupt PDLC применяет к спецификации и реализации. Но объектом проверки становятся доказательства и решения:
- откуда появилась гипотеза;
- соответствует ли выбранный метод поставленному вопросу;
- достаточно ли надёжен результат;
- рассмотрены ли альтернативные объяснения;
- какое действие действительно следует из полученного знания.
Чтобы сохранить прослеживаемость и не создавать набор разрозненных документов, я предлагаю использовать единую сквозную запись решения, которая последовательно меняет состояние:
| Состояние записи | Когда формируется | Что фиксирует |
|---|---|---|
| Карточка гипотезы | До эксперимента |
|
| Контракт на эксперимент | До запуска |
|
| Протокол решения | После эксперимента |
|
Это три состояния одного объекта обеспечивают прослеживаемость:
Карточка гипотезы защищает организацию от ситуации, когда правдоподобная идея немедленно превращается в эксперимент, не пройдя проверку качества исходных подтверждений и возможных альтернатив. В агентном контуре это особенно важно. Агент может быстро собрать убедительный текст вокруг слабого основания. Но убедительный текст не делает основание сильным.
Контракт на эксперимент не позволяет поменять метрику, сегмент или критерий успеха после появления результата и объявить успехом любое движение графика. Без такого контракта эксперимент легко превращается в поиск красивого объяснения уже полученного числа.
Протокол решения усиливает Способность принимать решения — не просто понять результат, а выбрать действие с учётом стоимости, риска, альтернатив и ответственности. Результат эксперимента и управленческое решение — не одно и то же. Статистически значимый прирост может не покрывать стоимость масштабирования, улучшать основную метрику за счёт маржи или поддержки, работать только для отдельного сегмента или ухудшать долгосрочное поведение клиента. Например, эксперимент мог показать прирост конверсии в одном сегменте. Но масштабирование на всю базу может оказаться экономически невыгодным из-за поддержки, маржи, нагрузки на канал или роста операционного риска.
После принятия решения начинается следующий переход полного цикла — реализация должна не просто завершиться релизом, а привести к принятию продукта и устойчивому результату.
Релиз — это середина.
Релиз завершает переход от намерения к работающей реализации, но не завершает полный цикл ценности. После него начинается другой переход — выпущенное изменение должно стать доступным, понятным и полезным для клиента, выдержать эксплуатацию и создать устойчивый измеримый эффект. Поэтому технический успех и продуктовый результат нужно оценивать отдельно.
Изменение может быть реализовано в соответствии со спецификацией и при этом не дать ожидаемого эффекта — например из-за ошибки на участке между релизом и принятием. Результат запуска зависит как минимум от пяти связанных предположений:
Если одна из переменных определена неверно, сильный продукт может показать слабый результат.
Можно сделать полезную функцию, но предложить её не тому сегменту.
Можно выбрать правильный сегмент, но не объяснить ценность.
Можно хорошо объяснить ценность, но прийти через канал, которому клиент не доверяет или которым он вообще не пользуется.
Можно выбрать правильный канал, но обратиться в момент, когда проблема для клиента неактуальна.
Поэтому низкое принятие ещё не доказывает, что продукт не нужен, сначала необходимо определить, какое именно предположение не сработало.
Чтобы этот переход оставался проверяемым, сквозная запись решения должна получить ещё одно состояние — готовность к запуску и эксплуатации:
| Область | Что фиксируется |
|---|---|
| Принятие продукта | Целевой сегмент, ценностное сообщение, канал, формат и время коммуникации |
| Запуск | План роллаута, критерии успешного запуска и условия пересмотра решения |
| Эксплуатация | Модель поддержки, прогноз нагрузки, маршруты эскалации, владельцы и план отката |
Эта запись нужна для связи продуктового решения с условиями, при которых оно действительно может стать ценностью. После запуска система должна ответить на четыре вопроса:
- 01Понял ли клиент ценность и получил ли доступ к продукту?
- 02Сработали ли сообщение, канал и сценарий активации?
- 03Выдержали ли поддержку, сотрудники и инфраструктура фактическую нагрузку?
- 04Возник ли устойчивый эффект и какое решение следует принять дальше: масштабировать, изменить, продолжить наблюдение, поддерживать или закрыть?
Так две архитектуры решают симметричные задачи. AI-Disrupt PDLC делает проверяемым переход от намерения к реализации. Предлагаемая продуктовая архитектура делает проверяемым переход от релиза к принятию, устойчивому результату и решению о дальнейшей судьбе инициативы, а так же отслеживать цепочку:
Для этого организации нужна память, которая сохраняет не только само изменение, но и историю его происхождения — на каких данных возникла гипотеза, как она проверялась, какое решение было принято и подтвердилось ли оно после запуска.
Product Intelligence Plane и Discovery Harness.
Агентному Discovery недостаточно доступа к документам, корпоративному поиску или RAG. Найти старое интервью, отчёт аналитика или результат эксперимента — не значит понять, насколько этому знанию можно доверять и применимо ли оно к текущему решению. Для формирования обоснованного намерения система должна сохранять не только содержание, но и контекст знания:
- из какого источника оно получено;
- каким методом и когда;
- для какого сегмента и ситуации;
- где проходит граница его применимости;
- какое решение было принято на его основании;
- подтвердилось ли это решение после запуска.
При этом важно различать типы объектов. Например:
Если эта структура теряется, в корпоративной памяти остаётся правдоподобная фраза «клиенты не понимают фичу» без источника, метода и границ применимости. Человек иногда компенсирует потерю контекста личным опытом, но агент в таком случае будет распространять галлюцинацию на множество последующих решений.
Информационный фундамент, который связывает продуктовые знания и сохраняет их происхождение, я называю Product Intelligence Plane — PIP, который отвечает на вопрос:
«Что организация знает, на каких основаниях она это знает и к каким результатам привели принятые решения?»
В нём связаны:
Минимально в нём должны жить:
- единая идентификация клиента между аналитикой, CRM и поддержкой;
- источник, дата, сегмент и метод получения каждого существенного подтверждения;
- понимание актуальности и срока жизни данных;
- разделение фактов, интерпретаций, гипотез, прогнозов и решений;
- связь evidence → hypothesis → experiment → decision → specification → outcome;
- реестр экспериментов;
- журнал решений и условий их пересмотра;
- причины отказа от гипотез;
- качественные отрицательные результаты, чтобы не возвращаться к уже проверенным слабым направлениям;
- история каналов, сообщений, сегментов и результатов принятия продукта;
- результаты после релиза, а не только результаты до решения.
Но структурированной памяти недостаточно. Разные продуктовые вопросы требуют разных способов получения доказательств. Гипотеза роста может проверяться через воронки, когорты и экономику. Гипотеза о клиентской проблеме — через интервью, обращения и наблюдение за поведением. Гипотеза о риске — через инциденты, ограничения и анализ последствий.
Однако, из интервью нельзя автоматически сделать вывод о масштабе проблемы. Корреляция в аналитике не доказывает причинность. Возможность провести A/B-тест не означает, что он подходит для конкретной гипотезы. Поэтому вторым элементом продуктовой архитектуры становится Discovery Harness — исполняемая среда получения и проверки продуктового знания, которая отвечает на другой вопрос:
«Каким методом получить достаточное знание и преобразовать его в следующий проверяемый продуктовый артефакт?»
В эту среду входят:
- оркестрация последовательности действий;
- управление контекстом;
- краткосрочная память задачи;
- долговременная память продукта и решений;
- специализированные исследовательские процессы;
- библиотека атомарных агентных операций;
- детерминированные аналитические и статистические инструменты;
- интеграции с корпоративными системами;
- валидаторы промежуточных и итоговых результатов;
- политики доступа и исполнения;
- ограничения на использование клиентских данных;
- условия эскалации к человеку;
- границы того, какие выводы агент может только предложить, а какие действия может подготовить к исполнению;
- журнал действий и происхождения выводов;
- система оценки качества.
Отдельный агентный навык в такой архитектуре — повторно используемая операция. Например:
- извлечь темы из обращений;
- проверить полноту источников;
- рассчитать изменение юнит-экономики;
- найти противоречащие доказательства;
- сопоставить гипотезу с прошлыми экспериментами;
- проверить, были ли уже похожие решения и чем они закончились;
- определить, какие сегменты затронуло изменение;
- проверить, не противоречит ли гипотеза ограничениям канала или правилам клиентского воздействия;
- подготовить черновик карточки гипотезы;
- собрать основания для протокола решения.
Масштабировать нужно не каталог промптов и не количество навыков или скиллов. Масштабировать нужно воспроизводимые рабочие контуры, для которых известны:
- входной сигнал;
- необходимые данные;
- исследовательский метод;
- последовательность операций;
- критерии качества;
- допустимые действия;
- правила эскалации;
- итоговый артефакт;
- журнал происхождения вывода;
- условия пересмотра результата.
И здесь важно не перепутать роль модели с ролью всей среды. Языковая модель не должна выполнять работу, которую можно надёжно выполнить кодом, запросом к базе или статистическим модулем.
Расчёты, проверка схем, применение политик, контроль лимитов, статистические тесты, поэтапная выкатка, откат и журналирование должны оставаться детерминированными. То есть выполняться предсказуемым кодом и проверяемыми процедурами, а не языковой моделью.
Модели стоит передавать задачи, где действительно требуется работа с неоднозначностью — синтез свидетельств, построение альтернатив, формулирование вопросов, критика гипотез и интерпретация ограниченного контекста.
Итого:
| Компонент | Основная функция |
|---|---|
| Product Intelligence Plane | Сохраняет источники, контекст, связи, актуальность и историю продуктового знания |
| Discovery Harness | Выбирает и исполняет допустимые методы, проверяет качество результата и управляет переходом к следующему артефакту |
Пример архитектуры через модульный подход к продуктовому Discovery.
Модульная агентская система собирает и обрабатывает внутренние и внешние данные, формирует на их основе продуктовые гипотезы, подвергает их критическому анализу на предоставленном материале, ранжирует и подготавливает к передаче к проведению экспериментов. Целевое состояние системы — воспроизводимый процесс, в котором агентская система:
- собирает релевантные данные и материалы из внутренних и внешних источников;
- очищает, нормализует и связывает данные между собой;
- выявляет проблемы, закономерности, аномалии и потенциальные точки роста;
- формулирует проверяемые продуктовые гипотезы;
- создает альтернативные объяснения выявленных проблем и возможностей;
- ищет подтверждающие и опровергающие доказательства;
- оценивает потенциальный бизнес-эффект;
- предлагает дизайн эксперимента и критерии принятия решения;
- сохраняет гипотезы, доказательства и результаты экспериментов в единой базе знаний.
Типы специализированных модулей
Экономика продукта и точки роста
Где находятся экономические точки роста и как продуктовые рычаги влияют на финансовый результат?
- · продуктовые события, воронки, каналы и сегменты
- · финансовые и транзакционные данные
- · доходы, расходы, комиссии и стоимость обслуживания
- · планы, история, релизы и маркетинговый контекст
- · согласует экономическую единицу, когорты, аллокации, формулы и дерево метрик
- · автоматически считает факт, историю и когортные показатели
- · строит прогноз, план-факт, сценарии и чувствительность
- · выявляет аномалии, локализует сегменты и оценивает финансовое влияние
- · передает Генератору гипотез количественно подтвержденные сигналы роста
Результат: Исполняемая модель экономики продукта; дерево драйверов; факт и прогноз метрик; мониторинг; оцененные точки роста.
Выбирать, если: нужно понять, какие изменения продукта способны дать измеримый финансовый эффект.
Потребности и барьеры клиентов
Какие проблемы, потребности, мотивы и барьеры действительно повторяются у клиентов?
- · интервью и UX-исследования
- · отзывы, обращения и жалобы
- · звонки и транскрипты
- · другие материалы клиентской обратной связи
- · извлекает потребности, проблемы и мотивы
- · нормализует формулировки и объединяет сходные сигналы
- · кластеризует темы и выявляет устойчивые паттерны
- · сравнивает сегменты и этапы клиентского пути
- · формирует доказательный слой для клиентских гипотез
Результат: Карта потребностей и проблем, барьеры, причины отказа, различия между сегментами, гипотезы улучшения клиентского пути.
Выбирать, если: нужно понять причины поведения клиента.
Статистическая проверка гипотез
Насколько проблема распространена и какие различия между сегментами статистически значимы?
- · опросы и анкеты
- · шкалы и результаты тестов
- · структурированные исследовательские выборки
- · сегментные данные
- · проверяет качество и структуру исследовательских данных
- · анализирует выборку и статистическую надежность
- · выявляет значимые различия и зависимости
- · сегментирует ответы и оценивает распространенность факторов
- · проверяет количественно предположения, найденные другими модулями
Результат: Оценка масштаба проблемы, значимые сегментные различия, факторы поведения, подтвержденные или опровергнутые предположения.
Выбирать, если: нужно перейти от качественного наблюдения к оценке масштаба и статистической проверке.
Организационная память и прошлые решения
Что организация уже знает об этой задаче, что уже проверяла и почему принимались прошлые решения?
- · внутренние исследования и аналитические отчеты
- · архив гипотез и результаты экспериментов
- · решения продуктовых комитетов
- · презентации, документы и выводы прошлых запусков
- · находит релевантные знания и связывает документы между собой
- · выявляет похожие или повторяющиеся гипотезы
- · восстанавливает основания прошлых решений
- · учитывает успешные, неуспешные и отклоненные инициативы
- · создает машиночитаемую организационную память Discovery
Результат: Связанные исследования, решения и эксперименты; исключение повторов; переиспользование накопленного опыта.
Выбирать, если: нужно перестать заново исследовать уже известное и использовать историю организации как доказательство.
Рыночные тренды и новые возможности
Какие внешние изменения создают новые возможности или риски для продукта?
- · рыночная и отраслевая статистика
- · исследования и макропоказатели
- · экспертные публикации и новости
- · технологические тренды и данные смежных рынков
- · мониторит изменения рынка и тренды
- · выявляет потенциальные ниши и новые модели поведения
- · сопоставляет сигналы из смежных отраслей
- · проверяет актуальность и происхождение внешних источников
- · связывает внешние изменения с продуктовым доменом и сегментами
Результат: Гипотезы о новых продуктах, сегментах, каналах, нишах и бизнес-моделях; структурированный внешний контекст.
Выбирать, если: нужно искать возможности за пределами текущей продуктовой аналитики и клиентской базы.
Конкурентные разрывы и угрозы
Как меняются предложения конкурентов и где возникают разрывы в нашем продукте?
- · предложения и тарифы
- · функции и клиентские сценарии
- · публичные интерфейсы и коммуникации
- · изменения продуктов и условий конкурентов
- · отслеживает изменения конкурентов
- · сравнивает предложения, функции и сценарии
- · выявляет конкурентные разрывы и угрозы
- · ищет незакрытые потребности и зоны дифференциации
- · преобразует изменения конкурентной среды в проверяемые продуктовые гипотезы
Результат: Карта конкурентных изменений, угрозы, незакрытые потребности, гипотезы дифференциации и реакции.
Выбирать, если: необходимо мониторить конкурентов и оперативно реагировать на их действия.
Качество гипотез определяется полнотой и качеством исходных данных, корректностью методов их обработки, достоверностью доказательств и связностью информации между источниками. Для разных типов гипотез требуются разные источники и способы подготовки информации. Для гипотез роста необходима модель юнит-экономики, для клиентских гипотез — обработка интервью и отзывов, для гипотез на основе количественных исследований — результаты опросов и анкетирования, для рыночных и конкурентных гипотез — данные о рынке, конкурентах, регулировании и трендах.
Общая логика агентской системы:
1. Источники
Система может работать с несколькими классами источников:
- продуктовые и финансовые данные;
- CRM, BI и транзакционные системы;
- интервью, отзывы, обращения и исследования;
- опросы и количественные исследования;
- внутренняя база знаний и история экспериментов;
- рыночные данные, исследования и публикации;
- конкурентные предложения, тарифы, функции и клиентские сценарии;
- продуктовые релизы, маркетинговые кампании, операционные инциденты, регуляторные изменения и другие сопутствующие события.
2. Специализированные модули
Каждый специализированный модуль обрабатывает определённый класс источников и формирует структурированные аналитические результаты: факты, сигналы, закономерности, отклонения, оценки и другие объекты, которые могут быть использованы системой при формировании и проверке гипотез.
| Модуль | Формируемые аналитические результаты |
|---|---|
| Экономика продукта и точки роста | Метрики, дерево драйверов, прогнозы, аномалии, оценка финансового эффекта |
| Потребности и барьеры клиентов | Потребности, проблемы, мотивы, барьеры, клиентские паттерны |
| Статистическая проверка гипотез | Оценки распространённости, статистические различия, факторы поведения |
| Организационная память и прошлые решения | Связанные исследования, решения, гипотезы и результаты экспериментов |
| Рыночные тренды и новые возможности | Рыночные сигналы, тренды, возможности, изменения сегментов |
| Конкурентные разрывы и угрозы | Изменения предложений, конкурентные разрывы, угрозы и возможности дифференциации |
3. Единый доказательный слой
Аналитические результаты специализированных модулей объединяются в едином доказательном слое. Он обеспечивает связность информации между продуктами, сегментами, периодами, метриками, исследованиями, рыночными сигналами, гипотезами и экспериментами. Для каждого доказательства или аналитического объекта фиксируются:
- источник и происхождение;
- дата и актуальность;
- степень достоверности;
- владелец;
- продукт и сегмент;
- связанные метрики;
- связанные исследования;
- связанные гипотезы;
- результаты проверки и экспериментов.
4. Генератор гипотез
На основе данных система:
- 01выявляет проблемы, закономерности, аномалии и возможности;
- 02формирует несколько альтернативных гипотез;
- 03ищет подтверждающие и опровергающие доказательства;
- 04связывает гипотезу с целевыми метриками и контрметриками;
- 05оценивает потенциальный эффект;
- 06проверяет наличие похожих ранее протестированных идей;
- 07формирует скоринг и приоритет;
- 08предлагает дизайн эксперимента.
5. Общие сквозные компоненты
Независимо от выбранных модулей система может включать:
- оркестрацию агентных процессов;
- библиотеку скиллов и детерминированных инструментов;
- краткосрочную и продуктовую память;
- API/MCP-интеграции;
- ролевую модель и разграничение доступов;
- маскирование чувствительных данных, guardrails;
- журналирование;
- валидацию промежуточных и итоговых результатов;
- систему оценки качества;
- пользовательский интерфейс;
- интеграцию с разрешенной корпоративной или локальной LLM.
Что требуется для подключения
Требования различаются в зависимости от выбранного модуля. На старте проводится диагностика доступности, качества и связности источников.
| Модуль | Основные данные | Требовательность | Основные участники |
|---|---|---|---|
| Экономика продукта и точки роста | Продуктовые, финансовые, транзакционные данные, воронки, сегменты, история | Высокая | Владелец продукта, финансисты, аналитики, ИБ |
| Потребности и барьеры клиентов | Интервью, отзывы, обращения, звонки, исследования | Средняя | Владелец продукта, исследователи |
| Статистическая проверка гипотез | Опросы, анкеты, тесты, сегментные данные | Средняя | Исследователи, продуктовые аналитики |
| Организационная память и прошлые решения | Документы, исследования, гипотезы, эксперименты, решения | Средняя | Владелец продукта, владелец базы знаний |
| Рыночные тренды и новые возможности | Рыночные исследования, статистика, внешние публикации | Низкая–средняя | Стратег, владелец продукта |
| Конкурентные разрывы и угрозы | Предложения, тарифы, функции, публичные интерфейсы | Низкая–средняя | Владелец продукта, стратег |
Масштабировать в такой системе нужно воспроизводимые исследовательские контуры с известными входами, методами, результатами и ограничениями. PIP и Discovery Harness являются самостоятельными элементами предлагаемой продуктовой архитектуры и сочетаются с AI-Disrupt PDLC через общие принципы контекста, прослеживаемости, валидации, полномочий и аудита.
Результаты после запуска возвращаются в PIP и становятся основанием для следующего решения. Так продуктовый цикл получает память не только о том, что было реализовано, но и о том, почему это было решено реализовать и к какому эффекту это привело.
Наличие данных, методов и прослеживаемости, однако, ещё не определяет, какие действия агент может выполнять самостоятельно. Для этого необходима отдельная модель автономии, учитывающая полномочия, охват и последствия ошибки.
Автономия: полномочия, охват и последствия ошибки.
AI-Disrupt PDLC рассматривает автономию как управляемую и риск-адаптивную. Для продуктового цикла я предлагаю описывать её через три независимых измерения:
| Измерение | На какой вопрос отвечает |
|---|---|
| Полномочия | Какие действия агенту разрешено выполнять и какие решения он вправе принимать |
| Охват | Какую часть продуктового цикла, сколько систем и организационных доменов он затрагивает |
| Последствия | Насколько серьёзна и обратима возможная ошибка |
Агент может самостоятельно действовать внутри одной узкой и хорошо наблюдаемой операции. Или участвовать в нескольких стадиях продуктового цикла, но только готовить рекомендации для человека. В первом случае у системы высокие полномочия и узкий охват. Во втором — широкий охват и низкие полномочия. Риски, требования к данным, устройству контроля, откату и человеческому участию у них различаются. Поэтому одной фразой «агент принимает решения» такую систему описать невозможно.
Ось полномочий: A0–A5
Первая ось отвечает на вопрос: что агенту разрешено делать?
Эта шкала важна тем, что отделяет подготовку действия от исполнения, а исполнение — от жизненного решения. Например, агент может подготовить проект решения о закрытии гипотезы. Это ещё не значит, что он имеет право закрыть её сам. Он может собрать основания, указать противоречия, рассчитать стоимость продолжения, найти похожие прошлые случаи и предложить решение владельцу продукта. Но право изменить статус инициативы — это уже другой уровень полномочий.
Ось охвата: S0–S5
Вторая ось отвечает на вопрос: какую часть жизненного цикла держит агент?
Агент может иметь широкий охват и слабые полномочия: например, читать клиентский фидбэк, сопоставлять его с аналитикой, смотреть историю экспериментов и приносить владельцу продукта список гипотез с основаниями. Это может быть S3, но всего лишь A1 или A2. И наоборот, агент может иметь высокие полномочия внутри очень узкого контура: например, управлять ставкой, лимитом, порядком показа или маршрутизацией обращения в заранее заданных границах. Это может быть A4, но только S1.
A0–A5 и S0–S5 — это не лестница зрелости и не план «как дойти до A5 × S5». Это язык описания формы автономии. Зрелость такого режима и право его применять нужно оценивать отдельно.
Именно поэтому вопрос «можно ли агенту принимать решения?» не имеет смысла без уточнения — какие решения, где, для какой аудитории, с каким откатом, с каким наблюдением и с какими последствиями.
Последствия: цена ошибки как третье измерение
Полномочия и охват описывают форму автономии. Но они ещё не отвечают на вопрос, допустима ли она в конкретном контексте. Для этого нужно третье измерение — значимость последствий. Одинаковые полномочия и одинаковый охват могут создавать совершенно разный риск. Изменить текст описания продукта для одного процента пользователей и изменить условия кредитного продукта для всей клиентской базы — технически могут быть похожими действиями. Но организационно это разные вселенные. Поэтому отдельно нужно оценивать:
- обратимость действия;
- размер затронутой аудитории;
- финансовый масштаб;
- влияние на клиента;
- юридические и регуляторные последствия;
- дискриминационный риск;
- влияние на репутацию;
- скорость, с которой человек может вмешаться;
- качество и скорость обратной связи;
- возможность обнаружить ошибку до того, как она станет системной.
Чем ближе автономия к клиентскому воздействию, деньгам, условиям продукта и решению о судьбе инициативы, тем выше цена ошибки и тем уже должен быть мандат. В упрощённом виде риск автономии можно представить так:
«Риск автономии ≈ Полномочия × Охват × Последствия»
Это скорее практическое правило — чем шире полномочия агента, длиннее участок цикла и серьёзнее последствия ошибки, тем выше требования к доказанной надёжности, наблюдаемости, ограничениям, откату и человеческому контролю. Высокая цена последствий не означает автоматического запрета автономии. Она означает, что автономия должна получать более узкий мандат, более сильные гейты подтверждения и более дорогой контур контроля. И наоборот: низкая цена ошибки не означает, что можно игнорировать качество данных, метод и журнал действий. Она лишь позволяет сделать контроль дешевле и легче.
Несколько разных автономий, которые не стоит путать.
Автоматическое управление ставками в рекламных аукционах — пример автономии примерно уровня A4 × S1 (это кстати не обязательно пример языкового агента, а пример класса ограниченной автономии, когда система сама выбирает действие внутри узкого, наблюдаемого и быстро корректируемого контура). Система самостоятельно распоряжается деньгами, но внутри одной узкой операции. Такие контуры работают много лет, потому что в них есть богатый сигнал, понятная целевая функция, быстрая обратная связь и обратимые действия. Это подтверждает общий принцип — узкая автономия хорошо работает там, где контур наблюдаем, ограничен и быстро корректируется.
Агент, который читает клиентский фидбэк, сопоставляет его с продуктовой аналитикой, строит карту проблем и приносит владельцу продукта ранжированный список гипотез, — это примерно A1 × S3. У него широкий охват, но почти нет полномочий. Он может участвовать в нескольких стадиях цикла — от сигнала до подготовки решения, — но окончательный выбор остаётся за человеком.
Такая система может быть полезна уже сегодня, потому что ошибка рекомендации обычно обнаружима и обратима. Человек может проверить источник, отвергнуть предлагаемый вывод или запросить дополнительные данные. На практике это может быть не один универсальный агент, а связанный контур специализированных модулей как я показывал на примере архитектуры.
Агент, который самостоятельно запускает ограниченные эксперименты, следит за guardrail-метриками и выполняет откат при заранее определённых условиях, — это уже примерно A4 × S4. Это полноценный ограниченный автономный контур.
Финал статьи — разделы «Горизонты автономии: от H0 к саморазвивающемуся продукту», «Распределение ответственности» и «С чего начинать» — готовится к публикации и будет добавлен в эту версию.