Исследование продукта до разработки

Заказчик получает исследование продукта: кто пользователь, какой сценарий главный и чего сознательно нет в первой версии. VIQQ проводит предпроектный этап до прототипа и технического задания - чтобы разработка не начиналась со списка хотелок от разных отделов. Этап нужен там, где сроки хотят контролировать, а смысл продукта ещё спорят.

Без этого ТЗ фиксирует спор, а не решение. Прототип рисует несколько равноправных потоков. Разработка потом платит за несогласованные ожидания сроком и бюджетом. Команда Викью на этапе исследования собирает артефакты, по которым можно идти дальше без презентации «о цифровизации» и без часа устных пояснений каждому новому подрядчику.

Если нужна независимая оценка архитектуры шире продукта, рядом смотрят IT-консалтинг. Сами прототип, ТЗ и MVP после исследования берут отдельными этапами - карточки ниже. Срок предпроекта считаем после списка стейкхолдеров и доступов к текущим инструментам, без обещания «за два дня на холдинг».

Что получите после предпроектного исследования

Карту ролей и ключевых сценариев - с одним главным на первую версию. Ограничения: интеграции, сроки, юридические и ИБ-рамки. Явный список «вне скоупа», чтобы спор не вернулся на старте разработки. Рекомендацию следующего шага: прототип, MVP или полноценное ТЗ.

Рабочие артефакты можно передать в разработку без повторного «расскажите о продукте с нуля». VIQQ фиксирует договорённости так, чтобы их читала и студия, и заказчик. Викью не прячет границы первой версии в сноску.

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

• Карта ролей и один главный сценарий
• Ограничения по интеграциям, срокам и ИБ
• Список того, чего нет в первой версии
• Рекомендация следующего шага
• Материалы для сметы без лишней презентации

Что мы умеем сделать на предпроектном этапе

Интервью со стейкхолдерами и разбор текущих таблиц и легаси. Собираем один главный сценарий, без которого продукт не запускают. Выявляем интеграции, без которых запуск физически невозможен. Фиксируем границы MVP, когда сразу большой объём страшно заказывать.

Формат - короткие рабочие сессии, не исследование рынка на полгода. Если после этапа все хотелки снова в скоупе без приоритета - этап сделали формально, и это видно на сверке.

Разбираем, где процесс уже живёт в таблицах и почте, а где его только обещают «после сайта». Так смета не считает автоматизацию того, чего в компании ещё нет как практики.

Когда предпроектное исследование можно сжать

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

Сжимать нельзя, когда отделы называют разных главных пользователей или когда интеграции «обязательны», но никто не подтвердил доступы. В таком случае короткий этап только перенесёт спор в ТЗ и в разработку. Лучше один лишний созвон на исследовании, чем три круга правок после старта дизайна и кода.

Критерий готовности этапа простой: можно ли передать артефакты другой команде без часа устных пояснений и без возврата вопроса «а кто всё-таки главный пользователь».

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

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

Если доступы задерживаются, этап растягивается не из-за «исследований ради исследований», а из-за отсутствия фактов. Напишите об этом в брифе заранее.

Напишите задачу - посчитаем состав, срок и стоимость после брифа.

Напишите задачу - посчитаем состав, срок и стоимость после брифа.

Актуализировано 18.09.2026