Намерение, спецификации и контекст в AI-Native SAFe: как управлять разработкой продуктов с ИИ

Материал подготовлен на основе статьи Scaled Agile, Inc. «AI-Native Intent, Specifications, and Context». Это неофициальный перевод и редакционная адаптация для русскоязычной аудитории. Перевод и адаптация подготовлены Алексеем Ионовом, основателем «Ионов и Партнеры», Advanced SPC.

Намерение, спецификации и контекст в AI-Native SAFe – это три связанных элемента продуктового управления, которые помогают компаниям согласовать стратегические цели бизнеса, требования к продукту и реальные условия, в которых решение должно быть успешным. Намерение отвечает на вопрос «почему создаётся продукт или изменение», спецификации описывают «что должно быть реализовано и как это проверить», а контекст показывает «где, для кого и с какими ограничениями должно работать решение».

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

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

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

Если стратегия, результаты, ограничения и критерии успеха не описаны явно, ИИ начинает ускорять неопределенность. Связка «намерение – спецификации – контекст» помогает сделать работу с ИИ управляемой, проверяемой и связанной с бизнес-результатами.»

Алексей Ионов, основатель «Ионов и Партнеры», Advanced SPC, эксперт по Lean-Agile трансформациям и SAFe в России и СНГ

Кратко: главное о намерении, спецификациях и контексте в AI-Native SAFe

• Намерение отвечает на вопрос «почему»: какую проблему нужно решить, какую ценность создать и какой бизнес-результат поддержать.
• Спецификации отвечают на вопросы «что» и «как»: что именно должно быть реализовано, каким требованиям, правилам и ограничениям должна соответствовать работа.
• Контекст отвечает на вопрос «где и в каких условиях»: для каких клиентов, рынков, процессов, систем, данных и регуляторных требований создаётся продукт.
• Эта связка особенно важна при использовании генеративного ИИ и ИИ-агентов в разработке продуктов: ИИ должен понимать не только задачу, но и намерение, ограничения и среду применения.
• Для бизнеса намерение, спецификации и контекст снижают риск рассогласования между стратегией и исполнением, помогают улучшить качество требований и делают работу команд более управляемой.

В конце статьи также есть глоссарий ключевых терминов: AI-Native SAFe, ART, намерение, спецификация, продуктовый контекст, policy specification (спецификации-политики), Definition of Done (определение завершённости/выполненности) и AI governance (ИИ надзор/управление).

Важное терминологическое уточнение

В этой статье мы используем термин «Намерение» применительно к AI-Native SAFe. Его не следует смешивать с термином «Интент решения базового SAFe». В Core SAFe интент решения состоит из спецификаций, дизайна и тестов и является подходом к управлению требованиями. В AI-Native SAFe управление требованиями строится иначе: через связку намерения, спецификаций и контекста.

Это различие связано с тем, что AI-Native SAFe ориентирован на работу с генеративным ИИ и ИИ-агентами, которым нужно ясное понимание результата, ограничений и среды применения. Поэтому далее в статье термин «Намерение» используется именно в контексте AI-Native SAFe. Если речь идёт о базовом SAFe, корректнее использовать термин «Интент решения базового SAFe».

На момент написания статьи AI-Native SAFe находится в раннем доступе, поэтому при релизе фреймворка терминология может быть уточнена.

Что такое намерение, спецификации и контекст в ИИ разработке продуктов

Намерение, спецификации и контекст обеспечивают исполнение и поставку ценности в AI-Native SAFe. Вместе они формируют систему продуктового знания, с которой могут работать и люди, и ИИ-агенты.

Рисунок 1. Намерение, спецификации и контекст обеспечивают AI-Native-исполнение и поставку

Каждый из этих элементов отвечает на отдельный вопрос о продукте, который создаёт ART:

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

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

Когда все три элемента заданы явно, ART получает общую основу для принятий решений – независимо от того, кто принимает следующее решение: человек или ИИ-агент.

Чем отличаются намерение, спецификации и контекст

Таблица 1. Отличия между намерением, спецификацией и контекстом в AI-Native SAFe.

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

Намерение в AI-Native SAFe: почему создаётся продукт

Намерение определяет базовую цель, стоящую за результатом, – «почему», которое описывает ключевой результат/outcome, а не только саму метрику. Оно смещает фокус с простого выполнения задач на создание ценности для клиента и бизнеса.

