---
title: "Dual-Track Agile: Discovery и Delivery в одном продуктовом цикле"
description: "Как продуктовая команда параллельно проверяет, что стоит создавать, и выпускает надёжное решение: роли, риски, практики и границы Dual-Track Agile."
---

Dual-Track Agile описывает два взаимосвязанных вида работы продуктовой команды. **Discovery** помогает понять, какую проблему стоит решать и каким способом; **Delivery** превращает выбранное решение в работающий, поддерживаемый продукт. Команда ведёт оба потока параллельно и продолжает учиться после выпуска.

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

## Discovery: снижать неопределённость

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

В модели Марти Кагана обычно различают четыре риска:

- **Ценность:** решает ли предложение значимую проблему и выберет ли его пользователь?
- **Удобство:** сможет ли человек разобраться и выполнить нужное действие?
- **Реализуемость:** может ли команда создать и поддерживать решение с доступными технологиями и ресурсами?
- **Жизнеспособность для бизнеса:** совместимо ли решение с экономикой, операциями и ограничениями продукта?

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

## Delivery: выпускать с нужным качеством

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

Discovery и Delivery не образуют очередь фаз. Пока команда выпускает один инкремент, она может исследовать следующие возможности. Реальные данные и обращения после релиза становятся частью следующего цикла обучения. Проверенная гипотеза даёт основание начать реализацию, но объём и способ выпуска ещё нужно согласовать с техническими ограничениями и критериями готовности.

## Одна команда и общая ответственность

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

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

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

## Как организовать цикл

1. Сформулируйте продуктовый результат и опишите проблему, которую наблюдаете.
2. Запишите несколько предположений, включая то, которое сильнее всего угрожает ценности или реализуемости решения.
3. Выберите небольшую проверку с понятным сигналом и ограничьте время, бюджет и возможный ущерб.
4. По результату решите: развивать вариант, изменить его или отказаться. Зафиксируйте вывод и оставшиеся вопросы.
5. Для выбранного решения уточните сценарий и критерии готовности, затем поставьте реализацию в общий поток Delivery.
6. Выпустите изменение с подходящими проверками и наблюдением; используйте поведение пользователей и работу системы для следующего цикла Discovery.

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

Показатели должны отвечать на разные вопросы. В Discovery смотрят на скорость получения полезных свидетельств, ясность проблемы и то, насколько решения меняются после проверки. В Delivery — на время прохождения работы, стабильность релизов и качество. Количество интервью, убитых идей, строк кода или задач само по себе не доказывает ценность.

## Нюансы и границы

- **Не делайте из треков mini-waterfall.** Последовательность «аналитик написал требования — дизайнер передал макет — разработчик собрал» задерживает совместное обнаружение проблем.
- **Не считайте всё исследование подготовкой требований.** Discovery может показать, что функцию следует изменить или вовсе не делать; это полезный результат.
- **Не отправляйте в Delivery автоматом всё, что проверяли.** Проверка нужна для решения о дальнейшей работе, а не для производства обязательств по выпуску.
- **Не сводите успех к скорости.** Быстрая разработка невостребованной функции и большое число интервью без принятых решений не улучшают продукт.
- **Не путайте короткие итерации с экспериментами.** Чтобы учиться, нужны явное предположение, наблюдение и готовность поменять следующий шаг.
- **Учитывайте обязательную работу.** Безопасность, доступность, законодательные ограничения и техническое обслуживание могут требовать реализации даже без пользовательского эксперимента.
- **Размер команды не отменяет принципов.** Если отдельная продуктовая триада недоступна, определите, кто приносит продуктовый, пользовательский и технический контекст, и подключайте пользователей подходящим способом.

## От Dual-Track к непрерывному развитию продукта

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

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

В этой перспективе Discovery и Delivery взаимно питают друг друга: исследование подсказывает, что пробовать; разработка делает решение доступным; работающий продукт и реакция пользователей уточняют следующее исследование. Спринты, Kanban и разные модели планирования могут поддерживать такой цикл. Например, [GIST](https://wpcraft.ru/kb/processes/gist-framework.md) связывает цели, идеи, этапы проверки и задачи. [Модель Кеневина](https://wpcraft.ru/kb/processes/cynefin.md) помогает выбрать подход к ситуации по характеру неопределённости, а [итерационный и транзакционный подходы](https://wpcraft.ru/kb/processes/dev-ops-vs-iterations.md) рассматривают экономику организации потока работы.

Предположение, что ИИ-агенты изменят состав команды или сместят акцент с триады на непрерывный цикл, — возможное направление развития, а не установленное следствие Dual-Track Agile. Команде всё равно нужны свидетельства о потребностях пользователей, ответственность за технический результат и решения о выпуске.

## Связанные страницы

- [KPI и метрики ИТ-процессов](https://wpcraft.ru/kb/processes/kpi.md) — общая карта показателей.
- [Метрики Discovery](https://wpcraft.ru/kb/processes/kpi/discovery.md) — скорость обучения и качество решений.
- [Метрики Delivery и DORA](https://wpcraft.ru/kb/processes/kpi/delivery.md) — скорость и надёжность поставки.
- [Agile-манифест разработки](https://wpcraft.ru/kb/processes/agile-manifesto.md) — ценности совместной работы и обратной связи.
- [Фреймворк GIST](https://wpcraft.ru/kb/processes/gist-framework.md) — постановка целей и поэтапная проверка идей.
- [Матрица Impact–Effort](https://wpcraft.ru/kb/processes/impact-effort-matrix.md) — быстрый первичный отбор идей по ожидаемому эффекту и затратам; оценки нужно проверять свидетельствами.
- [Модель Кеневина](https://wpcraft.ru/kb/processes/cynefin.md) — выбор действий по контексту и характеру неопределённости.
- [Типы команд веб-разработки](https://wpcraft.ru/kb/processes/dev-team-types.md) — варианты состава команды и устойчивость распределения знаний.
- [Итерационный и транзакционный подходы](https://wpcraft.ru/kb/processes/dev-ops-vs-iterations.md) — выбор формата сотрудничества с учётом координационных затрат.

## Материалы и источники

- [Dual-Track Agile — Marty Cagan, SVPG](https://www.svpg.com/dual-track-agile/)
- [The Four Big Risks — Marty Cagan, SVPG](https://www.svpg.com/the-four-big-risks/)
- [Dual Track Development is not Duel Track — Jeff Patton](https://jpattonassociates.com/dual-track-development/)
- [Process vs. Model — Marty Cagan, SVPG](https://www.svpg.com/process-vs-model/)
- [Getting Started with Discovery — Teresa Torres, Product Talk](https://www.producttalk.org/getting-started-with-discovery/)
- [Исходный конспект](https://wpcraft.ru/raw/2026/1005/dta.md) — синтезированный материал с библиографией и заметками об истории модели.