MVP сайта: какие функции выпускать первыми

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Назовите предположение, которое проверяет первый выпуск

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

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

В описании этапа alpha в GOV.UK предлагается проверять наиболее рискованные предположения до полноценного сервиса. Для коммерческого проекта полезна сама логика: сначала установить, имеет ли смысл решение, затем расширять реализацию. Иногда для первого ответа достаточно прототипа, и публичный запуск ещё не нужен.

Выберите один законченный пользовательский путь

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

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

Запишите и исключения. Какие запросы первая версия не обслуживает? Как человек об этом узнаёт? Куда он может обратиться вместо тупика? Ограничение должно быть понятно до того, как пользователь потратит время на заполнение данных.

Разделите обязательное, полезное и отложенное

Для каждой функции задайте три вопроса: можно ли без неё закончить основной сценарий, что произойдёт при её отсутствии, чем её можно временно заменить. Если объяснение сводится к «так принято» или «есть у конкурентов», это слабое основание для первого выпуска.

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

Подобное разделение описано в руководстве GOV.UK по приоритетам. Важно регулярно пересматривать приоритеты по данным и учитывать поддержку наряду с новыми функциями. Само название категории не решает спор: если всё объявлено обязательным, нужно вернуться к границам пользовательского пути.

Сначала примените ограничения, которые нельзя нарушать, и только затем сравнивайте удобство. Безопасность, корректность обработки данных и достоверность обещаний не стоит переводить в необязательные пункты ради уменьшения списка. Минимальность относится к охвату, а не к допустимости вредных ошибок.

Используйте ручную работу там, где она управляемая

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

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

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

Не вырезайте невидимые части продукта

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

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

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

Заранее решите, как интерпретировать результат

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

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

Определите период наблюдения по объёму и характеру спроса, а не по желанию немедленно получить вывод. Редкие B2B-запросы могут требовать сочетания статистики, интервью и обратной связи отдела продаж. Небольшая выборка не позволяет уверенно обещать будущую выручку.

Условный пример первой версии каталога

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

Личный кабинет и повтор заказа откладывают: они обслуживают другой сценарий. Персональные цены пока готовит менеджер. При этом сохраняют выбранные позиции в заявке, подтверждают её получение и назначают сотрудника для разбора. Иначе нельзя будет понять, помог ли самостоятельный подбор.

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

Не называйте технический полуфабрикат первым выпуском

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

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

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

Оформите границы выпуска на одной странице

1. Для кого предназначена первая версия.
2. Какую задачу человек может завершить.
3. Какое предположение проверяется.
4. Что включено и что явно исключено.
5. Какие операции выполняются вручную и кем.
6. Какие риски необходимо закрыть до публикации.
7. Какие наблюдения определяют следующий шаг.

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