Видение продукта и клиентские и бизнес-результаты, или outcomes, ART описывают будущее состояние продукта и задают конечное «почему». Намерение делает это «почему» более конкретным с точки зрения ценности: каких клиентов обслуживать, какие проблемы решать, какие ставки делать и почему они оправданы. При этом намерение всё ещё остаётся на уровне «почему», не переходя к детальному описанию реализации.

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

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

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

Рисунок 2. Пример, как связать видение продукта, результаты ART и намерение

Намерение в части стратегии: где конкурировать и как победить

В AI-Native SAFe видение продукта и клиентские или бизнес-результаты ART являются основными формами представления продуктовой стратегии. По замыслу они задают пункт назначения, а не стратегию его достижения.

Стратегическая часть намерения добавляет следующий уровень детализации, формулируя, где конкурировать – то есть на каких рынках, сегментах и клиентских задачах сосредоточиться – и как побеждать – два выбора, лежащие в основе любой продуктовой стратегии. Оба относятся к «почему»: «где конкурировать» отвечает на вопрос, почему выбраны именно эти клиенты, а не другие; «как побеждать» объясняет, почему они выберут именно этот продукт.

В этой статье мы используем формулировку «намерение в части стратегии», а не «стратегическое намерение», чтобы не смешивать её с другими значениями термина strategic intent в управленческой и продуктовой практике. Здесь речь идёт именно о стратегическом аспекте намерения в AI-Native SAFe: выборе, где конкурировать и как побеждать.

Где конкурировать – это логика выбора рыночного поля для продукта: на каких клиентских сегментах, задачах и неудовлетворённых потребностях стоит сосредоточиться. Важны не самые крупные сегменты сами по себе, а те, где продукт имеет убедительные основания для победы. Осознанный отказ от части сегментов – такая же часть стратегии, как и выбор приоритетных направлений.

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

Выбор вариантов «где конкурировать» и «как побеждать» может фиксироваться в разных артефактах:

• стратегии сегментации;
• описании целевых клиентских групп;
• дереве продукта;
• фреймворке ценностного предложения;
• гипотезах позиционирования, упаковки и ценообразования.

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

Намерение в части исполнения: как реализовать выбранную стратегию

Последняя часть намерения описывает подход к исполнению и связывает стратегический выбор с конкретной работой ART. Она отвечает на вопросы:

• Почему этот результат продвинет нашу стратегию?
• Чему команда должна научиться и почему именно это знание важно?
• Какую гипотезу нужно проверить и почему именно эту?
• Какой риск требуется прояснить и почему это важно?

В AI-Native SAFe намерение в части исполнения может выражаться через разные артефакты:

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

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

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

Почему намерение должно оставаться ответственностью людей

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

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

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

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

Алексей Ионов, основатель «Ионов и Партнеры», Advanced SPC, эксперт по Lean-Agile трансформациям и SAFe в России и СНГ

Спецификации в AI-Native SAFe: что и как должно быть реализовано

Спецификации превращают намерение в детали решения, которые могут использовать для разработки люди и ИИ-агенты. На сегодняшний день становится очевидным, что разработка, управляемая спецификациями, или spec-driven development, является формирующимся отраслевым паттерном, на который опирается эта статья. Существуют текущие реализации этого подхода, такие как OpenSpec, GitHub Spec Kit и AWS Kiro. Авторы ожидают, что реализации и инструменты spec-driven будут развиваться, но базовый паттерн сохранится.

Разработка, управляемая спецификациями (spec-driven development) по сути является AI-Native эволюцией BDD — разработки, управляемой поведением (behavior-driven development). С появлением BDD появилась возможность описывать и проверять позже ожидаемое поведение функционала. Разработка, управляемая спецификациями, в свою очередь, делает спецификацию поведения артефактом, на основе которого ИИ может строить решение и контролировать соответствие этому поведению.

AI-Native SAFe определяет два типа спецификаций:

• функциональные спецификации – описывают предполагаемую реализацию;
• спецификации-политики – задают границы, в которых реализация должна оставаться.

Что такое функциональные спецификации

Функциональная спецификация описывает отдельную возможность продукта или задачу на новое обучение. Она отвечает на 2 вопроса:

1. Что должно делать хорошо реализованное решение?
2. Как команда поймёт, что оно действительно это делает?

