Дискавери фаза (Discovery Phase) — процедура сбора информации, выполняемая с целью понимание отрасли, для которой разрабатывается продукт, бизнеса Вашего заказчика и целевой аудитории. Важно получить глубокое понимание ожиданий заказчика, лиц, принимающих решения с его стороны, а также конечных пользователей в отношении продукта.
Основной целью предварительного анализа является предоставление технического предложения заказчику. Для этого необходимо максимально выяснить потребности клиента и создать отдельный документ с требованиями к продукту.
Все детали, которые будут получены в ходе Discovery-фазы, помогут определить объем работ, временные рамки и план выполнения задач по проекту, а также будут способствовать тому, что заказчик получит качественный программный продукт, разработанный под его нужды.
Готовый вариант чек-листа по подготовке к Discovery Phase:
1. Подготовка - Agenda
Видение (Vision)
- А почему пришла идея сделать такую систему?
- Почему нельзя использовать готовые подобные системы?
- Какие проблемы решит именно новая система?
Заинтересованные стороны (Stakeholders)
- Кто ваш конечный пользователь?
- Будет ли эта система взаимосвязана с другими системами?
- Кто будет разрабатывать систему?
- Кто будет ее тестировать?
Бизнес-цели (Business Goals)
- Зачем заказчик хочет разработать систему?
- Заработать деньги?
- Использовать по надобности?
Рынок (Market)
- В какой стране будет работать система?
- Какое там законодательство и стандарты?
- Какие обычаи?
- Там есть проблемы, которые решает наш продукт?
Конкуренты (Competitors)
- Существуют ли аналогичные системы?
- Чем они лучше новой?
- Чем новая система будет отличаться?
- Какие стратегии используют конкуренты?
- Какие проблемы у конкурентов?
Домен (Domain)
- Какие сейчас тренды в вашем домене?
- Какие компании считаются передовыми?
- Какие технологии используются?
- Каковы прогнозы по развитию отрасли?
Потребности пользователя (User Needs)
- Кто будет использовать систему? А это точно?
- Вы уже общались с конечными пользователями?
- Почему они должны использовать именно эту систему?
- Какие проблемы она решает?
2. Проведение
Возможности (Opportunities)
- Есть ли инсайты или возможности для развития системы?
- Как можно их провалидировать?
Ограничения (Limitations)
- Каковы ограничения, влияющие на развитие системы и проекта?
- Это технические ограничения, бизнес-ограничения (сроки, бюджет, мероприятия), ограничения рынка?
Варианты реализации (Solution Options)
- А если не разрабатывать все с нуля, а кастомизировать что-то готовое?
- А может бизнес-проблему можно решить иначе, без системы вообще?
- Делать только web или mobile?
Фичи (Features)
- Как будет работать система?
- Какие функции будет выполнять?
- С чем система будет интегрироваться?
Границы решения (Solution Boundaries)
- Будет ли система состоять из определенных функциональных модулей и интегрироваться с конкретной сторонней платежной системой?
Риски (Risks)
- Какие существуют риски?
- А что, если система не взлетит?
- Кто отвечает за риски?
- Какой есть резерв для рисков?
- Учтены ли все риски?
- Есть ли план по управлению рисками?
3. Результаты
Минимально жизнеспособный продукт (MVP)
- Какие модули нужны, чтобы система могла выйти на рынок?
- Без чего нельзя вообще?
Дорожная карта (Roadmap)
- Определяются майлстоуны и значимые мероприятия, определяются модули, которые должны быть готовы к определенному майлстоуну.
- Рассчитывается приблизительная длительность проекта.
Документация (Documents)
- Архитектурное видение (Architecture Vision)
- Концепция системы (Business Vision)
- Концепция дизайна (Design Vision)
План (Plan)
- План проекта (Project Plan)
- Бизнес-план (BA Plan)
- Архитектурный план (Architecture Plan)
Источник не известен, в любом случае авторы молодцы - хорошая шпаргалка получилась.