Discovery: что должно быть понятно до старта разработки
Discovery нужен не ради объёмного документа. Его задача — убрать дорогостоящую неопределённость до того, как команда начнёт писать код.
- Рубрика
- Цифровые продукты
- Опубликовано
- Время чтения
- 6 минут
01Сведите разные ожидания к одной картине
Заказчик, пользователи и инженеры по-разному описывают будущий продукт. На discovery эти представления превращаются в общую модель: цели, роли, ключевые сценарии и границы первого релиза.
Прототип помогает обсуждать не абстрактные пожелания, а конкретный путь пользователя. Архитектурная схема одновременно показывает, какие системы и данные потребуются для его реализации.
02Определите, что не входит в первый релиз
Список исключений не менее важен, чем перечень функций. Он защищает команду от постоянного расширения объёма и позволяет сосредоточиться на проверке главной продуктовой гипотезы.
- Один измеримый результат первого релиза
- Приоритетные сценарии и допустимые компромиссы
- Зависимости от внешних систем и других команд
03Завершите этап рабочим планом
Результат discovery — прототип, архитектурный контур, приоритизированный backlog и план итераций. После этого оценка сроков опирается на согласованные решения, а не на предположения.
Главные выводы
Как согласовать бизнес-цель, пользовательские сценарии и технические ограничения, не затягивая подготовку проекта.
- Сведите разные ожидания к одной картине
- Определите, что не входит в первый релиз
- Завершите этап рабочим планом