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