Какие артефакты должны появиться в резульатате Discovery фазы?

Артефакты Discovery фазы: фундамент для успешного проекта

Discovery (или фаза предпроектного анализа) — это критически важный этап, цель которого — не написать код, а досконально понять проблему, контекст, ограничения и ожидания заказчика. Результатом этой фазы должен стать не просто отчет, а комплект взаимосвязанных артефактов, которые становятся единым источником истины (Single Source of Truth) для всех участников проекта на последующих этапах. Их наличие значительно снижает риски, исключает разночтения и закладывает основу для точного планирования.

В результате качественно проведенного Discovery должны появиться следующие ключевые артефакты:

1. Документация по бизнес-требованиям и видению

Эти артефакты фокусируются на «зачем» (Why) и «что» (What), а не на «как» (How).

• Vision & Scope Document (Видение и границы проекта): Краткий, но емкий документ, описывающий стратегическое видение продукта, его цели, ключевые преимущества и высокоуровневые границы. Отвечает на вопросы: Какую проблему мы решаем? Для кого? Какой будет успех?
• Business Requirements Document (BRD) / Пользовательские истории (User Stories) и карта пути пользователя (User Journey Map): Детальное описание функциональных и нефункциональных потребностей с точки зрения бизнеса и конечных пользователей. User Journey Map визуализирует взаимодействие пользователя с продуктом, выявляя точки боли и возможности.

  # Пример структуры Epic/User Story в Confluence/Jira
  ### Epic: Онлайн-оплата заказа
  **Цель:** Уменьшить процент отказа от корзины на 20%.
  *   **Story US-101:** Как покупатель, я хочу выбрать способ оплаты (карта, электронный кошелек), чтобы оплатить заказ удобным для меня способом.
    *   Критерии приемки (AC):
      1. На странице оплаты отображаются минимум 3 способа.
      2. Выбор способа ведет на соответствующий шлюз.
      3. При успешной оплате пользователь видит подтверждение.
  

• Бизнес-PoC (Proof of Concept), если требуется: Не функциональный, а концептуальный прототип для проверки жизнеспособности ключевой гипотезы или интеграции.

2. Документация по решениям и архитектуре

Эти артефакты начинают раскрывать «как» (How) в высокоуровневой форме.

• Solution Approach Document (Описание подхода к решению): Описывает выбранный высокоуровневый путь реализации (например, использование микросервисной архитектуры, покупка SaaS-платформы с доработкой, кастомизация opensource-решения). Обосновывает выбор с точки зрения затрат, рисков и времени.
• High-Level System Architecture Diagram: Блок-схема ключевых компонентов системы, их взаимосвязей и интеграций с внешними сервисами. Важно указать технологии (например, бэкенд на Java, фронтенд на React, БД — PostgreSQL).

  graph TD
      A[Web Client] --> B[API Gateway];
      B --> C[Auth Service];
      B --> D[Order Service];
      D --> E[(PostgreSQL)];
      D --> F[Payment Gateway];
      F --> G[External Bank API];
  

• Список интеграций (Integration Map): Детализированная таблица всех внешних и внутренних систем, с которыми необходимо интегрироваться, включая протоколы (REST, SOAP, gRPC), ответственность сторон и статус договоренностей.

3. Оценочная и плановая документация

Трансляция понимания в измеримые метрики и сроки.

• Оценка проекта (Estimation): Не просто одна цифра, а оценка с варьированием (range estimation), например, «1200-1600 человеко-часов», основанная на техниках Planning Poker или Function Point Analysis. Часто представляется в виде High-Level Roadmap.
• High-Level Roadmap (Дорожная карта): Визуальный план по кварталам или месяцам, показывающий последовательность реализации крупных блоков (Epics), привязанный к бизнес-целям. Например:

  title High-Level Roadmap 2024
  dateFormat YYYY-MM
  section Phase 1
  Ядро системы : 2024-01, 3M
  section Phase 2
  Интеграции : 2024-04,而造成 2M
  section Phase 3
  Мобильное приложение : 2024-07, 4M
  

• Предварительный план управления рисками (Risk Register): Таблица с идентифицированными на этапе Discovery рисками (техническими, бизнес-скими, организационными), их вероятностью, impact и стратегиями реагирования (mitigation).

4. Организационная и процессная документация

• Матрица ответственности RACI: Четкое определение ролей (Responsible, Accountable, Consulted, Informed) для ключевых процессов и артефактов проекта между командой, заказчиком и стейкхолдерами.
• Предложение по методологии и процессам (Ways of Working): Рекомендация по гибкой методологии (Scrum, Kanban), длине спринта, инструментам (Jira, Confluence), регламентам совещаний и процессу приемки работ. Особенно важно для новых или распределенных команд.

5. Итоговый сводный документ

• Feasibility Study Report или Discovery Phase Summary: Итоговый документ, который суммирует все выводы Discovery и содержит ключевые рекомендации: «Стоит ли запускать проект?», «С каким бюджетом и в какие сроки?», «Какие ключевые риски?». Этот документ является основанием для принятия решения о переходе к фазе активной разработки (Implementation) или об остановке проекта, что также является успешным результатом Discovery, так как позволяет избежать бесполезных трат.

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