Каждая функциональная спецификация обычно включает в себя:

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

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

Эфемерные и устойчивые спецификации

Срок жизни спецификации зависит от того, какую единицу работы она описывает.

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

Устойчивые спецификации используются для фич и энейблеров. Если продуктовая способность продолжает жить и развиваться, спецификация развивается вместе с ней. Для AI-Native разработки такая спецификация становится важным активом, который стоит сохранять и поддерживать в актуальном состоянии. Сгенерированный код может меняться, но спецификация сохраняет понимание того, что решение должно делать и почему.

Эфемерная спецификация при этом не является «одноразовой» в плохом смысле. Даже если эксперимент завершён, полученное знание обновляет намерение и контекст для последующих решений.

Что делает функциональную спецификацию хорошей

Хорошая функциональная спецификация обладает несколькими свойствами:

• Прослеживаемость к намерению – ясная связь с «почему», которое лежит в основе спецификации.
• Самодостаточность – ясно, что входит в область решения, что находится за её пределами.
• Соразмерность – спецификация достаточно детальна, чтобы направлять работу и генерацию, и достаточно компактна, чтобы человек мог её проверить.
• Проверяемость – по спецификации можно проверить, соответствует ли результат намерению и применимым политикам.

Спецификации-политики: каким правилам должно соответствовать решение

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

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

Спецификации-политики обычно охватывают три группы правил:

1. Качества системы
Производительность, безопасность, масштабируемость, надёжность и другие нефункциональные требования, описанные в Core SAFe. Они описывают не то, что система делает, а насколько хорошо она что-то делает.

2. Стандарты
Внешние и внутренние требования: стандарты шифрования, утверждённые протоколы, регуляторные обязательства, разрешённые компоненты и архитектурные правила.

3. Процессы
Правила выполнения и приёмки работы. Определение выполненности, или Definition of Done, модели согласования, контрольные точки с участием человека, требования к ревью и аудиту.

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

Что делает спецификацию-политику хорошей

Хорошая спецификация-политика должна быть:

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

Как контекст формирует спецификацию

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

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

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

Продуктовый контекст: где решение должно быть успешным

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

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

Пять аспектов продуктового контекста

Рисунок 3. Пять аспектов продуктового контекста

1. Клиентский контекст

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

Для AI-Native-продуктов особенно важно учитывать, как ИИ меняет ожидания клиентов. Пользователи всё чаще ждут от продукта персонализации, проактивной помощи, быстрых ответов и снижения ручной работы.

2. Рыночный контекст

Рыночный контекст описывает конкурентный ландшафт, в котором продаётся продукт: конкурентов, альтернативные решения, покупательскую аудиторию, динамику рынка, события и рыночные окна возможностей.

ИИ ускоряет изменения на рынке. Новые AI-Native игроки могут быстрее выходить к клиентам, тестировать гипотезы и занимать ниши. Поэтому организациям нужно понимать не только текущее положение, но и скорость изменений вокруг продукта.

3. Операционный контекст

Операционный контекст описывает инфраструктуру, среды развёртывания, процессы эксплуатации и поддержки, а также реальные условия, в которых работает продукт.

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

4. Контекст экосистемы

Экосистемный контекст описывает более широкую сеть, в которую встроен продукт: интеграции, интерфейсы, зависимые системы, партнерские продукты, платформы, ИИ-агенты и модели.

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

5. Регуляторный контекст

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

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

Регуляторный контекст особенно важен для банков, финансовых организаций, телеком-компаний, медицины, промышленности и других регулируемых отраслей.

Как поддерживать контекст в актуальном состоянии

Контекст постоянно меняется. Конкуренты выпускают новые продукты, регуляторы обновляют требования, клиенты меняются ожидания, платформы развиваются, а появляющиеся возможности ИИ постоянно создают новые сценарии взаимодействия с продуктом. Поэтому понимание контекста – это не разовая фаза анализа, а постоянная дисциплина.

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

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

Как связать намерение, спецификации и контекст на практике

Когда намерение, спецификации и контекст выстроены как единая система, людям не нужно каждый раз объяснять ИИ-агенту задачу с нуля. Агент может использовать окружающий стек знаний: клиентские и бизнес-результаты, намерение, спецификации, политики и релевантные контексты.

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

