Первый релиз сайта имеет закономерную болезнь: в него хотят впихнуть всё. Калькулятор стоимости, личный кабинет, фильтр с двенадцатью параметрами, интеграция с внутренней системой — каждая функция в отдельности выглядит небольшой. Вместе они раздувают сроки в два-три раза, а после запуска выясняется, что половиной никто не пользуется.
MVP нужен не для того, чтобы «выпустить дёшево». Он нужен, чтобы запустить проверяемый путь клиента — и не тратить месяцы на то, что этот путь не проверяет.
Начните с сценария, а не с функций
Первый вопрос звучит просто: что посетитель должен сделать на сайте? Выбрать услугу и отправить заявку. Найти дилера. Скачать документ. Записаться на консультативную встречу.
Первый релиз обязан позволить пройти этот маршрут целиком — без ручных костылей внутри команды. Если менеджеру приходится вручную переписывать заявку из почты в CRM, маршрут ещё не работает, сколько бы страниц ни было свёрстано.
Каждую функцию, которая не влияет на ключевой сценарий, можно заменить временным простым процессом. Клиенту, который получает один документ в месяц, не нужен личный кабинет — ему нужен рабочий канал выдачи. Решение о переносе фиксируют с причиной и условием возврата к задаче, иначе «отложенное» навсегда превращается в «забытое».
Оценивайте риск, а не только трудозатраты
Самый обидный кейс: небольшой виджет, который требует нового источника данных, согласований, персональных данных и отдельного регламента. Формально — пара дней разработки, фактически — месяц согласований и юридическая ответственность.
Поэтому для каждой идеи смотрят четыре вещи:
- ценность для ключевого сценария;
- готовность данных (кто владелец, откуда берутся);
- зависимости от других работ;
- стоимость ошибки после запуска.
Такой список превращает спор «надо/не надо» в предметное обсуждение.
Что обычно входит в первый релиз
Для корпоративного сайта типовой набор скромен:
- понятная структура услуг;
- контактные точки на каждом шаге;
- адаптивные шаблоны;
- базовая аналитика;
- рабочая форма с уведомлениями;
- минимальные права редакторов.
Ключевое слово — «рабочая». Форма, которая отправляет письмо, но теряет контекст обращения, не рабочая. Форма, по которой заявка падает в CRM с темой, источником и содержимым, — рабочая.
А вот закрытый кабинет «потому что он в стратегии» — классический кандидат на второй этап. Как и расширенные подборки, редкие интеграции, декоративные интерактивные элементы.
Что нельзя откладывать никогда
Откладывание — не отказ от обязательного. Нельзя переносить на второй этап:
- работу ключевой формы;
- права доступа и базовую безопасность;
- обязательные согласия и юридические требования;
- контроль ошибок и резервирование.
Эти элементы не «улучшают» MVP. Они делают его пригодным для реальной работы с реальными людьми.
Как проверить результат
Перед релизом прогоняют полный путь с реального устройства: вход на страницу, выбор услуги, отправка формы, получение данных ответственным в CRM. Затем — наблюдение: фактические обращения, ошибки, вопросы пользователей, сравнение с гипотезой первого релиза.
Если сценарий не работает, первый порыв обычно неверный — добавить новые функции. Правильный — найти причину: содержание, форма, маршрутизация заявки, скорость или работа менеджера. Чаще всего дело не в недостающем калькуляторе.
Где проходит граница
В первый релиз входит путь, по которому посетитель понимает предложение и может совершить целевое действие. Для сайта услуг это входная страница, описание услуги, форма обращения и маршрут заявки к ответственному. Дополнительные разделы берут в релиз, только если без них путь обрывается.
У каждой отложенной задачи должно быть условие возврата: появление новой услуги, повторяющийся вопрос из обращений, необходимость изменить маршрут пользователя. Формулировка «сделаем потом» планированию не помогает.
Рабочий артефакт
После согласования у команды остаётся две вещи: карта первого релиза (страницы, формы, интеграции, владельцы, критерии приёмки) и бэклог отложенного с причинами и сигналами для возвращения в план. Это и есть управляемость: следующий этап формируют по наблюдаемым проблемам, а не по длине первоначального списка желаний.
MVP завершён, когда основной сценарий доступен пользователю, обращения проходят проверку, а команда знает, что именно она сознательно отложила — и почему.
Top comments (0)