Какие этапы проходит задача в discovery?

Развернутый ответ об этапах задачи в Discovery

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

Этап 1: Инициация и фрейминг задачи

Задача начинается не с технического решения, а с бизнес-контекста. На этом этапе происходит:

• Выявление стейкхолдеров: Определение всех заинтересованных сторон (бизнес-заказчик, конечные пользователи, команда, поддержка).
• Формулировка проблемы: Четкий ответ на вопрос "Какую бизнес-проблему или боль пользователя мы решаем?". Использую технику Problem Statement.
• Определение целей и KPI: Что будет считаться успехом? Например, "увеличить конверсию на 15%" или "сократить время обработки заявки на 30%".

# Пример Problem Statement для задачи:
*   **Проблема:** Пользователи теряются в сложном интерфейсе личного кабинета, что приводит к 40% оттоку после первого месяца использования.
*   **Кто страдает:** Новые пользователи сервиса.
*   **Размер проблемы:** 2000 потенциальных клиентов ежемесячно.
*   **Успех:** Снижение оттока на 50% в течение квартала после внедрения улучшений.

Этап 2: Исследование и сбор информации (Research)

Это аналитическая фаза, где мы собираем данные для подтверждения или опровержения наших гипотез.

• Анализ рынка и конкурентов (Benchmarking): Понимаем, как подобные проблемы решают другие.
• Интервью с пользователями и стейкхолдерами: Проводим структурированные беседы, чтобы понять глубинные потребности, сценарии использования и "боли".
• Анализ метрик и данных: Изучаем аналитику (Google Analytics, Amplitude, внутренние отчеты) для выявления узких мест в текущих процессах.
• Аудит существующего решения (если есть): Технический и UX-аудит текущего продукта или процесса.

Этап 3: Анализ и синтез

На этом этапе "сырые" данные превращаются в инсайты и структурированные артефакты.

• Создание персонажей (User Personas): Архетипы целевых пользователей.
• Построение карты путешествия пользователя (User Journey Map): Визуализация всех точек взаимодействия пользователя с продуктом, выявление эмоций и проблемных зон.
• Приоритизация гипотез: Использую матрицу RICE (Reach, Impact, Confidence, Effort) или MoSCoW для ранжирования идей и возможных решений.

Этап 4: Проектирование решения и прототипирование

Переход от анализа к конкретным предложениям. Важно: на Discovery мы не делаем финальный дизайн, а создаем концепции для проверки.

• Facilitation workshops: Проведение воркшопов по генерации идей (например, дизайн-спринты).
• Создание пользовательских сценариев (User Stories) и Jobs to be Done: Описание функциональности с точки зрения ценности для пользователя.
• Разработка прототипов: От набросков на бумаге (скетчей) до интерактивных кликабельных прототипов в Figma. Цель — быстро и дешево проверить идею.
• Формирование high-level архитектуры: Создание диаграмм контекста и контейнеров (C4 model) для понимания масштаба и основных компонентов системы.

graph TD
    A[Проблема от бизнеса] --> B{Этап 1: Фрейминг};
    B --> C[Этап 2: Сбор данных];
    C --> D[Этап 3: Анализ & Синтез];
    D --> E{Этап 4: Проектирование};
    E -->|Вернуться к уточнению| B;
    E --> F[Выходные артефакты];

Этап 5: Валидация и планирование

Финальный этап Discovery, где мы доказываем жизнеспособность решения и готовимся к следующей фазе.

• Юзабилити-тестирование прототипов: Получение обратной связи от реальных пользователей на ранних концепциях.
• Оценка сроков и ресурсов (High-level estimation): Использую методику Planning Poker или оценку на основе аналогий для формирования предварительной дорожной карты.
• Оценка рисков и зависимостей: Выявление технических, бизнес- и организационных рисков.
• Формирование итогового пакета документов Discovery: Это может быть Pitch Deck для стейкхолдеров, Vision Doc, Product Requirements Document (PRD) или Решение о начале работ, содержащее:

    *   Обоснование проекта.
    *   Ограничения (scope, time, budget).
    *   Предлагаемое решение и архитектуру.
    *   Предварительный план, риски и критерии успеха.

Ключевые принципы, которые я соблюдаю в Discovery:

• Итеративность: Этапы часто выполняются не линейно, а циклически. Исследование может привести к пересмотру постановки проблемы.
• Фокус на проблеме, а не на решении: Мы должны сопротивляться желанию сразу предложить техническое решение, не разобравшись в корне проблемы.
• Вовлеченность команды: В Discovery участвуют не только аналитики и PM, но и ключевые разработчики, архитекторы, UX/UI-дизайнеры. Это обеспечивает общее видение и более точные оценки.
• Ориентация на данные: Решения должны основываться на данных (метрики, интервью), а не на мнениях или HiPPO (Highest Paid Person's Opinion).

Итог: Задача в Discovery проходит путь от расплывчатой бизнес-идеи до валидированной концепции решения с понятными границами, предварительной оценкой и общим видением для всех участников. Качественно проведенный Discovery на 60-70% снижает риски провала проекта на этапе разработки, экономит значительные ресурсы и гарантирует, что мы строим правильный продукт.