Рисунок 4. Совместный рабочий процесс человека и ИИ-агента

На практике это может выглядеть так:

1. Человек формулирует короткий запрос.
2. ИИ-агент собирает релевантное данные из намерения, спецификаций, политик и контекста.
3. Агент готовит черновик спецификации, тестов, анализа или решения.
4. Человек проверяет результат, оценивает логику и утверждает или корректирует его.
5. Полученная обратная связь обновляет намерение, спецификации или контекст.

Такая автономность безопасна только при условии, что стек базовых знаний остаётся целостным, актуальным и управляемым.

Практический шаблон для команды

Чтобы связать намерение, спецификации и контекст, команда может использовать простой шаблон:

1. Намерение: почему мы это делаем?
2. Ценность: для кого создаётся результат и какую проблему он решает?
3. Контекст: где и при каких условиях решение должно работать?
4. Ограничения: какие правила, зависимости и риски нужно учитывать?
5. Спецификации: что должно быть реализовано?
6. Критерии проверки: как мы поймем, что результат соответствует намерению?
7. Роль ИИ: в каких задачах ИИ может помогать, а где решение остается за людьми?

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

Почему важна прослеживаемость

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

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

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

Почему намерением, спецификациями и контекстом нужно управлять как курируемыми данными

Чтобы люди и ИИ-агенты могли обращаться к стеку, а сам стек сохранял целостность и не отставал по мере роста, содержащиеся в нём намерение, спецификации и контекст должны управляться как курируемые данные:

• доступны для поиска;
• структурированы;
• актуальны;
• проверены;
• связаны между собой;
• пригодны для повторного использования;
• защищены от неконтролируемых изменений.

Недостаточно просто единожды описать намерение, спецификации и контекст; они должны быть постоянно пригодны для нового практического применения и масштабного повторного использования.

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

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

Что это значит для бизнеса и продуктовых организаций

Для организаций России и СНГ конструкция связки «намерение – спецификации – контекст» особенно актуальна в трех ситуациях:

1. Компания внедряет генеративный ИИ в разработку;
2. Организация масштабирует продуктовые команды;
3. Бизнес хочет перейти от базового Lean-Agile/SAFe в управляемую AI-Native систему поставки ценности.

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

При этом, для разных отраслей основной акцент таких знаний будет разный:

• банки и финансовые организации – контроль рисков, безопасность данных, соответствие регуляторным требованиям, качество клиентских сервисов;
• телеком-компании – масштаб экосистемы, интеграции, надежность платформ, скорость вывода цифровых продуктов;
• промышленные предприятия – операционный контекст, надежность, безопасность, интеграция ИИ в производственные и инженерные процессы;
• ритейл и e-commerce – изменение клиентских ожиданий, персонализация, омниканальность, конкуренция с другими AI-Native-игроками;
• ИТ-компании и цифровые фабрики – переход от разрозненных ИИ-пилотов к системной модели AI governance, управления требованиями, спецификациями и качеством.

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

Алексей Ионов, основатель «Ионов и Партнеры», Advanced SPC, эксперт по Lean-Agile трансформациям и SAFe в России и СНГ

Преимущество ART: общая реальность для команд и ИИ-агентов

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

Когда намерение, спецификации и контекст связаны и регулярно обновляются, команды могут:

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

Чек-лист: готовы ли ваши намерение, спецификации и контекст к работе с ИИ-агентами

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

• Сформулировано ли намерение продукта, инициативы или функционала?
• Понятно ли, какой клиентский или бизнес-результат должна поддержать работа?
• Определено ли, какие решения принимает человек, а какие может предлагать ИИ-агент?
• Есть ли функциональная спецификация, описывающая ожидаемое поведение решения?
• Определены ли политики: безопасность, производительность, надежность, соответствие стандартам?
• Зафиксирован ли продуктовый контекст: клиент, рынок, операции, экосистема, регулирование?
• Понятно ли, какие данные и источники агент может использовать?
• Есть ли механизм проверки результата человеком?
• Есть ли способ обновлять намерение, спецификации и контекст по итогам поставки или обучения?
• Связаны ли артефакты между собой так, чтобы изменение стратегии отражалось на спецификациях и ограничениях?

Ключевые выводы

