Интент Решения в SAFe: что это, из чего состоит и как использовать
Коротко
Интент/Намерение Решения (Solution Intent) – это единый репозиторий знаний о системе, где фиксируется:
- какое поведение требуется (целевое, предполагаемое);
- какое поведение реализовано (текущее);
- какие решения по архитектуре и дизайну обеспечивают это поведение.
Зачем это нужно: синхронизировать бизнес и ИТ по объёму и способу реализации, снизить стоимость изменений, ускорить согласования и упростить соответствие требованиям.
Пару слов о термине
«Я встречаю очень разные варианты перевода термина Solution Intent на русский язык, которые, в принципе, можно более-менее использовать, такие как «Намерение решения», «Замысел решения», «Концепция решения», «Цель решения» или даже «Умысел решения».
Но при этом, общаясь с профессионалами, занимающимися архитектурой и управлением требованиями для сложных и масштабных систем, в процессе такого общения ни один из этих терминов не приживался в обсуждении рабочих вопросов при запуске Lean-Agile. Связано это с тем, что то, о чём пойдёт речь ниже, – это одновременно модель, структура и система построения сквозного управления документацией в духе Lean-Agile, начиная от концепции и заканчивая кодом и тест-кейсами.
Иными словами, краткий и, наверное, наиболее правильный смысловой перевод термина «Solution Intent» в SAFe будет звучать как «Модель требований решения». Но такой вариант очень далёк от оригинального «Намерения» и, скорее, затруднит понимание других оригинальных материалов SAFe.
В связи с этим далее в статье мы будем использовать для обозначения термина «Solution Intent», кроме англоязычного оригинального варианта, либо простую транслитерацию в виде «Интент Решения» либо простой перевод «Намерение Решения», понимая под этим намного больше, чем просто чьё-то намерение что-то сделать.»
![Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры]()
Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры
Что такое Solution Intent: определение в SAFe
Интент Решения (Solution Intent) – это репозиторий, который помогает хранить, обновлять и передавать знания:
- о текущем и целевом (предполагаемом) поведении системы;
- об архитектуре и дизайне, которые это поведение обеспечивают.
При необходимости Интент Решения включает:
- фиксированные и вариативные спецификации и варианты дизайна,
- ссылки на применимые стандарты,
- модели системы,
- функциональные и нефункциональные требования (НФТ, NFR) и тесты,
- результаты проверок и доказательства регуляторного соответствия,
- механизмы прослеживаемости (трассируемости).
Зачем бизнесу и ИТ нужен Интент/Намерение Решения
В крупных продуктах (особенно с высокой ценой ошибки) важно удерживать в фокусе два взаимосвязанных вопроса:
- Что создаём: назначение, функции, ограничения, критерии приёмки.
- Как реализуем: архитектура, интерфейсы, дизайн и подход к проверке.
Если «как» оказывается слишком дорогим, рискованным и технически неосуществимым, приходится корректировать «что» – объём и формулировку потребности. В SAFe этот критически важный набор знаний оформляется как Интент Решения (Solution Intent): он поддерживает единое понимание предназначения решения, текущих и возникающих требований, архитектуры, проектных решений и целевого поведения системы.
Интент Решения обычно состоит из двух частей:
- Фиксированная – то, что уже определено и служит опорой для разработки и проверки.
- Вариативная (уточняемая) – то, что требует дальнейшего изучения, анализа и подтверждения по мере появления новых данных.
Управление этими частями и способность сохранять варианты (в том числе на поздних стадиях) повышают гибкость разработки решений большого масштаба.
Agile, документация и соответствие регуляторным требованиям (compliance)
В системах с высокой ценой ошибки необходимость строго определять и валидировать поведение системы может усложнить внедрения Lean-Agile подходов. Несмотря на важность ценности Agile Манифеста о том, что «работающее программное обеспечение важнее исчерпывающей документации», на практике организациям обычно нужны и результат, и документация. Это нередко приводит к конфликту приоритетов между задачами на разработку против задач на документирование.
Сложные решения нередко порождают большие объёмы технической информации, включая:
- требования и дизайн: Фичи (Features), Капабилити/Возможности (Capabilities), Истории (Stories), Нефункциональные требования (НФТ/NFR), архитектура, доменные модели, варианты дизайна, интерфейсы, спецификации заказчика;
- тесты и доказательства: результаты тестов и подтверждение соответствия;
- ключевые решения: результаты исследований и экспериментов, обоснования выбора вариантов.
Во многих случаях эти материалы входят в официальный набор артефактов – по операционной необходимости или по требованиям регуляторов/контрактов.
Solution Intent как репозиторий знаний: что он даёт на практике
Интент/Намерение Решения – основной репозиторий знаний о том, «что создаётся» и, при необходимости, «как это будет построено».
Он помогает:
- поддерживать единый «источник истины» о целевом и фактическом поведении решения;
- фиксировать и распространять требования, архитектурные и дизайн-решения;
- поддерживать анализ, исследования и принятие решений;
- со-направить клиента, Agile команды и поставщиков вокруг общей цели;
- обеспечивать соответствие регуляторным требованиям и выполнение договорных обязательств.
Текущее и будущее состояние Интента Решения: спецификации, дизайн, тесты
Интент/Намерение Решения отражает две ключевые реальности разработки:
Текущее и будущее состояния
Важно понимать, что «система делает сейчас» и «что планируется изменить» для будущего состояния.
Три опорных элемента: Спецификации, дизайн и тесты
Знания о текущем и будущем состоянии могут фиксироваться в любой форме, но должны отражать три элемента:
- спецификации – документированное определение ожидаемого поведения системы,
- дизайн – как это поведение обеспечивается,
- тесты – как поведение подтверждается.
Рисунок 1. Анатомия Solution Intent
Для систем, которые должны работать строго по заданному поведению (например, системы, критичные для жизни или регулируемые нормативными требованиями), трассируемость связывает элементы Интента Решения между собой, а также с компонентами реализации и проверками. Интент Решения создаётся совместно и уточняется по мере получения новых знаний.
Форматы и носители: документы, модели, MBSE
Элементы Интента Решения можно оформлять в разных форматах: в виде документов и таблиц, результатов сессий совместной проработки (whiteboard sessions), формализованных требований, а также моделей и инструментов моделирования – включая Инжиниринг систем на основе моделей (Model-Based Systems Engineering, MBSE), где модели выступают основным носителем части требований и решений дизайна.
При этом Интент Решения – средство создания Решения, а не самоцель: способ фиксации не должен создавать избыточные накладные расходы и потери.
Solution Intent как «живой» артефакт: почему он постоянно обновляется
Традиционный подход опирается на детализированные требования, зафиксированные заранее. Однако Принцип SAFe №3 «Принимать вариативность; сохранять опциональность» (Assume variability; preserve options) показывает, что чрезмерная фиксация требований и дизайна на ранних этапах снижает вероятность достижения оптимального результата. Нужен подход, который удерживает фокус на известном и позволяет уточнять неизвестное по мере разработки.
Интент Решения – не разовое утверждение. Он поддерживает весь цикл разработки и регулярно обновляется: задаёт видение будущей системы, со-направляет команды и их беклоги, даёт достаточную детализацию для текущего планирования и сохраняет пространство для исследования неизвестного. Новые знания дают обратную связь о целевом (to-be) состоянии системы и создают возможность адаптации.
Рисунок 2 демонстрирует разницу между традиционной декомпозицией фиксированных требований на ранних этапах и Lean-Agile подходом, где требования уточняются через Фичи, Истории и, при необходимости, через прямую коммуникацию участников.
Рисунок 2. Сравнение традиционного и Agile подходов к требованиям
Фиксированная и вариативная части Solution Intent: как сохранять варианты
Интент Решения не требует заранее полностью определять финальное «точечное решение». Преждевременная детализация ограничивает поиск экономически лучших альтернатив и увеличивает стоимость последующих изменений, которые неизбежно произойдут. Чтобы этого избежать, SAFe выделяет две части Интента Решения:
1. Фиксированное Намерение (Fixed)
Описывает «известное» – требования и решения, которые не предполагают пересмотра или уже закрепились в ходе разработки.
Например:
- требования к конкретным характеристикам (например, профиль сигнала кардиостимулятора);
- стандарты соответствия регуляторным требованиям (например, PCI DSS при обработке платёжных данных);
- ключевые способности Решения (например, максимальная грузоподъёмность автономного автомобиля доставки)
2. Вариативное Намерение (Variable)
Включает элементы, позволяющие исследовать экономические компромиссы требований и альтернативы дизайна. По мере появления подтверждённых знаний эти элементы постепенно переводятся в фиксированную часть.
Переход от «вариативного» к «фиксированному» требует накопления знаний, достаточных для принятия решений. В SAFe для этого используются Энейблеры (Enablers) – механизм исследования неизвестного и фиксации полученных результатов в Интенте Решения. В сочетании с Множественным Дизайном (Set-Based Design) команды рассматривают альтернативы и выбирают оптимальный вариант по экономическим критериям. Выбранный вариант затем позволяет развивать последующие Фичи в дорожной карте (рисунок 3).
Рисунок 3. Переход от вариативных элементов к фиксированным элементам Интента Решения со временем.
В каждом Интервале Планирования (PI) команды одновременно реализуют то, что уже известно, и исследуют то, что пока неизвестно.
Совместная разработка Solution Intent: роли и взаимодействия
Создание и развитие Интента/Намерения Решения – командная работа.
Менеджмент Продукта и Решения вместе с Архитекторами Систем и Решения отвечают за решения верхнего уровня: декомпозицию системы, интерфейсы и распределение требований по подсистемам и Капабилити. Они также задают структуру Интента Решения, чтобы поддержать будущие потребности в анализе и обеспечении соответствия регуляторным требованиям. В то же время Интент Решения помогает принимать решения локально, на уровне команд, как показано на рисунке 4.
Рисунок 4. Solution Intent развивается через сотрудничество
Интент Решения определяет дорожную карту Решения и, в конечном итоге, формирует состав работ в беклогах. Разработка Интента начинается с создания первоначального Видения, описывающего основное назначение решения и критически важные Капабилити (Возможности/способности), а также с нефункциональных требований системы. Эти знания, развивающаяся дорожная карта и ключевые вехи помогают командам выстраивать беклоги и планировать работу.
При этом и дорожная карта, и Интент Решения содержат предположения и должны корректироваться по мере получения знаний в ходе реализации (рисунок 5). Такой формат сотрудничества заменяет традиционный подход с централизованными детализированными спецификациями и планами, призванными заранее снизить неопределённость.
Рисунок 5. Разработка Интента Решения
Рекомендации SAFe по непрерывной доставке позволяют проверять ключевые предположения через MVP и получать подтверждённые знания на основе частых и измеримых экспериментов. Результаты такого обучения фиксируются в Интенте Решения. Как правило, эти знания носят технический характер, однако применимы и бизнес-ориентированные принципы Бережливого Стартапа (Lean Startup) Эрика Риса.
Интенты Решений в цепочке доставок: связь подсистем и поставщиков
В крупных решениях Интент Решения не существует изолированно. Поскольку система состоит из нескольких подсистем, Интент часто охватывает их, включая информацию, необходимую поставщикам. У поставщиков обычно есть собственные требования, дизайн и спецификации по их подсистемах или Капабилити (Возможности) – по сути, их собственный Интент Решения.
Верхнеуровневый Интент Решения должен объединять релевантную информацию по всей иерархии подсистем, чтобы коммуницировать решения, поддерживать исследования, со-направлять команды и обеспечивать соответствие регуляторным требованиям (рисунок 6).
Рисунок 6. Иерархия требований и дизайна в Интенте Решения.
Минимально достаточная документация: как избежать избыточной документации
Интент/Намерение Решения помогает направлять разработку и со-направлять участников, облегчает коммуникацию и подтверждает выполнение регуляторных требований и договорных обязательств. Планируя содержание, структуру и подход к документированию, важно исходить из принципа минимальной достаточности и эту минимальную достаточность выносить в Интент Решения. При этом «больше» не означает «лучше»: Lean-Agile подход рекомендует сохранять документацию «легковесной».
Практики, которые помогают:
- Предпочитать модели документам. В условиях постоянных изменений документоцентричный подход менее устойчив. Модели (включая артефакты, создаваемые современными практиками Дизайн Мышления и клиентоцентричного дизайна) часто проще сопровождать и обновлять.
- Вести Интент Решения совместно. Интент/Намерение Решения не является исключительной зоной ответственности Менеджеров Продукта и Решения и Архитекторов: многие участники команд создают, уточняют и улучшают его содержание.
- Сохранять варианты. Декомпозируйте решения до локальных контекстов и принимайте решения как можно позже, пока это экономически оправдано. Использование подхода «Множественный дизайн» (Set-Based Design) помогает не фиксировать дизайн и требования преждевременно.
- Избегать параллельных копий и фиксировать каждое решение в одном месте. Требования и решения должны иметь один официальный источник – единый репозиторий, «книгу правды» для всех участников, в которой осуществляется работа над всеми артефактами. Это снижает расхождения и ускоряет согласование.
- Держать достаточный уровень абстракции. Коммуницируйте на максимально высоком уровне абстракции и избегайте излишней детализации. Поддерживайте Множественный дизайн (Set-Based Design), задавая диапазоны допустимых значений вместо фиксированных чисел. Описывайте поведение решения через намерения и гипотезы ценности, а не через излишнюю конкретику. Децентрализуйте полномочия по принятию решений по требованиям и дизайну ближе к месту выполнения работы.
- Сохранять простоту. Фиксируйте только то, что действительно необходимо для разработки, подтверждения соответствия регуляторным требованиям и выполнения контрактных обязательств.
Частые вопросы о Solution Intent в SAFe
Solution Intent – это документ или набор документов?
В SAFe это репозиторий знаний. Он может включать документы, таблицы, модели, ссылки на стандарты, тесты и результаты проверок – важнее не формат, а управляемость и актуальность.
Чем Solution Intent отличается от требований в беклоге (Фичи/Истории)?
Беклог – это план работ и единицы доставки ценности. Интент Решения – сводное знание о поведении решения (as‑is/to‑be), дизайне и проверках, которое помогает согласовывать «что» и «как» и обеспечивать соответствие.
Что обязательно должно быть в Solution Intent?
Минимально – описание текущего и целевого (будущего) поведения, ключевые (но не все!) архитектурные решения и способ подтверждения поведения (тесты/проверки). В регулируемых средах часто требуется также прослеживаемость (трассируемость) между всеми этими элементами, когда можно определить взаимосвязи между элементами беклогов, дизайном, кодом, документацией, поведением и подтверждением этого поведения.
Кто владелец Solution Intent?
Интент Решения развивается совместно. Обычно структуру и верхнеуровневые решения задают Менеджеры Продукта/Решения и Архитекторы всех масштабов, но содержание пополняют команды, инженеры, тестирование, безопасность и другие роли.
Как поддерживать актуальность Solution Intent при частых изменениях?
Считать его «живым», динамичным артефактом: обновлять по мере появления подтверждённых знаний, переносить элементы из вариативной части в фиксированную, фиксировать результаты Энейблеров и экспериментов.
Когда нужна прослеживаемость/трассируемость?
Когда требуются доказательства подтверждения соответствия поведения исходным требованиям (например, соответствие критически важным для жизни человека показателям или когда есть формальное регуляторное требование, которому необходимо соответствовать), а также когда это прямо предусмотрено контрактом или внутренними стандартами качества.
Оригинал: Scaled Agile, Inc. (вендор), статья «Solution Intent». Материал не является официальным переводом.
Перевод и адаптация: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры.
Основано на версии статьи от 09.10.2023.
Обучение
Обсуждение Интента Решения является частью тренинга SAFe® для Архитекторов. Если Вас интересует эта и/или другие темы по управлению Agile архитектурой, приходите на тренинг SAFe® for Architects.
Программа курса включает такие темы, как:
- Что такое Lean-Agile архитектура?
- Создание архитектуры для DevOps и Выпуска по требованию
- Выравнивание архитектуры с бизнес-ценностью
- Разработка Видения Решения, Намерения Решения и Дорожной Карты Решения
- Подготовка архитектуры к PI Планированию (PI Planning)
- Координация архитектурных вопросов во время PI Планирования
- Поддержка Непрерывной Доставки в рамках выполнения Интервала Планирования (PI)
- Поддержка новых Стратегических Тем и цепочек создания ценности
- Лидерство Архитектора в Lean-Agile трансформации
Дополнительная информация о тренинге: https://ionovpartners.ru/trainings/safe-for-architects/
Почитать дополнительно:
Видение Продукта: стратегический компас бизнеса
Дорожные карты (горизонты планирования)
© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».
SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.