Срок разработки сайта зависит не только от числа страниц. Для календарного плана нужны согласованный состав результата, готовность материалов, доступность участников и условия работы связанных систем. Пока это неизвестно, дата запуска остаётся предположением с условиями, а не подтверждённым обязательством.
В этой статье нет универсального обещания «сайт за определённое число дней». Вместо него — способ разобраться в оценке подрядчика и собрать план, который показывает зависимости. Рабочий результат: этапы, условия входа, критерии завершения, ответственные и открытые вопросы.
Сначала определите, что считается запуском
Внешне готовая главная, демонстрация на тестовом адресе и работающий публичный сайт — разные результаты. Если в проект входят CMS, каталог, приём заявок и несколько языков, уточните, какие из этих частей должны работать в первом выпуске.
Запишите минимальный состав запуска и то, что может выйти позже по отдельному решению. Для компании, готовящейся к выставке, таким составом может быть информация об услугах и рабочий способ обращения. Но это лишь учебный пример: сокращённый выпуск не подходит автоматически любому бизнесу.
Не исключайте из понятия «готово» проверку формы, наполнение и передачу доступов. Состав работ удобно сверить с техническим заданием и структурой сметы: три документа должны описывать один результат.
Различайте трудозатраты и календарь
Оценка работы специалиста не равна времени от старта до выпуска. Календарь включает ожидание материалов и решений, согласованные окна проверки, доступность ответственных и последовательность задач. Уточняйте, что означает единица в предложении: рабочий день, календарный день или объём труда.
Параллельная работа сокращает календарь только там, где задачи достаточно независимы и есть ресурсы. Если структура ещё меняется, одновременное наполнение всех страниц может привести к переделке. Если один человек принимает несколько результатов, согласования тоже могут образовать очередь.
Попросите показывать отдельно оценку исполнения, ожидания и допущения. Запись «работа начинается после согласования структуры» должна ссылаться на понятный критерий согласования, а не оставлять момент старта на усмотрение участников.
Постройте схему зависимостей
Ниже — упрощённая учебная схема корпоративного сайта. Буквы обозначают результаты, а стрелки — необходимые предшествующие решения. Это не описание фактических сроков или состава проекта CoreWeb.
A → B → C → E → F
↘ D ───↗
- A — исходные условия: задача бизнеса, аудитория и границы первого выпуска.
- B — структура и сценарии: назначение страниц, действия посетителя и модель содержания.
- C — согласованные решения интерфейса: шаблоны, состояния и адаптация.
- D — материалы и условия интеграций: подготовленное наполнение, поля данных, тестовые доступы и ответственные.
- E — сборка согласованного выпуска: интерфейс, CMS, данные и взаимодействие систем.
- F — проверка, переключение и передача: подтверждённые сценарии, условия выпуска и доступы.
В этой схеме C и D могут идти параллельно после B, но E зависит от обеих веток. В реальном проекте разработка отдельных согласованных частей может начаться раньше. Тогда разбейте E на конкретные результаты и покажите, какие входные данные нужны каждому. Не называйте весь этап независимым только потому, что часть кода уже можно написать.
Если задержалась ветка D, сокращение времени дизайна не обязательно приблизит выпуск. Ищите зависимость, которая фактически удерживает следующую задачу, а не самый заметный незавершённый этап.
Заполните календарный план
| Этап | Что нужно на входе | Что подтверждает завершение | Что занести в календарь |
|---|---|---|---|
| Постановка задачи | Контекст компании и доступные исходные данные | Границы выпуска и открытые вопросы | Встреча и срок решений |
| Структура и сценарии | Задачи аудиторий и перечень предложения | Карта страниц и основные действия | Проверка структуры |
| Дизайн | Согласованные шаблоны и образцы содержания | Макеты и состояния по критериям проекта | Окна обратной связи |
| Контент и интеграции | Владельцы материалов и систем | Готовые данные и проверенные условия подключения | Поставки материалов и доступов |
| Разработка и наполнение | Согласованные решения для конкретной части | Рабочие сценарии на тестовом контуре | Демонстрации и проверка результатов |
| Приёмка и запуск | Наполненный выпуск и план переключения | Проверки пройдены, результат передан | Приёмка, исправления и окно запуска |
Для каждой строки добавьте начало, окончание, ответственного, предшествующий результат и основание оценки. Разделите плановую дату и фактическую. Не заполняйте неизвестную дату случайным значением: сначала запишите вопрос и того, кто должен дать ответ.
Готовность материалов удобно вести в отдельном реестре контента. Из календаря должна быть видна связь с ним: какая страница или группа карточек нужна к конкретной демонстрации. Одной строки «заказчик предоставляет тексты» недостаточно для планирования многостраничного сайта.
Согласуйте правила обратной связи
Определите, кто собирает комментарии и кто принимает решение. Предусмотрите срок ответа и порядок работы с противоречивыми замечаниями. Молчание не стоит автоматически считать согласованием, если такой порядок явно не установлен участниками проекта.
Для каждого показа сообщайте, что именно обсуждается. На проверке структуры важны назначение страниц и маршруты, на проверке формы — поля и состояния. Комментарий о новой услуге может менять состав проекта, а ошибка в согласованном поле требует исправления. Эти случаи должны по-разному отражаться в плане.
Фиксируйте решение и версию результата, к которой оно относится. Если несколько участников присылают разрозненные правки к разным версиям, календарь перестаёт отражать реальный объём согласования.
Найдите внешние зависимости и резерв
CMS и интеграции добавляют не только разработку. Понадобятся описание данных, доступ к тестовой системе, контакт ответственного и способ проверить результат. Запрос доступа в последний день не превращает систему в готовую к подключению.
Для зависимости запишите последствие задержки. Можно ли продолжить работу с согласованными тестовыми данными? Что останется неподтверждённым до получения доступа? Демонстрация на заглушке может помочь проверить интерфейс, но не закрывает готовность реальной интеграции.
Резерв планируют под конкретную неопределённость: дополнительную сверку импорта, исправления после приёмки или согласование содержания. Универсальный процент без связи с риском мало объясняет заказчику. Укажите, на что рассчитан резерв, кто принимает решение о его использовании и что происходит, если причина выходит за рамки допущения.
Что делать, если дата уже зафиксирована
Сначала выясните причину: выставка, договорённость с партнёром, рекламный запуск или внутренний ориентир. Затем сопоставьте дату с зависимостями и доступными ресурсами. Не подменяйте этот разбор обещанием «ускориться».
Учебный пример: до показа компании не готовы фотографии всей продукции. Возможные решения — организовать подготовку приоритетных материалов, согласовать меньший первый выпуск или перенести показ. У каждого решения есть ограничения. Публикация пустых карточек или выдуманных характеристик не решает задачу готовности.
Если состав сокращается, перепишите перечень первого выпуска, критерии приёмки и последующий этап. Заказчик должен понимать, какой результат будет получен к дате и что останется сделать после неё.
Как обновлять план по ходу проекта
При изменении зафиксируйте запрос, причину, затронутые результаты и влияние на даты. Если нужен выбор, подготовьте варианты с последствиями для состава и последовательности. Новую дату отмечайте как согласованную только после решения ответственных.
На рабочей встрече полезны четыре вопроса: что завершено с доказательствами, что удерживает следующий этап, какое решение требуется и как изменился прогноз выпуска. Процент «почти готово» не заменяет ответы, если каталог ещё не наполнен или доставка заявки не проверена.
Для подготовки к обсуждению заполните реестр исходных ограничений. В CoreWeb можно обсудить состав сайта под ключ: текущие материалы, CMS, интеграции и причину желаемой даты. По этим данным можно перейти к предметной оценке, а не обещанию срока без известного объёма.
Для отдельного запроса используйте порядок управления изменениями: оцените влияние и обновите согласованную версию плана.