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

Что такое discovery-фаза

Discovery (в русскоязычной практике — дискавери или предпроектное исследование) — начальный этап работы над продуктом, на котором команда изучает проблему, пользователей и условия, в которых будет существовать решение. Код на этом этапе не пишут. Цель — собрать достаточно сведений, чтобы обоснованно решить, что разрабатывать, в каком объеме и нужно ли разрабатывать вообще.

Подход широко используется в продуктовом дизайне и при создании цифровых государственных сервисов. В британском руководстве GOV.UK Service Manual discovery открывает жизненный цикл сервиса, за ним следуют фазы alpha, beta и live. Руководство прямо предупреждает: на этапе discovery строить сам сервис не нужно.

Чем discovery отличается от Proof of Concept

Оба инструмента применяют до основной разработки, но они отвечают на разные вопросы. Proof of Concept проверяет, осуществимо ли конкретное техническое решение. Discovery начинается раньше и охватывает больше: выясняет, какую проблему стоит решать, для кого и в каких рамках. По итогам исследования может оказаться, что одну из идей нужно проверить через PoC, — тогда он становится одним из следующих шагов.

Какие вопросы закрывает исследование

Содержание discovery зависит от продукта, но круг вопросов обычно похож:

  • кто пользователи, в какой ситуации у них возникает потребность и как они справляются с ней сейчас;
  • какую бизнес-задачу должен решать продукт и по каким показателям будет видно, что он ее решает;
  • какие есть ограничения — законодательные, договорные, бюджетные, связанные с уже работающими системами;
  • с какими внешними сервисами и данными придется интегрироваться;
  • что уже пробовали внутри компании и почему это не сработало;
  • какие допущения о продукте самые рискованные и как их проверить.

Последний пункт часто оказывается самым ценным. Список рискованных допущений показывает, что нужно проверить в первую очередь, а что можно спокойно отложить.

Как проходит discovery-фаза

В центре этапа — исследование, а не подготовка документов. Типичная последовательность работ выглядит так:

  1. Стартовая встреча с заказчиком: цели, известные вводные, участники со стороны бизнеса, сроки.
  2. Интервью со стейкхолдерами — руководителями, будущими пользователями внутри компании, техническими специалистами. Они рассказывают о процессах, ограничениях и прошлых попытках решить задачу.
  3. Исследование пользователей: интервью, наблюдение за работой, опросы, разбор имеющейся аналитики и обращений в поддержку.
  4. Анализ рынка и конкурентов — как похожую задачу решают другие и какие ожидания уже сложились у аудитории.
  5. Технический аудит: существующие системы, данные, API, требования к безопасности и инфраструктуре.
  6. Синтез: команда сводит находки, формулирует проблему, строит карту пользовательского пути и список гипотез с приоритетами.
  7. Итоговая презентация и решение о следующем шаге.

Строгого порядка здесь нет. Интервью нередко меняют исходную постановку задачи, и команда возвращается к вопросам, которые казались закрытыми.

Кто участвует

Discovery проводит небольшая команда из специалистов разного профиля. Nielsen Norman Group рекомендует состав из 3–7 человек: исследователь или дизайнер, фасилитатор (продакт- или проектный менеджер), представитель заказчика, который знает предметную область и принимает решения, и технический специалист. Без разработчика легко спроектировать то, что невозможно сделать в разумные сроки, а без представителя бизнеса — то, что никому не нужно.

Сколько длится

Единого срока нет: он зависит от сложности задачи и от того, насколько доступны пользователи для интервью. Ориентир в GOV.UK Service Manual — обычно от 4 до 8 недель. Небольшому продукту с понятной аудиторией может хватить меньшего срока, системе с множеством интеграций и ролей потребуется больше. Растягивать этап без необходимости не стоит: его задача — снять ключевую неопределенность, а не ответить заранее на все вопросы.

Что заказчик получает на выходе

Итог discovery — набор материалов, на которые можно опираться при планировании:

  • сформулированная проблема и данные исследования, которые ее подтверждают;
  • описание пользователей и их сценариев, карты пользовательского пути;
  • границы первой версии продукта: что в нее входит, а что откладывается;
  • предварительная архитектура и перечень интеграций;
  • список рисков и гипотез, которые предстоит проверить;
  • оценка сроков, бюджета и состава команды для следующего этапа;
  • при необходимости — кликабельные прототипы ключевых экранов.

Эти материалы полезны не только для следующего этапа. С ними проще защитить бюджет внутри компании, обсуждать проект с инвесторами или сравнивать предложения разных подрядчиков.

Почему отказ от проекта — тоже результат

Discovery заканчивается решением: продолжать, изменить подход или отказаться от идеи. В GOV.UK отдельно оговаривают, что остановить работу после discovery — не провал, если исследование показало, что так правильнее. Несколько недель исследования обходятся несравнимо дешевле, чем несколько месяцев разработки продукта, который не решает реальной задачи.

Чаще итог промежуточный: идея сохраняется, но меняется ее масштаб. Например, вместо платформы для всех отделов компании команда предлагает начать с одного процесса, где проблема стоит острее всего, а эффект легче измерить.

Когда без discovery можно обойтись

Отдельное исследование нужно не каждому проекту. Если задача типовая, требования подтверждены, а продукт похож на то, что команда уже делала, discovery может оказаться избыточным. Пример — доработка существующей функции по уже собранной обратной связи.

Этап особенно оправдан, когда:

  • продукт создается с нуля, а об аудитории и ее потребностях известно только по предположениям;
  • у заказчика есть идея, но нет общего видения среди руководства;
  • проект затрагивает несколько подразделений, процессов или внешних систем;
  • бюджет разработки значителен, и ошибка в направлении обойдется дорого;
  • нужна точная оценка сроков и стоимости, а исходных данных для нее не хватает.

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