Discovery-этап — это короткое исследование перед основной разработкой, которое помогает понять проблему, пользователей, ограничения и проверяемый результат. На нём не строят полноценный production-продукт: сначала собирают доказательства для решения, что и как имеет смысл делать дальше. Хороший discovery может закончиться решением не разрабатывать продукт или изменить его границы.
Его ценность не в красивом отчёте, а в снижении неопределённости до того, как команда зафиксирует большой бюджет и начнёт писать код.
Какую неопределённость снимает discovery
В начале проекта часто есть готовое решение: «сделаем портал», «добавим личный кабинет», «автоматизируем заявки». Discovery возвращает разговор к задаче: кто испытывает проблему, в каком контексте, какие ограничения существуют и какой результат будет достаточным.
| Область | Что выяснить | Артефакт |
|---|---|---|
| Пользователи | Роли, цели, контекст, барьеры и доступность | Карта ролей и сценариев |
| Процесс | Шаги, исключения, ручные операции и владельцы | Карта текущего процесса |
| Данные | Источники, качество, права, статусы и хранение | Схема потоков данных |
| Технологии | Системы, API, legacy, инфраструктура и ограничения | Карта интеграций и рисков |
| Результат | Как поймём, что решение работает | Метрики и критерии успеха |
Что команда делает на discovery
- уточняет цель и границы проблемы;
- проводит интервью или анализирует реальные обращения и документы;
- описывает путь пользователя и точки потерь;
- проверяет существующие системы, данные и интеграции;
- формулирует гипотезы и ранжирует риски;
- готовит варианты решения и план следующей фазы;
- фиксирует критерии успеха и условия остановки.
Методы зависят от проекта. Для внутреннего сервиса важны интервью с сотрудниками, роли и права, а также реальные исключения процесса. Для клиентского продукта — сценарии пользователей, поддержка, аналитика и ограничения интеграций. Для AI-функции добавляются качество данных, границы автоматизации, проверка ответов и ручной контроль.
Нужна рабочая оценка? Опишите задачу в Telegram или через контактную форму: команда Paladin Engineering поможет разложить её на сценарии, ограничения и понятный следующий шаг.
Почему discovery — это не «нарисовать несколько экранов»
Прототип может быть частью следующей фазы, но сам по себе не заменяет исследование. GOV.UK Service Manual разделяет discovery и alpha: discovery изучает проблему и ограничения, а alpha проверяет варианты решения прототипами и тестирует самые рискованные предположения. Это полезная модель и для коммерческих проектов.
Если команда начинает с экранов, она рискует быстро согласовать интерфейс для процесса, который никто не проверил. Макет полезен, когда отвечает на вопрос: «сможет ли конкретный пользователь выполнить этот сценарий?»
Как определить, что исследование завершено
У discovery должен быть критерий завершения. Не «мы поговорили со всеми», а решение и его основания: идти в прототипирование, менять задачу, отложить её или остановиться.
- проблема сформулирована через потребность пользователя, а не название технологии;
- понятны основные роли, сценарии и исключения;
- зафиксированы данные, интеграции и ограничения;
- выделены самые рискованные гипотезы;
- есть варианты решения и аргументы выбора;
- определены метрики, критерии приёмки и следующий этап.
Какие решения можно принять после discovery
| Вывод | Следующий шаг |
|---|---|
| Проблема подтверждена, риски понятны | Прототип или MVP с ограниченным контуром |
| Проблема есть, но решение неясно | Проверить несколько гипотез в alpha/прототипе |
| Готовый продукт закрывает задачу | Настройка, интеграция и план внедрения |
| Данные или ограничения блокируют ценность | Сначала исправить процесс, данные или доступы |
| Эффект не оправдывает вложения | Остановить проект и сохранить выводы |
Как не превратить discovery в дорогую формальность
Зафиксируйте вопросы до старта и связывайте каждый артефакт с решением. Если карта процесса не меняет приоритеты, её нужно упростить. Если интервью не проверяют гипотезу, изменить сценарий разговора. Если технический аудит не показывает риск, который влияет на план, не превращать его в инвентаризацию ради инвентаризации.
Полезен короткий ритм: вопрос → evidence → вывод → решение. Так заказчик видит, за что платит, а команда не маскирует отсутствие ответа количеством страниц.
Связь discovery с оценкой и контрактом
После discovery оценка становится точнее не потому, что неопределённость исчезла, а потому, что её видно. В смете можно отдельно показать подтверждённые работы, допущения, внешние зависимости, риски и то, что пока остаётся гипотезой.
В договорённостях полезно закрепить результат этапа: какие вопросы исследуются, какие материалы передаются, кто принимает решения и при каких условиях команда переходит к MVP. Это снижает риск, что discovery незаметно превратится в бесконечную подготовку.
Безопасность, доступы и данные
Даже раннее исследование должно учитывать, какие данные используются и кто имеет к ним доступ. Для будущего продукта заранее обсуждают минимальные права, аудит действий, хранение, резервное копирование и безопасную передачу данных подрядчику. NIST SSDF полезен как общий словарь для вопросов о безопасной разработке, хотя он не заменяет отраслевые требования и юридическую экспертизу.
Практический чеклист заказчика
- какую проблему исследуем и для кого;
- какие факты уже есть, а что пока предположение;
- какие ограничения могут остановить проект;
- какие три гипотезы самые рискованные;
- какой результат должен быть к концу discovery;
- какие решения принимает заказчик по итогам;
- что входит в следующий этап, а что исключено.
Paladin Engineering проводит предпроектную аналитику и помогает переводить бизнес-задачу в понятный контур MVP, архитектуру и план разработки. Если проект уже начат, команда может подключиться к разбору сценариев, интеграций и рисков. Оставьте заявку через контакты или изучите направление веб-разработки.
Частые вопросы
Сколько длится discovery?
Фиксированного срока нет: он зависит от числа ролей, систем и неопределённости. Важно заранее определить вопросы и критерий завершения.
Нужно ли писать код на discovery?
Обычно нет production-кода. Для рискованных сценариев следующий этап может использовать прототип, который проверяет идею, а не готов к эксплуатации.
Можно ли пропустить discovery?
Если задача типовая и хорошо изучена, отдельный этап может быть коротким или встроенным в старт проекта. Пропускать нужно не исследование, а лишнюю бюрократию.
Кто должен участвовать со стороны бизнеса?
Владелец процесса, представители ключевых ролей, человек, принимающий решения, и специалисты по данным или интеграциям, если они критичны.
Как понять, что подрядчик сделал работу?
Попросите связать выводы с исходными вопросами, показать риски, варианты, ограничения, критерии успеха и план следующего шага.
Discovery гарантирует точную смету?
Нет. Он делает допущения и неизвестные явными, поэтому оценка становится управляемее, но изменения и внешние зависимости всё равно возможны.
Комментарии