Что такое discovery?

Что такое Discovery Phase (Фаза исследования проекта)

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

Ключевые цели и задачи фазы Discovery

Основная цель — снижение неопределенности и ответы на фундаментальные вопросы:

• Зачем? (Бизнес-цели): Какую бизнес-проблему мы решаем? Какой метрикой (KPI) измерим успех (рост дохода, снижение затрат, увеличение конверсии)?
• Для кого? (Пользователи и стейкхолдеры): Кто конечные пользователи, их боли, потребности, сценарии поведения? Кто внутренние заказчики и как согласовать их ожидания?
• Что? (Масштаб и функциональность): Каковы ключевые возможности (features) продукта? Что входит в MVP (Minimum Viable Product), а что — в дальний горизонт?
• Как? (Технические и процессуальные аспекты): Каковы технические ограничения (legacy-системы, интеграции)? Какие методологии и инструменты будут использоваться? Какой примерный бюджет и timeline?
• Стоит ли? (Оценка жизнеспособности): Оправдает ли решение ожидаемые инвестиции (ROI)? Есть ли рыночная ниша или конкурентные преимущества?

Типичные активности и артефакты Discovery

Процесс дискавери носит итеративный и исследовательский характер. Вот основные активности:

• Сессии с заказчиком и стейкхолдерами (Stakeholder Interviews): Глубинные интервью для выявления бизнес-целей, страхов, ожиданий и метрик успеха.
• Пользовательские исследования (User Research):

    *   Интервью и опросы потенциальных пользователей.
    *   Анализ конкурентов (Competitor Analysis).
    *   Создание **персон пользователей (User Personas)** и **карт эмпатии (Empathy Maps)**.

• Анализ существующих систем и данных: Изучение текущей архитектуры, API, ограничений производительности.
• Воркшопы по проектированию решений: Коллективные сессии (например, Design Sprints, Event Storming) для генерации идей и их быстрой валидации.
• Прототипирование: Создание интерактивных прототипов (в Figma, Sketch) или даже "броскового кода" (clickable prototype) для проверки гипотез без дорогой разработки.

В результате формируется пакет артефактов, который становится источником истины (Single Source of Truth) для команды:

1. Vision & Scope Document (Документ видения и границ): Краткое, ясное описание продукта, его ценности и основных функций.
2. User Stories и Job Stories: Сформулированные потребности пользователя в формате "Как [роль], я хочу [цель], чтобы [выгода]".
3. Прототипы и пользовательские сценарии (User Journey Maps): Визуальное представление взаимодействия пользователя с продуктом.
4. Техническое заключение (Technical Feasibility Study): Оценка архитектурных рисков и вариантов реализации.
5. Предварительная дорожная карта (High-Level Roadmap) и оценка: Ориентировочные сроки, бюджет и план релизов (часто в формате кварталов).
6. Business Model Canvas или Lean Canvas: Для стартапов — компактная модель бизнес-гипотез.

Роль Project Manager в Discovery

PM выступает здесь как фасилитатор, координатор и аналитик рисков, а не просто администратор задач. Его ключевые обязанности:

• Планирование и фасилитация процесса: Организация воркшопов, интервью, синхронизация работы бизнес-аналитиков, дизайнеров и архитекторов.
• Управление ожиданиями стейкхолдеров: Постоянная коммуникация, перевод бизнес-языка на язык технических требований и обратно.
• Управление рисками: Ранняя идентификация бизнес-рисков (не те потребности), технических (невыполнимые интеграции) и организационных (нехватка экспертизы).
• Обеспечение перехода к реализации: Гарантия того, что выходные артефакты дискавери понятны, одобрены и достаточны для старта активной разработки (фазы Delivery).

Пример: Отличие Discovery от сбора требований

# Сбор требований (Requirements Gathering)
*   **Фокус:** "Что система должна ДЕЛАТЬ?"
*   **Подход:** Часто реактивный, каталогизация пожеланий.
*   **Результат:** Детализированный список функциональных требований (Software Requirements Specification).
*   **Риск:** Может привести к созданию точного, но бесполезного с точки зрения бизнеса продукта.

# Discovery (Исследование)
*   **Фокус:** "Какую ПРОБЛЕМУ пользователя и бизнеса мы решаем и КАКИМ способом?"
*   **Подход:** Проактивный, исследовательский, ориентированный на контекст и ценность.
*   **Результат:** Стратегические артефакты (видение, персоны, прототипы, MVP-скоп).
*   **Цель:** Гарантировать, что мы строим ПРАВИЛЬНУЮ вещь, прежде чем строить ее ПРАВИЛЬНО.

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