Привет, Хабр!

Внутренние продукты умирают чаще, чем живут. Причём гибнут не на проде, не из‑за кривого кода и не от того, что разработка пошла не по плану. Они разваливаются на самом старте — когда гипотеза ещё не успела обрести форму, но уже обросла Jira‑задачами. Где‑то я видел, что 9 из 10 новых инициатив не переживают первую встречу с пользователем. Почему? Потому что команды бегут в реализацию, не удостоверившись: а надо ли это вообще кому‑нибудь?

Классический двухнедельный Scrum здесь не спасёт. Он хорош, когда вы уже уверены в направлении. А вот когда на старте всё зыбко и туманно, нужен отдельный, чётко спланированный discovery‑конвейер. Такой, в котором каждые три недели появляется не слайд, а артефакт — проверенный, валидированный, готовый к следующему шагу. И вот хорошо вписывается 5D Discovery.

Коротко о 5D Discovery

Концепт построен на известных пятиступенчатых дизайн‑процессах, но адаптирован под инженерный ритм: ровно пять трёхнедельных итераций, суммарно 15 недель.

План на 15 недель

Dream (недели 1–3)

Сначала все идеи фиксируются на виртуальной доске: каждая гипотеза формулируется в виде проблемы и ожидаемого эффекта. Интервью с внутренними заказчиками проводятся по 30 минут; обязательный вопрос — «Как будет понятно, что проект не удался?». Так мы вынуждаем формулировать конкретные критерии провала и отсеивать абстрактные хотелки.

Далее в течение двух‑трёх часов наблюдают, как сотрудники решают задачу вручную: без опросников, только реальные действия. Наблюдение показывает обходные пути, частоту ошибок и реальные задержки в процессе.

Все наблюдения переносятся в Canvas. На одной странице фиксируются участники процесса, текущие боли, существующие обходные решения, ценность для компании и основные риски.

Distill (недели 4–6)

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

Каждая гипотеза пропускается через фильтр «ценность, измеряемость, техническая выполнимость». Если хотя бы один пункт не проходит проверку, идея переносится в отложенный backlog. Жёсткий отсев экономит время на последующих этапах и фокусирует команду на действительно важных функциях.

Результаты фиксируются в компактном Lean PRD объёмом до двух страниц. Раздел Out of scope обязателен, чтобы зафиксировать, какие задачи в MVP точно не войдут. По итогам формируется приоритизированный backlog в Jira и набор метрик North Star для дальнейшего отслеживания.

Draft (недели 7–9)

Далее создаётся вертикальный сквозной спайк: минимальный рабочий сценарий проходит через все уровни — UI, API, базу данных и кэш — сразу на prod‑подобном окружении.

Параллельно включается security‑контроль: статический и динамический анализ запускается на каждую ветку, даже если код временный. Раннее обнаружение уязвимостей дешевле, чем исправление перед запуском.

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

Demo (недели 10–12)

Для проверки гипотезы организуются живые юзабилити‑тесты с минимум пятью представителями целевой аудитории; сессии записываются.

Затем проводится получасовой обзор со стейкхолдерами: что увидено, как интерпретируется, какие вопросы остаются. Формат избавляет от длинных презентаций и концентрируется на конкретной обратной связи.

Если метрики удовлетворённости ниже порога, гипотезы возвращаются на этап Distill для доработки. При положительных результатах согласовывается финальный список изменений и уточняются требования к пилоту.

Deploy (недели 13–15)

Функция выводится в прод под feature flag, открытый лишь 5% внутренней аудитории. Такой щадящий запуск позволяет собратьметрики, не рискуя стабильностью всей системы.

Телеметрия настраивается по принципу observability by default: бизнес‑события сразу поступают и в Grafana, и в Amplitude, чтобы технические и продуктовые показатели были доступны из одного места.

Через 48 часов проверяются p95-латентность (цель — < 250 мс), отсутствие P1-инцидентов и достижение минимально запланированного эффекта (не менее 30% улучшения ключевой KPI). При выполнении условий пилот признаётся успешным и готовым к масштабированию.

Гейт-критерии и как их защитить

Команда минимального размера

• Tech Lead — владелец методологии, держит технический риск на коротком поводке.

• Product Owner — отвечает за метрику North Star и приоритизацию.

• UX Designer — ведёт исследования, прототипы, тесты.

• Dev Squad — 3–4 инженера T‑shape: фронт, бэк, инфраструктура.

• QA Engineer — автоматизирует критические пути с начала Draft.

• Stakeholder Proxy — представитель бизнеса, доступен не менее 4 часов в неделю.

Инструменты и шаблоны

Все шаблоны (Problem Statement, Lean PRD, Runbook) можно держать в Confluence (или любом подобном окружение).

Итоги

Метод 5D Discovery фиксирует три ключевые проблемы внутренних инициатив:

1. Скорость принятия решений — каждую третью неделю есть формальный чек‑пойнт.

2. Прозрачность метрик — от Problem Statement до Telemetry Dashboard проходит строго 15 недель.

3. Контроль риска — архитектурный спайк и security‑сканы встроены в Draft, а не после кода.

Внедрить метод можно за один квартал: начинаем с пилотной команды, прописываем шаблоны, отслеживаем метрики переходов. Через полгода большинство команд перестают задавать вопрос «зачем ещё один процесс» — он просто помогает им быстрее доводить идеи до продакшена.

Метод 5D Discovery помогает структурировать работу с внутренними инициативами и доводить их до пилота за 15 недель. Если вы хотите, чтобы команда не только применяла этот подход, но и глубже прокачала навыки анализа, проектирования и тестирования решений, обратите внимание на корпоративные программы OTUS.

А чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram‑канал OTUS4Business.