Дискаверифаза

Discovery фаза - разбивается на этапы (артефакты), на каждом из из которых задаются правильные вопросы, предлагаются варианты их решения и определяется нужная конкретно на этом проекте реализация, с учетом всех нюансов. После каждого этапа предоставляется отдельный артефакт с зафиксированными требованиями. В зависимости от особенностей проекта, некоторые из необязательных артефактов могут быть пропущены.

Как итог Discovery фазы - становится понятен объем работ, стек технологий, методология ведения проекта, необходимая команда, способы и сроки его реализации.

Для успешного выполнения Discovery фазы нужны следующие специалисты:
1. Стейкхолдер (со стороны Заказчика)
2. Аналитик
3. UI/UX Дизайнер
4. Менеджер
5. Senior developer

Все они у нас в штате.

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

Подробнее об артефактах дискавери-фазы в нашей компании:
1. Mind Map: Визуализация требований в диаграмме связей помогает понять масштаб проекта, количество ролей и модулей, а также определить границы будущего проекта. С ней проще разглядеть сразу незаметные задачи, построить взаимосвязи, отследить противоречия и дублирующиеся требования.
2. Диаграмма BPMN: Формализация требований в таком виде помогает четко понять взаимодействие пользователей друг с другом и увидеть возможные «белые пятна», которые в другом артефакте мы могли попросту не заметить. На этом этапе явно указывается, как именно система работает: откуда в ней появляются данные, отправные точки для действий и процессов, как именно пользователь приходит к цели и не слишком ли длинным получается путь.
3. User Story/Functional Requirements (история пользователя/функциональные требования): Краткое описание функции или функциональности с точки зрения конечного пользователя, подробно описывающее, что должно быть на проекте реализовано.
4. Non-Functional Requirements (нефункциональные требования): Определяют атрибуты качества, которыми должна обладать программная система, такие как производительность, безопасность, масштабируемость и удобство использования.
5. Request-Response Model (модель "запрос-ответ"): Модель связи клиент-сервер, это документ, конкретизирующий требования к интеграции со сторонними системами и сервисами: что именно разрабатываемая нами система должна запросить у сервиса (какие поля) и что мы получим от него в ответ.
6. Исследование узких мест: Поиск узких мест и возможных решений. Узкие места можно рассматривать в спектре от чисто бизнес-ориентированных до чисто технических. В особых случаях — симбиоз того и другого. Например, платежные системы.
7. Wireframes: Представление с низкой точностью макета, дизайна и функциональных возможностей пользовательского интерфейса, используемое для понимания того, как будет осуществляться навигация по проекту целиком.
8. Design Concept (Концепция дизайна): Проектирование и отрисовка нескольких ключевых элементов дизайна, отражающих основополагающую идею проекта, ключевые компоненты дизайна и наследуемую впоследствии стилистику.
9. Clickable Prototype: Интерактивное моделирование конечного продукта с высокой точностью, используемое для тестирования и проверки пользовательского опыта.
10. Презентация: Визуальное представление целей, хода и результатов проекта, используемое для донесения информации о проекте до заинтересованных сторон. Можем включить в пул работ, чтобы помочь заказчику презентовать идею стейкхолдерам.
11. План проекта: План, описывающий цели, задачи, ресурсы и сроки проекта, используемый для управления и отслеживания прогресса. Создается, чтобы дать понимание требуемых разработческих ресурсов и транслировать сроки выполнения задач заказчику.
12. Грубая оценка для разработки: Предварительная оценка времени и стоимости, необходимых для разработки программной системы, используемая для планирования и распределения ресурсов.

Каждый из артефактов детализируется в необходимой мере для того, чтобы выполнить поставленные перед Discovery фазой задачи. Например, в рамках User Story/Functional Requirements может быть написано подробное ТЗ, а в рамках Design Concept может быть выполнен весь дизайн целиком.