Этапы разработки сайта: от брифа до запуска

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

Бизнес-контекст выбора архитектуры

Занимает 1–2 недели. Результат — зафиксированные цели бизнеса, портрет пользователей и ограничения (бюджет, сроки, обязательные интеграции). Здесь же собирают входной бриф — что уже есть у заказчика (домен, хостинг, старый контент, доступы к аналитике) и чего явно не будет в первой версии. Пропуск этого этапа — самая частая причина, почему смета «плывёт» на середине проекта: без зафиксированной цели любое расширение объёма выглядит для заказчика естественным, а для подрядчика — незапланированной доработкой.

Trade-offs: скорость vs гибкость

Занимает 1–3 недели. Здесь собирают структуру сайта (карту разделов), пользовательские сценарии и технологический контур — какие интеграции нужны (CRM, оплата, 1С), как устроена модель данных, какая CMS или headless-архитектура подойдёт под объём контента и команду, которая будет с ним работать после запуска. Результат этапа — техническое задание: не бриф с целями, а конкретный состав страниц, функций и интеграций, по которому можно оценивать разработку и на который потом ссылается договор.

Когда хватает простого контура

Занимает 2–4 недели. Создаётся интерактивный прототип (кликабельный макет ключевых экранов) и согласуется с заказчиком до начала разработки. Здесь проверяют, что сценарии реально работают для пользователя — например, что путь от карточки товара до оформления заказа не требует лишних кликов — пока правки стоят часы дизайнера, а не недели разработчика. Пропуск прототипа и переход сразу к разработке — вторая по частоте причина пересмотра сроков: несостыковки в UX всплывают в готовом коде, где их дороже исправлять.

Когда нужна более сложная схема

Срок зависит от объёма — от нескольких недель для лендинга до нескольких месяцев для интернет-магазина или портала. Работа ведётся спринтами с регулярными демо (обычно раз в 1–2 недели), а не «сдачей в конце» — это позволяет заказчику видеть прогресс и вносить правки по ходу, а не только на финальной приёмке. Именно на этом этапе всплывают технические ограничения (например, особенности API платёжного провайдера или 1С), которые не всегда видны на этапе проектирования — разумный подход закладывает буфер по времени под такие находки, а не жёсткий дедлайн день-в-день.

Как мигрировать без простоя

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

Практический вывод

Цифры ориентировочные — точный срок фиксируется после этапа 2 (проектирования), когда виден реальный состав ТЗ.

Где чаще всего теряют время

1. Пропускают этап проектирования и сразу переходят к разработке — потом переделывают структуру на живом коде
2. Согласовывают дизайн без прототипа — несостыковки в сценариях всплывают только на приёмке готовых экранов
3. Не фиксируют ТЗ как приложение к договору — любое расширение объёма превращается в спор, входило оно в смету или нет
4. Ожидают финальную версию сайта сразу после запуска, хотя доработки по факту метрик — стандартная часть этапа 5, а не признак недоделанной работы

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