Проекты заходили на discovery или на delivery

Отличный и очень важный вопрос. Как руководитель проектов с большим опытом, могу сказать, что не существует универсального ответа. Формально проект «заходит» на delivery (реализацию), но качественный discovery (исследование) часто является критически важным этапом перед этим самым входом в delivery. По сути, это две стороны одной медали, и правильный подход зависит от зрелости процессов, типа проекта и определенности требований.

1. Discovery как отдельная фаза или часть проекта?

На практике я вижу три основных подхода:

Подход А: Discovery — это отдельный мини-проект или спринт «нулевой фазы».

• Когда используется: Для сложных, инновационных или плохо определенных продуктов, где риски непонимания рынка, технологий или пользовательских сценариев极高.
• Цель: Не написать код, а снизить неопределенность, проверить гипотезы, прототипировать UX, выбрать технологический стек, оценить реализуемость и построить детализированный backlog с приоритизацией.
• Вход в Delivery: Проект официально стартует на этапе delivery только после завершения discovery, когда есть утвержденное видение, дорожная карта, прототип, техническое решение и более-менее точная оценка.

Подход Б: Discovery и Delivery идут параллельно в рамках одного проекта.

• Когда используется: В Agile-среде, особенно при развитии существующего продукта. Discovery (исследование новых фич, юзер-стори маппинг) ведется Product Owner'ом и UX-специалистами на 1-2 спринта впереди команды разработки, которая в это время занята delivery текущего спринта.
• Цель: Обеспечить непрерывный поток ценности без остановки разработки.
• Вход в Delivery: Проект изначально стартует как delivery-проект, но включает непрерывную discovery-активность на постоянной основе.

Подход В: Проект сразу заходит на Delivery, а discovery делается «на коленке» или игнорируется.

• Когда используется: К сожалению, часто в условиях pressure со стороны бизнеса, при работе с фиксированными контрактами или в незрелых организациях.
• Риски: Колоссальные. Это прямой путь к scope creep (разрастанию объема), переделкам, срыву сроков и бюджетов, и, в итоге, к неудовлетворенности заказчика.

2. Почему формальный вход на Discovery — это признак зрелости?

С точки зрения бизнес-процессов, выделение discovery в отдельную фазу или проект позволяет:

• Легализовать и оплатить работу по исследованию. Дизайнеры, аналитики и архитекторы не работают «втемную».
• Принять взвешенное Go/No-Go решение. После discovery становится ясно: стоит ли вообще запускать дорогостоящую разработку? Может, идея нежизнеспособна?
• Сформировать реалистичную baseline: бюджет, сроки, scope. Это основа для управления ожиданиями стейкхолдеров.

3. Мой опыт и рекомендации: как я определяю подход?

В своей работе я применяю простой алгоритм, основанный на уровне неопределенности (технической и продуктовой):

graph TD
    A[Получена инициатива] --> B{Высокая неопределенность?<br/>Новый продукт/рынок/технология?};
    B -- Да --> C[Отстаиваю отдельный Discovery-проект<br/>с целями: прототип, ТЗ, оценка];
    C --> D{Результаты Discovery успешны?};
    D -- Да --> E[Запускаем Delivery-проект<br/>с четким scope и планом];
    D -- Нет --> F[Проект закрывается<br/>или переформулируется];
    B -- Нет --> G[Запускаем Delivery-проект<br/>с встроенной фазой Discovery<br/>в первые 2-3 спринта];
    G --> H[Непрерывная discovery-активность<br/>силами PO/UX на опережение];

Конкретные примеры из практики:

• Разработка мобильного банка с нуля: Отдельный 2-месячный discovery-проект с созданием clickable-прототипа, техническим анализом API провайдеров и оценкой. Только после его защиты мы стартовали delivery с четким MVP.
• Добавление новой платежной системы в существующий e-commerce: Проект сразу стартовал как delivery, но первые 2 спринта включали интенсивную discovery-работу (анализ документации провайдера, spike-задачи по интеграции, уточнение требований к логированию).

Заключение

Идеальный сценарий, к которому я стремлюсь: проект официально начинается с Discovery-фазы, результаты которой являются gate для перехода к Delivery. Это дисциплинирует всех участников, экономит значительные средства и повышает шансы на успех. Однако в Agile-реальности зачастую эти процессы сливаются. Ключевая задача PM — не допустить начала delivery (написания продакшн-кода) в условиях полной неопределенности. Если требования расплывчаты, а технические риски не исследованы, мой ответ: «Сначала discovery, потом delivery». В противном случае проект обречен на болезненные итерации переделок и конфликты.