• Намерение определяет конкретную цель и идеи, стоящие за бизнес-результатами, смещая фокус к решению проблем с помощью ИИ, но под управлением человека.
• Спецификации переводят высокоуровневое намерение в живые, машиночитаемые детали решения и задают операционные границы.
• Контекст описывает клиентскую, рыночную, операционную, экосистемную и регуляторную среду, в которой продукт должен быть успешен.
• Связь намерения, спецификаций и контекста создаёт общий язык для команд разработки и ИИ-агентов.
• AI-Native SAFe требует не только ИИ-инструментов, но и зрелой системы управления продуктовыми знаниями, требованиями, правилами и ответственностью.

FAQ: частые вопросы о намерении, спецификациях и контексте в AI-Native SAFe

Что такое намерение в AI-Native SAFe?

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

Что такое спецификации в AI-Native SAFe?

Спецификации – это структурированные и проверяемые описания того, что должно быть создано, как должно работать решение и каким ограничениям оно должно соответствовать. В AI-Native SAFe спецификации должны быть пригодны не только для чтения людьми, но и для использования ИИ-агентами.

Чем intent отличается от specification?

Intent, или намерение, объясняет, зачем создаётся решение. Specification, или спецификация, описывает, какое поведение должно быть реализовано и как проверить результат. Намерение задает направление, а спецификация превращает его в рабочие критерии для разработки и проверки.

Что такое продуктовый контекст?

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

Чем спецификации отличаются от обычных требований?

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

Зачем ИИ-агентам нужно намерение?

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

Почему одного промпта недостаточно для работы с ИИ?

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

Как намерение, спецификации и контекст помогают снизить риск галлюцинаций ИИ?

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

Кто должен определять намерение – человек или ИИ?

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

Кому особенно полезен AI-Native подход «намерение – спецификации – контекст»?

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

Глоссарий: ключевые термины AI-Native SAFe и Core SAFe

Ниже собраны термины, которые используются в статье. Часть из них относится к AI-Native SAFe, часть – к базовому SAFe и смежным практикам управления требованиями, разработки и ИИ-надзора.

AI-Native SAFe – подход к применению SAFe в условиях, когда генеративный ИИ и ИИ-агенты становятся частью разработки, принятия решений и поставки продуктов.

Core SAFe / базовый SAFe – базовая версия фреймворка SAFe, ориентированная на масштабирование Agile-подходов, синхронизацию команд и регулярную поставку ценности.

ART, Agile Release Train – долгоживущая команда команд, которая регулярно поставляет ценность в рамках SAFe.

Намерение – формулировка «почему»: какую проблему клиента и какой бизнес-результат должна поддержать работа.

Интент решения базового SAFe – элемент управления требованиями в Core SAFe, который состоит из спецификаций, дизайна и тестов.

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

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

Функциональная спецификация – описание поведения, дизайна и тестов для отдельной способности, функции, эксперимента или прототипа.

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

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

BDD, Behavior-driven development – разработка, управляемая поведением, при которой ожидаемое поведение системы описывается в проверяемой форме.

Definition of Done – определение выполненности: общий критерий, по которому команда понимает, что работа действительно завершена.

AI governance, или надзор над ИИ – система управления применением ИИ: роли, правила, политики, контроль качества, рисков и ответственности.

Источник: Scaled Agile, Inc. (вендор), статья «AI-Native Intent, Specifications and Context» (от 30.07.2026). Материал не является официальным переводом.

Перевод и адаптация: Алексей Ионов, Advanced SPC, основатель компании «Ионов и Партнеры».

Дополнительно почитать по теме AI-Native SAFe:

⇒ AI-native SAFe: как искусственный интеллект меняет систему создания ценности в организациях 
⇒ Как управлять продуктовой разработкой через клиентские и бизнес-результаты в AI-Native SAFe
⇒ Инвестиционная стратегия портфеля в AI-Native SAFe: как связать результаты, бюджет и риски 
⇒ AI-Native ART: как Agile Release Train меняется в эпоху ИИ
⇒ Архитектор ИИ-ценности: роль AI-Value Architect в AI-Native SAFe и внедрении ИИ
⇒ Гибкость, усиленная ИИ: применение искусственного интеллекта в SAFe и Agile
⇒ Персонал, усиленный ИИ: руководство по внедрению в SAFe и Agile
⇒ Что такое искусственный интеллект (ИИ): основные типы ИИ и применение в бизнесе

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.