Короткий ответ: discovery-этап — это короткая исследовательская работа до основной разработки. На нём команда проверяет проблему, пользователей, ограничения, данные, интеграции и границу первой версии. Его задача не «подготовить красивую презентацию», а уменьшить неопределённость настолько, чтобы решение можно было честно спроектировать и оценить.
Самая дорогая ошибка — начать с интерфейса
Представьте типичную ситуацию: у компании есть идея сервиса, несколько списков функций и просьба «сразу показать первый экран». Команда быстро рисует интерфейс, затем выясняется, что у разных ролей разные правила, исходные данные неполные, а главный сценарий зависит от внешней системы. Работа сделана, но решение задачи ещё не доказано.
В discovery этот конфликт поднимают до разработки. Не чтобы затянуть старт, а чтобы отделить проверяемые предположения от требований. Если гипотеза не выдерживает разговора с пользователями или проверки данных, дешевле изменить её до реализации.
Из каких частей состоит discovery
Состав зависит от риска, но обычно включает пять направлений.
- цель и проблема: какой процесс должен измениться и для кого
- пользовательские сценарии: роли, контекст, частота и исключения
- данные и интеграции: источники, API, права, качество и ограничения
- прототип: как выглядит основной путь и где нужны решения
- границы MVP: что проверяем первой версией, а что сознательно откладываем
Важен не список встреч, а итоговые решения. После discovery должны остаться карта сценария, перечень допущений, технические риски, прототип ключевого пути и критерии готовности первой версии.
Какие вопросы нельзя оставлять «на потом»
Некоторые вопросы легко отложить, потому что они не видны на макете: кто владеет данными, что происходит при повторной отправке, где хранится история, кто подтверждает изменение, что делать при недоступности API. Но именно такие вопросы превращаются в переделку после начала разработки.
| Зона | Вопрос | Артефакт |
|---|---|---|
| Пользователь | кто и в каком контексте действует? | сценарий и роли |
| Ценность | какое решение должно стать проще? | гипотеза и критерий |
| Данные | откуда берётся информация и кто её меняет? | модель данных |
| Интеграции | что произойдёт при ошибке или повторе? | контракт и fallback |
| Граница | что не входит в первую версию? | backlog вне MVP |
Прототип — не финальный дизайн
Прототип нужен для проверки пути: где человек начинает, какое решение принимает, какие данные вводит и как понимает результат. На этом этапе допустимы простые экраны и бумажные схемы. Смысл в том, чтобы быстро сравнить варианты и получить обратную связь, а не полировать цвета.
Atlassian описывает product discovery как работу с потребностями, идеями, приоритизацией и связью с последующей поставкой. Для заказчика практический вывод простой: discovery должен соединять разговор о проблеме с решением, которое можно передать в delivery, а не жить отдельным документом.
Как принять решение после discovery
Не каждый discovery обязан заканчиваться разработкой. Возможны четыре честных результата: запуск MVP, дополнительная проверка гипотезы, выбор готового решения с настройкой или отказ от идеи. Отказ — тоже результат, если он предотвращает реализацию продукта без подтверждённой ценности.
- запускать, если проблема и первый сценарий подтверждены
- уточнять, если ценность понятна, но не хватает данных
- настраивать готовое решение, если процесс типовой
- останавливать, если ключевая гипотеза не подтверждается
Что должно попасть в техническую оценку
После discovery оценка становится прозрачнее: известны роли, основные сущности, интеграции, критерии готовности и исключения. Но это всё ещё оценка с допущениями, а не обещание точной даты. Хорошая карточка показывает, что входит в MVP, какие зависимости остаются у заказчика и как изменение объёма влияет на план.
Безопасность и доступность тоже нельзя оставлять на релиз. OWASP ASVS предлагает проверяемые требования к техническим контролям веб-приложения, NIST SSDF — практики безопасной разработки в жизненном цикле, а WCAG 2.2 — тестируемые критерии доступности интерфейса. На discovery достаточно определить применимые риски и точки проверки.
Как выглядит полезный итог
Полезный итог discovery — не длинный отчёт, а набор решений, которым может пользоваться команда: схема процесса, прототип, список интеграций, карта рисков, граница MVP, критерии готовности и следующий шаг. Если документ нельзя превратить в задачи и проверки, исследование не закончено.
Paladin Engineering может провести discovery, аудит идеи или подготовить прототип перед разработкой. Это особенно уместно, когда у проекта несколько участников, неясные интеграции или спорная граница первой версии. Для старта достаточно описать проблему, текущий процесс и ограничения в сообщении команде. Отправьте заявку с текущим процессом и ограничениями.
Часто задаваемые вопросы
Обязателен ли discovery для маленького проекта?
Не всегда. Но даже короткая проверка полезна, если есть интеграции, несколько ролей или риск дорого изменить решение позже.
Чем discovery отличается от ТЗ?
Discovery сначала проверяет проблему и варианты решения, а ТЗ фиксирует выбранное решение на уровне требований.
Можно ли провести discovery без пользователей?
Можно собрать гипотезы, но нельзя выдавать их за подтверждённые. Нужно явно отметить, что именно предстоит проверить.
Как понять, что discovery завершён?
Команда может назвать первый сценарий, границы MVP, риски, критерии готовности и список вопросов, которые остаются открытыми.
Кто принимает решение о запуске?
Владелец продукта или бизнеса. Команда разработки помогает сделать последствия вариантов понятными, но не подменяет бизнес-решение.
Как Paladin Engineering подключается
Мы можем начать с разбора задачи, пользовательских сценариев и технических ограничений, затем собрать прототип и план первой версии. Такой формат помогает сравнить разработку, настройку готового решения и отказ от лишней функциональности до основного бюджета. Если идея уже сформулирована, отправьте заявку через контакты или Telegram.
Практический вывод: discovery нужен не для увеличения объёма документов, а для принятия решений до кода. Если после него остаются только проверяемые вопросы, понятная граница первой версии и критерии готовности, разработка начинается с меньшим количеством неизвестных. Если же главный сценарий и ценность всё ещё спорны, правильным следующим шагом будет дополнительная проверка, а не расширение backlog.
Комментарии