Как определить срок разработки сайта и заложить резерв

Сначала определите, что должно заработать к назначенной дате

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

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

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

Соберите сведения, без которых оценка будет предварительной

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

Передайте список функций, примеры исходных материалов и описание существующих систем. Для каталога полезнее реальный обезличенный файл с несколькими сложными товарами, чем обещание «потом выгрузим из 1С». Для формы — набор полей и нужная карточка CRM. Для переноса — перечень старых адресов и решение, какие разделы должны сохраниться.

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

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

Попросите план с результатами этапов и зависимостями

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

Формулировка «дизайн — пять дней» скрывает важную часть работы. Уточните, что будет передано: главная страница, шаблон услуги, мобильные состояния, ошибки формы. Добавьте время на проверку и исправления. В руководстве GOV.UK по пользовательским историям задачи связывают с потребностью человека и критериями приёмки. Для небольшого коммерческого сайта этот подход удобно применять в сокращённом виде — одной-двумя фразами на результат.

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

Проверьте, есть ли у команды работа на случай задержки согласования. Параллельно можно готовить тексты или тестовые данные, но только если их не придётся переделывать после изменения структуры. Фраза «будем делать всё сразу» должна сопровождаться объяснением, какие решения уже устойчивы и какие риски команда принимает.

Отделяйте трудозатраты от календарного срока

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

Рассмотрим условный пример без праздников и отпусков. Подготовка структуры занимает три рабочих дня. После неё дизайн занимает пять, а подготовка материалов — семь дней; эти две работы идут параллельно. Сборка длится восемь дней и начинается после завершения обеих. Затем приёмка и исправления занимают четыре дня. До резерва получается 3 + 7 + 8 + 4 = 22 рабочих дня, а не сумма всех строк 27.

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

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

Заложите резерв под названные риски

Резерв должен объясняться неопределённостью проекта. У старого сайта может оказаться неполная выгрузка, у каталога — разные форматы характеристик, у стороннего сервиса — задержка выдачи доступа. Попросите перечислить несколько наиболее вероятных препятствий и действия при их появлении. Фиксированный процент «на всякий случай» не заменяет такого разговора.

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

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

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

Сделайте согласования частью проекта

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

Заранее договоритесь, сколько времени есть на просмотр результата, как выглядит ответ и что считается утверждением. Молчание само по себе не следует трактовать как согласие, если такой порядок явно не согласован. Для руководителя, который редко открывает систему задач, можно назначить короткие встречи по контрольным точкам и заранее выдавать материалы.

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

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

Что делать, когда срок начинает сдвигаться

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

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

Учитывайте последствия сокращения объёма. Если убрать личный кабинет, останется ли способ обслужить покупателя? Если временно отказаться от обмена, кто будет вручную обновлять остатки и сколько это займёт? Временное решение допустимо, когда назначены ответственный и срок его пересмотра. Иначе экономия нескольких дней разработки создаст постоянную ручную нагрузку.

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

Оставьте время на приёмку и проверку опубликованного сайта

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

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

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

Для согласования срока достаточно одного компактного пакета: состав первого выпуска, этапы с результатами, календарь участников, риски, правила изменений и сценарии приёмки. Если смета и график описывают разный объём, верните их на уточнение. Подготовить исходные требования поможет ТЗ на сайт; обсудить реализацию можно через услуги ШТАБ ИТ.