Сроки и планирование
Сколько времени занимает разработка сайта
Срок сайта определяется не количеством экранов, а объёмом решений, контента, интеграций и согласований. Поэтому честная оценка всегда привязана к составу первого релиза.
Коротко
По практике ХЭМС, лендинг обычно занимает 2–4 недели, корпоративный сайт — 6–12 недель, интернет-магазин — 8–16 недель, а web-приложение — от 12 недель. Это ориентиры, а не обещание без вводных: точный срок зависит от готовности контента, числа шаблонов, интеграций, ролей, миграции данных и скорости согласований.
Ориентиры по срокам для разных типов сайтов
Одностраничный сайт и интернет-магазин нельзя оценивать одной формулой. В лендинге команда проверяет оффер, структуру, визуальную концепцию, адаптив и форму заявки. В магазине к этому добавляются каталог, карточка товара, корзина, оплата, доставка, статусы, личный кабинет и административная часть.
Диапазоны ниже подходят для планирования первого разговора. После брифа срок уточняют по конкретному составу и фиксируют в дорожной карте. Если проект нужно выпустить к событию или рекламной кампании, сначала определяют минимальный релиз, который действительно можно проверить на пользователях.
| Формат | Ориентир | Что обычно входит |
|---|---|---|
| Лендинг | 2–4 недели | Структура, дизайн, адаптив, форма, аналитика, запуск |
| Сайт компании | 6–12 недель | Шаблоны услуг, кейсы, CMS, SEO-основа, формы |
| Сайт-каталог | 6–12 недель | Категории, карточки, фильтры, CMS, импорт |
| Интернет-магазин | 8–16 недель | Каталог, корзина, оплата, доставка, админка |
| Личный кабинет | 10–20 недель | Роли, данные, документы, уведомления, API |
| Web-приложение | от 12 недель | Продуктовые сценарии, backend, роли, интеграции |
Из каких этапов складывается срок разработки
Разработка начинается не с отрисовки главной страницы. Команда должна понять задачу, определить сценарии, собрать структуру и зафиксировать, какой результат считается готовым. Чем раньше эти решения приняты, тем меньше переделок возникает в дизайне и коде.
Часть работ можно вести параллельно. Пока дизайнер собирает ключевые экраны, разработчик проверяет интеграции и модель данных, а редактор готовит контент. Параллельность ускоряет проект только при общей структуре и одном владельце решений.
- Бриф и discoveryЦель, аудитория, ограничения, контент, интеграции и критерии результата.
- Структура и прототипМаршруты пользователя, страницы, блоки, формы и состояния интерфейса.
- UX/UI-дизайнВизуальная система, ключевые экраны, адаптивы и компоненты.
- РазработкаFrontend, backend, CMS, роли, интеграции и техническая SEO-основа.
- ТестированиеФормы, сценарии, браузеры, мобильные устройства, скорость и доступность.
- ЗапускДомен, HTTPS, аналитика, sitemap, резервная копия и проверка на production.
Что сильнее всего влияет на срок
Количество страниц само по себе мало говорит о трудоёмкости. Пять уникальных продуктовых сценариев могут занять больше времени, чем сто страниц, собранных из трёх стабильных шаблонов. Для оценки важнее число уникальных состояний и правил.
Отдельно проверяют зависимости от внешних систем. Платёжный провайдер, CRM, 1С, служба доставки или закрытый API могут потребовать доступов, тестового контура и согласования со сторонней командой. Эти ожидания должны быть видны в графике.
- Количество уникальных шаблонов и интерактивных состояний.
- Готовность текстов, изображений, каталога и юридических документов.
- Наличие CMS, личного кабинета, ролей и административной панели.
- Интеграции с CRM, 1С, платежами, доставкой и аналитикой.
- Импорт и очистка данных со старого сайта или из таблиц.
- Число языков и особенности локализации.
- Требования к безопасности, нагрузке и отказоустойчивости.
- Количество лиц, принимающих решение, и время на обратную связь.
Почему даже небольшой сайт может задержаться
Самая частая причина задержки — не код, а неопределённость. Если после утверждения дизайна меняется оффер, структура или набор услуг, команде приходится возвращаться к уже завершённым этапам. Такая работа должна проходить через понятную процедуру изменения объёма.
Вторая причина — контент, который начинают собирать после готовности вёрстки. Реальные заголовки, фотографии, характеристики и документы влияют на композицию и сценарии. Заглушки удобны для старта, но до запуска нужен ответственный за каждую единицу контента.
Третья причина — интеграция, которую считали простой ссылкой. До оценки нужно проверить документацию, доступы, ограничения API, тестовую среду и поведение при ошибке.
Срок становится управляемым, когда у каждого этапа есть результат, ответственный, дата проверки и правило работы с новыми пожеланиями.
Как сократить срок без потери качества
Самый безопасный способ ускорить запуск — уменьшить объём первого релиза, а не убрать проектирование и тестирование. Сначала выпускают маршрут, который позволяет получить заявку, заказ или выполнить основную операцию. Остальные функции переходят в следующий релиз.
Готовая дизайн-система, согласованный контент и быстрый доступ к ответственному со стороны клиента также сокращают цикл. При этом нельзя экономить на проверке форм, мобильной версии, аналитики, резервного копирования и критичных интеграций.
- Зафиксировать одну бизнес-цель первого релиза.
- Отделить обязательные функции от улучшений следующей версии.
- Назначить одного владельца решений со стороны клиента.
- Собирать контент параллельно с прототипом, а не после вёрстки.
- Проверить сторонние API до финальной оценки.
- Показывать промежуточную версию каждую неделю.
- Запускать небольшими проверяемыми изменениями через тестовый контур.
Какие вводные нужны для точной оценки срока
Для первой оценки не требуется большое техническое задание. Достаточно описать цель, аудиторию, ключевое действие, обязательные разделы, интеграции, дедлайн и доступные материалы. Если есть старый сайт, таблица, презентация или запись процесса, приложите их.
После короткого разбора подрядчик должен вернуть не одну дату, а состав этапов, зависимости, контрольные точки и границу первого релиза. Такой план показывает, где срок фиксирован, а где зависит от контента или внешней стороны.
Посмотрите, как ХЭМС строит работу, на странице процесса проекта, а форматы запуска — в услуге веб-разработки.
FAQ
Частые вопросы
01Можно ли сделать лендинг за неделю?
Иногда да, если оффер и контент готовы, используется один визуальный маршрут, нет сложных интеграций, а решения принимаются быстро. Для нового продукта безопаснее заложить время на структуру, дизайн, адаптив и проверку формы.
02Сколько занимает только дизайн сайта?
Для небольшого сайта дизайн обычно занимает от одной до нескольких недель. Срок зависит от числа уникальных шаблонов, состояний, адаптивов, готовности контента и количества циклов согласования.
03Что быстрее: CMS, конструктор или индивидуальная разработка?
Конструктор быстрее для типового лендинга, CMS — для управляемого контентного сайта, индивидуальная разработка — для нестандартной логики. Быстрая платформа не компенсирует неясную структуру и неподготовленный контент.
04Можно ли вести дизайн и разработку параллельно?
Да, если утверждены структура, компоненты и приоритет экранов. Иначе параллельная работа создаёт переделки и не сокращает реальный срок.
05Когда можно назвать точную дату запуска?
После фиксации первого релиза, проверки интеграций, назначения ответственных и согласования графика контента. До этого корректнее давать диапазон и список допущений.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Получите график первого релиза
Разберём задачу, выделим обязательный результат и покажем этапы, зависимости и реалистичный срок запуска.