Первая версия корпоративного сайта: поэтапная разработка сайта MVP

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

Что считать первой версией корпоративного сайта

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

Признаки, по которым первую версию можно считать состоявшейся:

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

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

Задача бизнеса и границы решения

Работы начинаются не с макета, а с формулировки задачи в терминах бизнеса. «Сделать сайт» — это не задача, а способ. Задача звучит иначе: например, «получать обращения от оптовых покупателей из двух регионов» или «объяснять новым клиентам, чем наша услуга отличается от типовой». Пока такая формулировка не согласована, любой спор о кнопке или разделе решается вкусовщиной.

Границы решения фиксируют письменно. В них входит:

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

Ответственный за границы — всегда представитель заказчика, у которого есть право сказать «этого в первой версии не будет». Если такого человека нет, границы начнут расползаться: каждый новый участник обсуждения добавит «одну маленькую страничку». При разработке сайтов на Битрикс это особенно заметно, так как система позволяет быстро добавить раздел, но не отменяет необходимости его наполнять и поддерживать.

Минимальные рабочие сценарии первой версии

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

Как отобрать сценарии

Каждый предложенный сценарий оценивают по четырём признакам:

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

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

Что осознанно откладываем

Обычно за границы первой версии выносят:

• личный кабинет и любые формы авторизации посетителей;
• калькуляторы и конфигураторы с расчётом;
• мультиязычность;
• интеграции с внутренними учётными системами;
• разделы с большим объёмом регулярно обновляемого контента.

Это не значит, что они не нужны. Это значит, что их ценность пока не подтверждена, а затраты высоки. Решение о них принимают по результатам первой версии, а не заранее.

Поэтапная разработка сайта MVP и карта версий проекта

Главный рабочий артефакт здесь — карта версий проекта. Это таблица, которая живёт весь срок работ и заменяет собой споры «а давайте ещё». В карте по каждой версии указано:

• номер и короткое название версии;
• какую задачу бизнеса она решает;
• что в неё входит;
• по какому признаку версия считается готовой;
• кто отвечает за её содержание;
• когда состав версии пересматривают.

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

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

План развития без накопления долга

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

Признаки накопления долга

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

Правила, снижающие долг

• Договариваться о структуре разделов и типов страниц до наполнения, а не после.
• Описывать повторяющиеся блоки один раз и переиспользовать.
• Фиксировать в карте версий, какие решения временные и когда их пересмотрят.
• Не откладывать резервное копирование и доступы «на потом»: резервное копирование сайта на Битрикс — хранение и восстановление удобнее настроить до запуска, чем восстанавливать после сбоя.

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

Таблица решений по объёму первой версии

Таблица заполняется вместе с заказчиком и становится приложением к карте версий. Если по строке нет решения, это не «мелочь» — это открытый вопрос, который всплывёт на приёмке.

Учебный пример: первая версия сайта промышленной компании

Учебный пример. Данные условные и приведены только для иллюстрации порядка действий.

Входные условия

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

Что вошло в первую версию

• Главная страница с объяснением, чем компания отличается от перекупщиков.
• Две страницы групп продукции с характеристиками и областью применения.
• Страница с документами и сертификатами.
• Одна короткая форма обращения с полями «имя», «контакт», «что требуется».
• Контакты и реквизиты.

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

Проверка результата

Перед запуском прошли по сценарию от начала до конца на копии: нашли страницу продукции из главной, открыли документы, отправили тестовое обращение и убедились, что письмо дошло до ответственного. Отдельно проверили, что форма не теряет обращения при отправке с телефона и что страница с документами открывается без авторизации. Через месяц после запуска заказчик смотрит не «красиво ли», а сколько обращений пришло и по каким группам продукции — это и определяет состав второй версии.

Как проверить результат и принять работу

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

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

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

Какие исходные данные подготовить для оценки

Оценка объёма работ без исходных данных превращается в угадывание. Чтобы разговор был предметным, к обсуждению готовят:

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

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

Типичные ошибки и ограничения

• Первая версия как «всё, но быстро». Попытка уместить полный функционал в один этап приводит к тому, что ничего не доведено до конца.
• Отсутствие владельца границ. Без человека, принимающего решения, объём растёт на каждом обсуждении.
• Контент «потом». Пустые разделы на запуске подрывают доверие сильнее, чем отсутствие раздела.
• Проверка только на рабочем сайте. Любые изменения сначала проверяют на копии, с планом возврата.
• Забытые доступы. Если учётные записи остались у подрядчика, заказчик теряет управление сайтом; порядок передачи стоит описать заранее, как это делается в администрировании сайта на Битрикс — доступы, данные и настройки.
• Ожидание мгновенного эффекта. Первая версия проверяет гипотезу, а не гарантирует результат; выводы делают по накопленным данным, а не по первой неделе.

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

Роли и ответственность

У первой версии всегда есть несколько ролей, и путать их нельзя.

• Заказчик отвечает за задачу бизнеса и границы. Он же принимает работу.
• Руководитель проекта ведёт карту версий, следит за сроками и фиксирует решения.
• Аналитик или проектировщик описывает сценарии и структуру, проверяет, что они не противоречат друг другу.
• Разработчик реализует согласованный состав и сообщает о технических ограничениях до, а не после.
• Контент-ответственный готовит тексты, документы и изображения к согласованным датам.
• Владелец сопровождения отвечает за доступы, копии и обновления после запуска.

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

Что делать после запуска

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

Главное правило остаётся неизменным: сначала копия, резервирование, тест и план возврата — и только потом изменения на рабочем сайте.