Discovery

Содержательно этап состоит из четырёх блоков. Бизнес-контекст: какую задачу решает продукт, как компания зарабатывает сейчас, какие метрики должны сдвинуться. Пользователи: кто ими будет, какие у них сценарии и где сегодня боль — интервью с реальными людьми, а не с представлениями команды о них. Ограничения: интеграции с существующими системами, требования к данным, бюджетная рамка, сроки, регуляторные требования. Решение: структура продукта, прототипы ключевых экранов, архитектурная схема и список рисков.

Экономический смысл прямой. Discovery обычно занимает 5–10% бюджета проекта, и это самая дешёвая точка, где можно изменить решение. После него объём становится оцениваемым: вилка сужается с «от 500 тысяч до двух миллионов» до диапазона в пределах 20–30%, потому что известны экраны, интеграции и объём данных. Регулярный побочный результат — сокращение объёма: часть функций, которые казались обязательными, после интервью с пользователями переезжает во вторую очередь или исчезает.

Важный организационный момент: discovery оплачивается отдельно и результат принадлежит заказчику. Это защищает от привязки — с готовым ТЗ, прототипом и оценкой можно идти в тендер и сравнивать подрядчиков по одному документу, а не по красоте презентаций. Подрядчик, который отказывается отдавать материалы этапа или делает их бесплатно «в счёт будущего проекта», по факту продаёт вам зависимость. Обратная сторона тоже честная: бесплатная предпроектная аналитика почти всегда означает оценку по аналогии и последующие «мы не учли».

Когда discovery не нужен, тоже стоит сказать. Типовой лендинг, небольшой сайт по понятной структуре, доработка существующей системы в известных границах — здесь отдельный этап исследования съест бюджет без пользы, достаточно брифа и прототипа. Он оправдан там, где неизвестных много: новый продукт, сложные внутренние процессы, интеграции с учётными системами, несколько ролей пользователей, требования регулятора. Простой критерий — если вы не можете за пять минут перечислить экраны будущей системы, discovery окупится.

Смежные термины

• Техническое заданиеТехническое задание — документ, фиксирующий, что именно должно быть сделано и по каким признакам работа считается принятой: цели, роли, сценарии, требования по экранам, интеграции, нефункциональные требования и отдельный раздел о том, что в проект не входит.
• ВайрфреймВайрфрейм — черновая схема экрана без цвета, шрифтов и картинок: на ней фиксируют состав блоков, их приоритет и переходы между экранами, чтобы договориться о логике интерфейса до того, как начнётся дорогая отрисовка.
• MVPMVP — первая версия продукта с одним сценарием, доведённым до конца: её выпускают за 4–8 недель, чтобы проверить спрос на реальных пользователях и оплатах, а не на опросах, и решить, стоит ли вкладываться дальше.
• Fixed Price и Time and MaterialFixed Price и Time and Material — две модели контракта: в первой зафиксированы объём, срок и цена, а риск с надбавкой за него лежит на подрядчике; во второй оплачивается фактически потраченное время по ставке, а объёмом управляет заказчик.
• Юзабилити-тестированиеЮзабилити-тестирование — проверка интерфейса на живых людях: представители целевой аудитории выполняют реальные задачи и проговаривают свои действия вслух, а команда фиксирует, где они останавливаются, ошибаются и не находят нужное.

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• UX/UI дизайн сайтов и приложенийПроектируем интерфейсы, которые доходят до продакшена: от исследования и структуры до UI-кита и передачи в разработку. Всё живёт в Figma как компоненты с реальными состояниями и брейкпоинтами, а не как папка со статичными картинками. Один и тот же процесс работает для лендинга, корпоративного сайта, интернет-магазина, веб-приложения и мобильного продукта.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Почитать подробнее

• Техническое задание на сайт: структура, шаблон и разбор ошибокТЗ — это не бюрократия, а рычаг: всё, что не соответствует заданию, подрядчик исправляет бесплатно. Разбираем структуру по разделам, показываем заполненный пример для корпоративного сайта и объясняем, как писать критерии приёмки, которые можно проверить.
• MVP в 2026: реальные сроки, бюджет и что резать без потерьMVP перестал означать «дёшево и криво»: плохой прототип сегодня даёт ложноотрицательный результат и хоронит рабочую идею. Разбираем четыре уровня MVP с ценами и сроками, методику резки объёма и то, что вырезать нельзя ни при каком бюджете.
• Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.