Сроки разработки корпоративного сайта: этапы, зависимости и контроль результата

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

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

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

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

На срок влияют:

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

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

Отдельно стоит учитывать ограничения. Часть работ нельзя начать раньше другой: дизайн не начинается без утверждённой структуры, вёрстка — без макетов, наполнение — без шаблонов. Требует экспертной проверки. Эти связи и есть предмет карты зависимостей.

Карта зависимостей: как увидеть, где встанет проект

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

Для каждой работы фиксируют:

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

Как заполнять карту

Начинайте не с календаря, а с перечня работ. Затем для каждой работы задайте вопрос: «Что должно существовать, чтобы эту работу можно было начать и закончить?» Ответы становятся связями. Если ответ «нужно решение заказчика», у связи появляется владелец и срок.

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

Как читать карту

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

Что делать с работами вне критического пути

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

Состав работ: что именно оценивается

Оценка опирается на состав работ, а не на общее пожелание «сделать сайт». Чем конкретнее перечень, тем меньше разброс.

Проектирование и техническое задание

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

Дизайн и шаблоны страниц

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

Стоит заранее договориться о числе раундов правок и о том, что считается новой задачей. Иначе обсуждение макета может идти по кругу, а срок — расти без изменения объёма.

Сборка, наполнение и внедрение

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

Внедрение — не формальность. Это отдельная работа с собственными зависимостями: нужны доступы, настроенные разделы, проверенные формы и понятный порядок действий при сбое. Требует экспертной проверки.

Контент и согласования: где теряются недели

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

Что помогает:

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

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

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

Внешние системы, доступы и данные

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

Что подготовить до старта:

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

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

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

Промежуточные результаты контроля

Длинный проект без промежуточных проверок рискует тем, что расхождения обнаружатся в конце. Требует экспертной проверки. Поэтому каждый этап заканчивается результатом, который можно посмотреть и принять.

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

На каждом шаге полезно фиксировать, что именно принято. Это снижает риск возврата к уже закрытым вопросам и делает обсуждение сроков предметным: видно, какая работа закрыта, а какая ждёт входных данных.

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

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

Входные условия. Условная компания заказывает корпоративный сайт: пять разделов, каталог услуг с разделами и подразделами, форма заявки, новости, связь с CRM. Контент готов примерно наполовину: есть тексты о компании и услугах, нет фотографий и части описаний. Доступ к CRM обещан, тестового контура нет. Решение принимают два руководителя.

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

Развилки, которые видно на карте:

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

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

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

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

Приёмка — это не «посмотреть сайт». Это сверка с тем, что было согласовано. Требует экспертной проверки.

• Структура совпадает с утверждённой картой разделов.
• Шаблоны соответствуют макетам, отклонения перечислены и объяснены.
• Формы отправляют данные и сохраняют их в системе управления.
• Разделы и меню редактируются без разработчика.
• Отображение проверено в браузерах, указанных в договоре.
• Внешние связи работают на тестовых данных, ограничения описаны.
• Есть доступы и понятный порядок восстановления. О подготовке копий — в материале про Резервное копирование сайта на Битрикс — хранение и восстановление.

Если сайт уже существует и его нужно оценить перед доработкой, помогает аудит сайта на Битрикс: он показывает состояние текущей реализации и объём работ.

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

• Оценивать «сайт целиком» без перечня шаблонов и модулей. Из-за этого оценка расходится с реальностью уже на первом этапе.
• Считать, что контент появится сам, и не назначать ответственного. Материалы приходят в последний момент и сдвигают наполнение.
• Начинать дизайн до утверждения структуры. Позже структура меняется, и макеты приходится переделывать.
• Планировать интеграции без тестового контура и без описания обмена. Проверка превращается в поиск причин расхождений.
• Собирать замечания из переписки, теряя часть из них. Правки возвращаются на этапе приёмки.
• Принимать работу по общему впечатлению, а не по списку. Спорные пункты всплывают после запуска.
• Забывать про ограничения: часть работ физически нельзя ускорить, не сократив объём.

Ограничения стоит проговаривать заранее. Если сроки жёсткие, обсуждают не «ускорение», а сокращение объёма: какие разделы и модули войдут в первую версию, а какие — во вторую. Это честнее, чем обещать сжатые сроки на неизменный объём. Требует экспертной проверки.

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

Чтобы оценка была предметной, подготовьте:

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

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

Чек-лист перед стартом

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