Discovery-фаза: зачем нужна перед разработкой и что на выходе
Discovery-фаза — это несколько недель работы до первой строки кода: команда выясняет, какую задачу решает продукт, для кого он и в каком объёме его запускать. Одни компании проходят этот этап за две-три недели, другие начинают сразу с разработки и уточняют требования уже по ходу, в макетах и коде. Дальше — чем Discovery отличается от технического задания и MVP, какие документы остаются у заказчика на выходе, как проходят этапы и когда без исследования можно обойтись.
Что такое Discovery-фаза простыми словами
Знакомая многим ситуация: у компании есть идея приложения или сайта и бюджет, а на встрече с подрядчиком выясняется, что у отдела продаж, маркетинга и склада разные представления о том, что должен уметь продукт. Если начать разработку сразу, спор продолжится уже в макетах и коде, где каждое изменение стоит дороже.
Discovery-фаза (от англ. discovery — «открытие»; по-русски её называют предпроектным исследованием) — короткий этап до разработки. На нём команда выясняет, какую задачу бизнеса решает продукт, кто и как будет им пользоваться, с какими системами он связан и что войдёт в первую версию. На выходе остаётся не отчёт ради отчёта, а набор документов, по которым считают срок и бюджет и подписывают договор.
В исследовании работают бизнес-аналитик, дизайнер интерфейсов и архитектор или ведущий разработчик. Со стороны заказчика — владелец продукта и представители отделов, которых продукт затрагивает. Кто за что отвечает в проектной команде, описано в статье о составе команды разработки.
Discovery отвечает на пять вопросов:
| Вопрос | Что выясняют | Чем подтверждают |
|---|---|---|
| Зачем | Цель продукта и 2–3 метрики, по которым будут оценивать результат | Бриф, согласованный с владельцем продукта |
| Для кого | Сегменты аудитории и их сценарии: что человек делает и в каком порядке | Интервью, данные продаж и аналитики, опросы |
| Что | Функции и их приоритеты, граница первой версии | Перечень требований и карта пользовательских историй |
| Как | Платформы, архитектура, обмен данными с 1С, CRM, складом, эквайрингом | Схема системы и интеграций |
| Сколько | Срок и бюджет первой версии, очереди развития | Оценка по ролям и дорожная карта |
Discovery не заменяет разработку и не отменяет проверку продукта на пользователях: этап сокращает число решений, принятых наугад. Место исследования в общем цикле показано в статье об этапах разработки ПО и в материале о жизненном цикле продукта.
Discovery, ТЗ, бизнес-аналитика и MVP: в чём разница
Эти слова часто используют как синонимы, хотя они отвечают на разные вопросы и дают разный результат.
| Формат | На какой вопрос отвечает | Что остаётся на выходе | Когда уместен |
|---|---|---|---|
| Discovery-фаза | Стоит ли делать продукт, для кого и в каком объёме | Цели и метрики, сценарии, приоритеты, прототип, архитектура, оценка и план | Новый продукт или направление, требования не согласованы |
| Бизнес-аналитика | Что нужно бизнесу и пользователям | Перечень требований с приоритетами, карта пользовательских историй, функциональная документация | Требования расходятся между отделами; аналитик нужен и в идущем проекте |
| Техническое задание | Что именно и по каким правилам разрабатывать | Документ для договора и приёмки: экраны, роли, интеграции, критерии приёмки | Цель и объём понятны, нужна фиксация для оценки и договора |
| MVP (минимально жизнеспособный продукт) | Будут ли продуктом пользоваться | Рабочая первая версия с одним-двумя сценариями и данные о поведении пользователей | Гипотеза сформулирована, её проверяют на первых покупателях |
| Прототип | Понятен ли интерфейс | Кликабельные макеты ключевых экранов | Сценарии проверяют на пользователях или показывают продукт инвестору |
На практике форматы идут цепочкой: Discovery включает аналитику и заканчивается техническим заданием, а ТЗ задаёт объём MVP. В FITTIN эта связка закрывается услугами бизнес-аналитики для IT-проектов и разработки технического задания, исследование и документ для договора делают одним пакетом работ. Если продукт сначала нужно проверить на пользователях, следующий шаг описан на странице разработки MVP и в статье о сроках и стоимости MVP. Когда вместо MVP нужна проверка технической осуществимости или запуск в одном подразделении, разобрано в статье о POC и пилоте проекта.
Что на выходе Discovery-фазы
Результат Discovery — комплект документов и макетов, который остаётся у заказчика и с которым может работать любая команда разработки. Состав зависит от формата, в стандартный набор входят восемь артефактов.
| Артефакт | Что внутри | Кому и зачем нужен |
|---|---|---|
| Описание продукта и цели | Задача бизнеса, аудитория, бизнес-модель, метрики успеха | Руководству — решить, запускать ли проект, и договориться, как оценивать результат |
| Карта участников и записи интервью | Кого затрагивает продукт, как устроен процесс сейчас, где он даёт сбои | Команде — учесть требования продаж, склада, поддержки и ИТ-службы |
| Анализ конкурентов и решений в нише | Как похожие задачи решены у других компаний, какие сценарии привычны покупателям | Дизайнеру и владельцу продукта — не изобретать заново решённое |
| Перечень требований с приоритетами | Функции по методу MoSCoW: обязательно, желательно, возможно, не в этой версии | Всем участникам — договориться, что входит в первую версию |
| Карта пользовательских историй (User Story Map) | Сценарии пользователя по шагам и функции под каждый шаг, разметка очередей | Команде разработки — видеть объём целиком и делить его на очереди |
| Прототипы ключевых экранов | Структура, навигация и логика интерфейса в Figma | Заказчику — увидеть продукт до кода; дизайнеру — основа для макетов |
| Архитектура и схема интеграций | Части системы, платформы, обмен данными с 1С, CRM, эквайрингом, требования к доступам | Разработчикам и ИТ-службе — оценить сложность и подготовить доступы |
| Оценка, план и дорожная карта | Этапы, срок и бюджет первой версии, приоритеты следующих очередей | Руководству и финансовой службе — заложить бюджет и подписать договор |
Если по итогам исследования нужен документ для договора и приёмки, артефакты сводят в техническое задание. Как каркасы экранов экономят время на дизайне, разобрано в статье о вайрфреймах, как описывают обмен данными с другими системами — в материале о проектировании REST API.
Одно условие стоит записать в договор заранее: все исходники — файлы Figma, диаграммы, спецификация — передаются заказчику. Тогда документы можно отдать любому подрядчику или вынести на тендер.
Форматы Discovery: экспресс, стандартный и комплексный
Глубина исследования зависит от размера продукта и от того, сколько известно на старте. Сроки ниже — ориентиры по нашему опыту, точные цифры фиксируют после первой встречи.
| Формат | Для какого продукта | Что входит | Срок |
|---|---|---|---|
| Экспресс | Первая версия до 20 экранов, одна роль пользователя, цель и аудитория понятны | Интервью с заказчиком, приоритизация, пользовательские сценарии, каркасы ключевых экранов | 10–15 рабочих дней |
| Стандартный | Продукт до 50 экранов, несколько ролей, 2–4 интеграции | Интервью с участниками, анализ конкурентов, карта пользовательских историй, интерактивный прототип, архитектура и план | 15–20 рабочих дней |
| Комплексный | Приложение, сайт и административная панель, много интеграций или новая для компании ниша | Всё из стандартного плюс исследование пользователей и детальное описание обмена данными с системами (API-контракты) | 20–30 рабочих дней |
Если нужно проверить спрос в незнакомой нише, в Discovery добавляют интервью и тесты с будущими покупателями — методы описаны в статье об UX-исследованиях. Для работающего продукта отправная точка другая: аудит UX/UI показывает, где пользователи теряются в сценариях, а комплексный аудит интернет-магазина — что мешает продажам в целом.
Как проходит Discovery: карта этапов
Исследование проходит пять этапов. Сроки в таблице — для стандартного формата.
| Этап | Что происходит | Срок | Результат |
|---|---|---|---|
| 1. Знакомство с задачей | Интервью с заказчиком: цели, аудитория, ограничения, границы продукта | 1–2 рабочих дня | Бриф и критерии успеха |
| 2. Интервью и анализ рынка | Встречи с участниками процесса, разбор смежных систем, анализ конкурентов | 4–5 рабочих дней | Записи интервью, карта участников, обзор решений в нише |
| 3. Приоритизация и сценарии | Отбор функций, объём первой версии, карта пользовательских историй | 2–3 рабочих дня | Перечень требований с приоритетами |
| 4. Прототип ключевых экранов | Каркасы и прототип в Figma, проверка сценариев | 5–6 рабочих дней | Согласованный прототип |
| 5. Архитектура, оценка и план | Схема системы и интеграций, оценка по ролям, дорожная карта, защита результатов | 3–4 рабочих дня | Оценка срока и бюджета, план очередей |
В сумме этапы дают 15–20 рабочих дней, то есть 3–4 недели. Срок сильнее всего зависит от скорости ответов со стороны заказчика: если встречи с отделами растягиваются на две недели, на столько же сдвигается всё исследование. Экспресс-формат сокращает второй и четвёртый этапы, комплексный добавляет исследование пользователей и описание обмена данными.
Этап 1. Знакомство с задачей и целями
Что происходит: Аналитик проводит интервью с владельцем продукта: зачем бизнесу продукт, какую проблему он решает, как будут оценивать результат. Здесь же фиксируют ограничения — бюджет, дату запуска, обязательные системы, требования к защите данных.
Что входит в этап
- интервью с владельцем продукта и руководителем направления;
- цель продукта и 2–3 метрики успеха: доля заказов через приложение, повторные покупки, время обработки заказа;
- границы продукта — что точно не входит в проект;
- список участников, с которыми нужно поговорить;
- перечень систем, с которыми связан продукт;
- ограничения по срокам, бюджету и защите данных.
Результат этапа
Бриф на 2–4 страницы с целью, метриками, границами и списком участников. Документ согласует заказчик, и дальше команда сверяет с ним каждое решение. Артефакт этапа — согласованный бриф.
Проверьте перед следующим этапом
- Цель продукта сформулирована одной фразой?
- У каждой метрики есть текущее значение или способ его получить?
- Назначен владелец продукта, который принимает решения?
- Составлен список участников интервью с датами встреч?
- Известно, какие системы придётся подключать и у кого доступы?
Типичная ошибка на этом этапе
Метрика вида «удобное приложение» или «рост продаж» без цифры и срока. Через полгода по ней нельзя понять, достигнута ли цель. Работает формулировка вида «20% онлайн-заказов через приложение через год после запуска» — и сразу договорённость, откуда брать эту цифру. Метрики и инструменты их сбора — в статье об аналитике мобильного приложения.
Этап 2. Интервью с участниками и анализ рынка
Что происходит: Аналитик встречается со всеми, кого затрагивает продукт: продажами, маркетингом, логистикой, поддержкой, ИТ-службой. У каждой роли своя картина процесса, и задача этапа — собрать их в одну. Параллельно дизайнер изучает, как похожие задачи решены у компаний в той же нише.
Что входит в этап
- 5–10 встреч по заранее подготовленным вопросам;
- описание текущего процесса «как есть» и мест, где он даёт сбои;
- разбор смежных систем: 1С, CRM, склад, эквайринг, службы доставки;
- анализ 3–5 продуктов конкурентов и сценариев, привычных покупателям;
- проверка, какие персональные данные будет обрабатывать продукт: их обработку регулирует Федеральный закон № 152-ФЗ «О персональных данных»;
- список расхождений между отделами для общего согласования.
Результат этапа
Записи и выводы интервью, карта участников и обзор решений в нише. Расхождения между отделами вынесены отдельным списком и согласованы на общей встрече. Артефакт этапа — карта участников с выводами интервью и обзор конкурентов.
Проверьте перед следующим этапом
- Поговорили со всеми ролями, которых меняет продукт, включая склад и поддержку?
- Для каждой смежной системы известно, какие данные она отдаёт и кто за неё отвечает?
- Спорные требования решены владельцем продукта, а не отложены?
- В обзоре конкурентов есть выводы, а не только снимки экранов?
- Служба безопасности знает, какие персональные данные появятся в продукте?
Типичная ошибка на этом этапе
Ограничиться встречей с руководством. Требования склада или контакт-центра всплывают на тестировании, и экраны переделывают. Другие частые промахи на стороне заказчика собраны в статье об ошибках заказчика при разработке приложения.
Этап 3. Приоритизация и карта пользовательских историй
Что происходит: Собранные требования превращают в список функций и раскладывают по приоритетам. Обычно пользуются методом MoSCoW (от англ. Must, Should, Could, Won’t — обязательно, желательно, возможно, не в этой версии). Сценарии пользователя раскладывают на шаги в карте пользовательских историй, чтобы увидеть объём продукта целиком.
Что входит в этап
- проверка требований на противоречия и выполнимость;
- приоритизация по MoSCoW вместе с владельцем продукта;
- карта пользовательских историй: путь покупателя от первого действия до результата;
- граница первой версии — какие функции идут в запуск, какие в следующие очереди;
- гипотезы, которые стоит проверить на пользователях после запуска.
Результат этапа
Перечень требований с приоритетами и карта пользовательских историй с размеченными очередями разработки. Артефакт этапа — подписанный владельцем продукта список функций первой версии.
Проверьте перед следующим этапом
- В группе «обязательно» только функции, без которых продукт не решает задачу?
- Для каждой функции понятно, какой сценарий пользователя она обслуживает?
- Первая версия укладывается в бюджет и срок из брифа?
- Функции «на потом» записаны, а не потеряны?
- Владелец продукта согласовал список?
Типичная ошибка на этом этапе
Все требования попадают в «обязательно». Первая версия разрастается, запуск откладывается, а вместе с ним и проверка гипотез. Как ограничить объём первой версии под бюджет — в статье о бюджете стартап-проекта.
Этап 4. Прототип ключевых экранов
Что происходит: Дизайнер собирает каркасы (вайрфреймы) ключевых экранов, а затем кликабельный прототип: структуру, навигацию и логику переходов без финального визуального стиля. Прототип показывают заказчику и, если позволяет срок, 5–7 будущим пользователям.
Что входит в этап
- каркасы экранов для каждого сценария первой версии;
- кликабельный прототип в Figma для сценариев поиска, карточки товара, корзины и оформления заказа;
- сверка с правилами платформ — руководством Apple по интерфейсам и рекомендациями Android по дизайну;
- проверка сценариев на заказчике и нескольких пользователях;
- правки по результатам показа.
Результат этапа
Согласованный прототип ключевых экранов — основа для дизайна интерфейса и для оценки объёма разработки. Артефакт этапа — прототип в Figma с пройденными сценариями первой версии.
Проверьте перед следующим этапом
- Все сценарии из группы «обязательно» пройдены в прототипе от начала до конца?
- Пользователь дошёл до целевого действия без подсказок?
- Экраны учитывают ограничения смежных систем — например, какие статусы заказа отдаёт 1С?
- Заказчик смотрел прототип на телефоне, а не только на мониторе?
- Правки собраны в одном месте и закрыты?
Типичная ошибка на этом этапе
Обсуждать цвета и шрифты вместо сценариев. На этом этапе проверяют логику, визуальный стиль появится на дизайне. Следующий шаг описан на странице UX/UI-дизайна приложения и сайта и в статье об этапах UI/UX-дизайна.
Этап 5. Архитектура, оценка и план
Что происходит: Архитектор или ведущий разработчик описывает, из каких частей будет состоять система, на каких платформах она работает и как обменивается данными с другими системами. По прототипу и требованиям команда оценивает работу по ролям и собирает план по очередям. На финальной встрече результаты защищают перед заказчиком.
Что входит в этап
- схема системы: приложение, сайт, серверная часть, административная панель;
- выбор платформ и технологий — например, одна кодовая база на Flutter для iOS, Android и веб-версии;
- схема интеграций и требования к доступам;
- требования к публикации: правила App Store, RuStore и других сторов;
- оценка по ролям и этапам, срок первой версии;
- дорожная карта следующих очередей и финальная встреча с защитой результатов.
Результат этапа
Оценка срока и бюджета первой версии, архитектура и дорожная карта. Если нужен документ для договора и приёмки, материалы сводят в техническое задание. Артефакт этапа — оценка по ролям и этапам вместе с планом очередей.
Проверьте перед следующим этапом
- Оценка разбита по ролям и этапам, а не дана одной суммой?
- Для каждой интеграции понятно, кто отвечает за доступы и тестовые данные?
- Известно, сколько стоит поддержка после запуска?
- Требования сторов учтены до разработки?
- Все исходники переданы заказчику?
Типичная ошибка на этом этапе
Считать оценку по итогам Discovery окончательной ценой без запаса. Исследование снимает большую часть вопросов, но не все: заложите резерв на уточнения, а крупные изменения объёма оформляйте отдельно. Что зафиксировать до старта разработки — в статье с чек-листом по бюджету и срокам.
Когда Discovery нужна, а когда можно обойтись без неё
Пять ситуаций, в которых исследование до разработки окупается чаще всего:
- Новый продукт или направление. Опыта нет, гипотезы о спросе и сценариях не проверены.
- Требования расходятся между отделами. Маркетинг, продажи и склад по-разному видят продукт, и договориться нужно до макетов.
- Подрядчик выбирается по тендеру. Без единого документа каждая студия оценивает свой вариант продукта, и, по нашему опыту, разброс оценок достигает 3–5 раз.
- Много интеграций. 1С, CRM, склад, лояльность, службы доставки — каждая система добавляет ограничения, которые лучше знать до оценки.
- Нужно показать продукт инвестору. Описание, прототип и план с бюджетом убедительнее презентации идеи.
Длинная Discovery не нужна, когда задача и объём уже понятны: доработка работающего продукта, небольшой лендинг, проект по готовому ТЗ. Хватает короткой встречи и оценки.
Отдельный случай — интернет-магазин на модульной платформе. Каталог, корзина, оплата, лояльность и интеграции с 1С и маркетплейсами уже написаны и проверены на других проектах, поэтому исследование сводится к настройке модулей под бренд и списку уникальных сценариев. Модульная Flutter-платформа FITTIN работает по модели из трёх частей. Первая — единоразовая интеграция под бренд до 30 рабочих дней. Вторая — ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN, поэтому для базового сопровождения собственная команда разработки не требуется. Третья — новый функционал и доработки, их оплачивают отдельно по Time & Materials с оценкой в часах перед стартом задачи. Подробнее — на страницах мобильного приложения для интернет-магазина и приложения и сайта на одной кодовой базе.
Если продукт уже работает и его делал другой подрядчик, вместо Discovery начинают с аудита кода: он показывает, что можно развивать, а что проще переписать.
Сколько стоит Discovery-фаза
Стоимость зависит от объёма продукта и от того, что известно на старте. Исследование оплачивают фиксированной ценой, когда состав работ ясен заранее, или по фактически затраченным часам (Time & Materials), когда аналитика подключают к идущему проекту. Сравнение двух моделей — в статье Time & Material или Fix Price.
Семь факторов, которые определяют цену
| Фактор | Что увеличивает объём работ | Как сократить без потери смысла |
|---|---|---|
| Число ролей и сценариев | Каждая роль — свои требования, экраны и права | Первая версия под одну-две роли |
| Число участников интервью | Больше отделов — больше встреч и согласований | Один ответственный от каждого отдела |
| Интеграции | Каждая система — разбор данных и правил обмена | Разбирать только системы, без которых первая версия не работает |
| Число платформ | Приложение, сайт, административная панель | Одна кодовая база для приложения и сайта |
| Глубина прототипа | Интерактивный прототип всех экранов вместо каркасов ключевых | Детальный прототип только для сценариев «обязательно» |
| Исследование пользователей | Интервью, опросы, тесты прототипа | Проводить, когда ниша новая для компании |
| Готовые материалы | Если процессы не описаны, цикл интервью длиннее | Собрать до старта регламенты, выгрузки и схемы систем |
Цены на Discovery и техническое задание
В FITTIN Discovery входит в услугу разработки технического задания. Цены с НДС опубликованы на странице разработки ТЗ:
| Формат | Что входит | Срок | Цена |
|---|---|---|---|
| Мини-ТЗ | Описание MVP до 20 экранов, пользовательские сценарии, каркасы ключевых экранов | 10–15 рабочих дней | от 80 000 ₽ |
| Стандартное ТЗ | Полная спецификация до 50 экранов, интерактивные прототипы, архитектура и план реализации | 15–20 рабочих дней | от 200 000 ₽ |
| Комплексное ТЗ | Приложение для iOS и Android, сайт и административная панель, описание обмена данными (API-контракты), UX-исследование | 20–30 рабочих дней | от 400 000 ₽ |
Если исследование ведут по часам, в смету входят работа аналитика (3 150 ₽ в час), дизайнера UX/UI (3 990 ₽) и руководителя проекта (2 940 ₽) — это ставки Time & Materials с НДС со страницы тарифов. Мы федеральная команда с центром разработки в Воронеже: распределённая модель позволяет держать эффективные ставки без потери качества.
Как исследование окупается
Discovery не страхует от всех ошибок, но меняет основу сметы. Без согласованных требований каждая команда оценивает свой вариант продукта. После исследования подрядчики считают один и тот же объём, а изменения по ходу разработки видны на фоне согласованного списка и оцениваются отдельно. Из чего складывается смета разработки, разобрано в статье о стоимости разработки ПО.
Как выбрать подрядчика для Discovery
Discovery — работа аналитика и дизайнера, а не отдела продаж. Шесть вопросов до договора:
- Кто будет проводить исследование? В команде должны быть бизнес-аналитик, дизайнер интерфейсов и архитектор, а не только менеджер.
- Что останется у вас на руках? Перечень артефактов и формат передачи — файлы Figma, диаграммы, спецификация — лучше записать в договор.
- Можно ли отдать результат другой команде? Документы должны быть написаны так, чтобы по ним работал любой подрядчик.
- Как идёт согласование? Встречи после каждого этапа позволяют поменять направление, не дожидаясь финала.
- Как считается цена? Фиксированная сумма за оговорённый состав работ или часы по ролям с оценкой до старта.
- Что будет, если исследование покажет, что продукт в задуманном виде делать не стоит? Такой вывод — тоже результат, и подрядчик должен быть готов его сформулировать.
Как проверить команду до подписания договора — в чек-листе заказа разработки, сравнение подряда с наймом — в материале об аутсорсе и своей команде.
Кейсы: что меняют требования, собранные до разработки
Три проекта FITTIN, где результат зависел от того, насколько точно описаны аудитория и процессы. Цифры приведены со страниц кейсов.
IDOL — 2% покупателей дают около 40% выручки
Приложение премиального fashion-бренда с журнальной подачей. По данным страницы кейса, VIP-сегмент — 2% покупателей — приносит около 40% выручки. Поэтому сценарии для этой группы — подборки «Сочетается с», «Купить весь образ», программа лояльности — весят больше, чем сценарии «среднего покупателя». Такие пропорции выясняют на интервью и в данных продаж до того, как проектировать экраны.
«Сатурн» — конверсия в покупку 12,4%
Сеть строительных гипермаркетов в 20+ городах с каталогом свыше 30 000 товаров. По данным страницы кейса — конверсия в покупку 12,4% и 7 594 установки за первый месяц. Колеровка краски, распил листовых материалов, доставка с манипулятором, заказ на юрлицо, привязка к региональным складам в 1С — каждое такое требование меняет экраны и интеграции, поэтому его нужно знать до оценки.
Finn Flare — бюджет в 2,5 раза меньше, релиз менее чем за 30 рабочих дней
Перезапуск существующего приложения на Flutter для России и Казахстана, с ценами в рублях и тенге. По данным страницы кейса, бюджет получился в 2,5 раза меньше, скорость разработки — в 1,5 раза выше: старт 28 декабря 2025 года, релиз 3 февраля 2026 года. При перезапуске работающий продукт сам служит источником требований: сценарии и данные пользователей уже есть, и предпроектная работа отвечает на вопрос, что сохранить, а что изменить.
Остальные проекты — в разделе кейсов. Если продукт — внутренний сервис для сотрудников, подход к исследованию описан на странице корпоративных приложений.
Итог: Discovery-фаза на одной странице
Discovery-фаза — предпроектное исследование, после которого у заказчика есть цель и метрики, согласованные требования, прототип, архитектура и оценка. Порядок действий:
- Сформулируйте цель и метрики — без них не с чем сравнивать результат.
- Выберите формат по размеру продукта — экспресс, стандартный или комплексный.
- Соберите участников — все отделы, которые затрагивает продукт.
- Ограничьте первую версию — приоритеты по MoSCoW и граница запуска.
- Проверьте сценарии на прототипе до того, как писать код.
- Заберите исходники и оценку — с ними можно работать с любым подрядчиком.
Что делать дальше:
- Собрать требования и документ для договора — разработка технического задания и бизнес-аналитика.
- Прикинуть бюджет разработки — калькулятор стоимости, ставки и пакеты — на странице тарифов.
- Проверить гипотезу на пользователях — разработка MVP или приложение для стартапа.
Вопросы и ответы
Что такое Discovery-фаза в разработке?
Это предпроектное исследование перед разработкой: команда выясняет цель продукта, аудиторию, сценарии, ограничения смежных систем и объём первой версии. На выходе — требования с приоритетами, прототип ключевых экранов, архитектура и оценка срока и бюджета. Этап занимает от 10 до 30 рабочих дней в зависимости от размера продукта.
Чем Discovery-фаза отличается от технического задания?
Discovery отвечает на вопрос, что и в каком объёме делать, а техническое задание фиксирует, как это разрабатывать и принимать. В Discovery входят интервью, анализ рынка, приоритизация и прототип, а ТЗ сводит согласованные решения в документ для договора. Обычно исследование заканчивается техническим заданием, и обе работы делают одним пакетом.
Сколько длится Discovery-фаза?
Экспресс-формат для продукта до 20 экранов занимает 10–15 рабочих дней, стандартный для продукта до 50 экранов — 15–20, комплексный для приложения, сайта и административной панели — 20–30 рабочих дней. Сильнее всего на срок влияет то, насколько быстро заказчик организует интервью и согласует промежуточные результаты.
Сколько стоит Discovery-фаза?
Цена зависит от числа ролей и сценариев, интеграций, платформ и глубины прототипа. В FITTIN исследование входит в разработку технического задания: мини-ТЗ — от 80 000 ₽, стандартное — от 200 000 ₽, комплексное — от 400 000 ₽ с НДС. При оплате по часам работа аналитика стоит 3 150 ₽ в час, дизайнера UX/UI — 3 990 ₽.
Можно ли пропустить Discovery и сразу начать разработку?
Можно, если задача и объём понятны: доработка работающего продукта, небольшой сайт, проект по готовому ТЗ. Для нового продукта, тендера или проекта с несколькими интеграциями пропуск исследования переносит уточнение требований на этап разработки, где каждое изменение затрагивает макеты и код.
Кто участвует в Discovery со стороны заказчика?
Владелец продукта, который принимает решения, и представители отделов, которых затрагивает продукт: продаж, маркетинга, логистики, поддержки, ИТ-службы. Если продукт обрабатывает персональные данные, к работе подключают службу безопасности или юриста. От заказчика нужны время на интервью и согласование результатов после каждого этапа.
Можно ли передать результаты Discovery другому подрядчику?
Да. Требования, прототипы в Figma, диаграммы и оценка остаются у заказчика, и по ним может работать любая команда разработки. Формат передачи исходников лучше записать в договор до начала работ.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.
