Сроки разработки сайта определяются не только количеством страниц и часов работы. Дата запуска зависит от того, какие результаты нужны для следующих задач, когда их можно получить и кто будет доступен для работы и проверки. Готовая вёрстка ещё не даёт дату запуска, если содержание не утверждено, заявки не доходят до сотрудника или нужный доступ остаётся у прежнего подрядчика.
Поэтому ответ на вопрос «сколько времени занимает создание сайта» должен содержать состав выпуска, календарь зависимых работ и условия, при которых расчёт остаётся верным. Ниже — способ читать такой план и управлять своей частью проекта. Последовательность производства подробно разобрана в статье об этапах разработки сайта; здесь важна связь между работами и датой.
Сначала договоритесь, что считается запуском
«Сайт сделан» может означать показ макетов, готовность тестовой версии или работу на основном домене. Для календарного плана нужен один понятный результат. Например: согласованные страницы опубликованы с окончательными материалами, обращение посетителя доходит в нужную систему, ответственный сотрудник может его обработать, а команда проверила этот путь после публикации. Для конкретного проекта набор условий будет своим.
Зафиксируйте и начало отсчёта. Если план начинается с готовых материалов и утверждённых макетов, подготовка этих результатов должна быть видна в отдельной части календаря. Нельзя сравнивать такой срок с предложением, которое включает их создание. Условия старта должны быть выполнимы и известны заранее.
Трудозатраты и календарная длительность — разные величины. Короткая проверка текста может ждать свободного руководителя несколько дней; две работы разных специалистов могут выполняться одновременно. Даты также зависят от выходных, праздников и доступности людей. Именно длительности, связи, ограничения и календари используются при расчёте графика, что показано в официальной документации Microsoft Project. Пользоваться этой программой для небольшого сайта необязательно: те же сведения можно хранить в таблице.
Попросите у исполнителя расчёт с реальной датой начала, рабочим календарём, ответственными и оговорёнными условиями готовности. Общее количество часов без этих сведений не объясняет, когда результат появится у бизнеса.
Какая цепочка определяет дату
У каждой зависимой задачи есть результат, без которого она не может начаться или завершиться. Финальную сборку страницы может блокировать решение по содержанию. Подключение передачи заявок — рабочий доступ к принимающей системе. Общую проверку — готовность обеих частей.
Критический путь — самая длинная последовательность связанных работ, определяющая раннюю дату завершения проекта. Задержка на ней сдвигает завершение, если команда не меняет план и не компенсирует задержку. У других работ может быть запас времени до влияния на общую дату. Эти понятия описаны в руководстве GAO по оценке графиков, разделы 6 и 7.
Здесь «критическая» не означает «самая сложная». В нашем учебном примере ниже решение по текстам занимает меньше времени, чем сборка, но обе работы находятся в одной цепочке до запуска. В другой конфигурации датой будет управлять получение внешнего доступа.
Запас некритической ветви относится к конкретному графику. Его нельзя раздать каждому участнику как независимое разрешение опоздать: задержки в одной цепочке используют один и тот же запас. Отдельно запланированное время на риски тоже должно быть видно в плане; это другая величина, а не свободное время внутри ветви.
Какие вводные нужно проверить до обещания даты
Материалы должны быть пригодны для конкретной работы
Фраза «контент есть» мало говорит о готовности. Фотографии могут лежать в папке без связи с услугами, описания — противоречить друг другу, условия предложения — ждать решения руководителя. В плане нужен результат: какой комплект, в каком виде, кем проверен и для каких страниц предназначен.
Для начала проектирования иногда достаточно согласованных примеров, показывающих разные случаи. Для наполнения всех страниц нужен полный комплект. Для публикации — подтверждённые сведения. Длинный заголовок, отсутствие фотографии или другой набор характеристик могут потребовать пересмотра уже собранного блока. Поэтому нужно заранее выяснить, какие свойства содержания влияют на макет, а какие материалы можно безопасно дополнять позже.
Подготовку можно распределить между сотрудниками бизнеса, редактором и исполнителем. В календаре должны быть видны и подготовка, и проверка, и исправление замечаний — с ответственным за каждый результат. Список исходных сведений поможет собрать бриф на разработку сайта, а состояние готовности каждого комплекта нужно уточнять отдельно.
Согласование требует решения, которое можно использовать дальше
Ответ «в целом нравится» не закрывает вопрос о составе страницы, тексте кнопки или обязательных полях обращения. Для зависимой работы нужен ответ по конкретной версии и перечню вопросов. Назначьте человека, который вправе его дать, и договоритесь, когда он получит материалы и когда сможет их проверить.
Если участвуют несколько подразделений, выясните, проверяют ли они документ одновременно или один ответ требуется до начала другой проверки. Руководитель проекта со стороны бизнеса может собрать замечания в один согласованный ответ, но полномочия на окончательное решение должны быть определены.
Подрядчик отвечает за своевременную передачу пригодного к проверке результата и понятных вопросов. Если показан неполный макет, не описаны состояния формы или противоречивы варианты, время на их исправление нельзя автоматически записать в задержку заказчика. План должен учитывать работу обеих сторон.
Доступ должен позволять выполнить нужное действие
Запись «доступ выдан» не подтверждает, что интеграцию можно проверить. Нужно убедиться, что приглашение принято, нужная роль работает, доступен подходящий контур и есть согласованные данные для проверки. Доступ к тестовой системе и возможность выполнить реальную операцию после запуска проверяют отдельно.
У внешней системы может быть собственный администратор или поставщик. Назовите этого участника, требуемый результат и срок ответа. Если его срок ещё неизвестен, отметьте это как открытую зависимость. Разработчик может проверить часть решения на тестовых данных, но план не должен считать внешнюю готовность подтверждённой только по такому показу.
Передавать пароли в календарной таблице не нужно. В ней достаточно указать, кто выдаёт доступ и как будет подтверждена его работоспособность; секреты передают согласованным защищённым способом с необходимыми правами.
Проверка должна оставаться частью срока
Проверки отдельных компонентов можно выполнять по мере готовности. Но итоговый путь посетителя требует совместно работающих страниц, реального содержания и интеграций. Если одна из частей ещё не готова, её проверку нельзя считать завершённой.
В календаре предусмотрите время для исправления обнаруженных ошибок и повторной проверки затронутого поведения. Для неопределённых участков обсуждайте отдельный резерв и основание его размера, а не произвольную одинаковую надбавку ко всему проекту. Также заранее согласуйте, кто участвует в приёмке и сможет проверить результат на основном домене. Исключение этих действий из плана приближает только нарисованную дату.
Что действительно можно делать параллельно
Параллельная работа возможна, если у задач есть достаточные стабильные вводные и исполнители, которые могут заниматься ими одновременно. Например, редактор готовит оставшиеся описания в утверждённой структуре, а разработчик собирает шаблоны по проверенным образцам. Другой специалист подключает передачу заявки, если состав полей и правила обработки уже согласованы.
Если один разработчик должен выполнить обе работы, две полосы на диаграмме ещё не означают одновременную готовность. Нужно проверить его загрузку. Если поля формы могут измениться после решения бизнеса, часть интеграции пока имеет неопределённый объём. Работа «на предположениях» требует явного решения о риске переделки и не должна незаметно становиться основой обещанной даты.
Открытый выбор платформы тоже нельзя спрятать за календарём уже оценённой реализации. Если он влияет на функции и интеграции, сначала нужно принять это решение; для обсуждения вариантов есть сравнение Laravel и готовой CMS.
В учебной схеме ниже две независимые ветви сходятся перед общей проверкой. Решение по готовым материалам позволяет завершить сборку страниц. Рабочие доступы позволяют выполнить интеграцию. Итоговая проверка ждёт обе ветви, а запуск — её результата. Это модель зависимостей конкретного примера, не обязательная схема каждого сайта.
Учебный календарь: как одно решение сдвигает запуск
Рассмотрим условный сайт услуг с передачей обращений в систему продаж. Состав выпуска, макеты и поля заявки уже утверждены. Тексты подготовлены, но владелец должен подтвердить окончательные формулировки. За сборку и интеграцию отвечают разные специалисты, их время зарезервировано. Домен и среда публикации готовы.
Все числа ниже выбраны только для объяснения расчёта. Это не оценка услуг Студии Вебирус и не норматив для похожего сайта. Шкала состоит из рабочих дней; задача начинается в следующий рабочий день после завершения своих предшественников. В этом сценарии проверки не обнаружили ошибок, требующих дополнительного цикла исправлений.
| Работа | Длительность в сценарии | Что требуется до начала | Исходный план | Если решение получено позже |
|---|---|---|---|---|
| Решение по готовым текстам | 2 рабочих дня по плану | Полный комплект на проверку | Дни 1–2 | Ответ получен в конце дня 5 |
| Финальная сборка страниц | 5 рабочих дней | Решение по текстам | Дни 3–7 | Дни 6–10 |
| Получение и проверка доступа | 3 рабочих дня | Согласованный запрос администратору | Дни 1–3 | Дни 1–3 |
| Интеграция передачи обращений | 3 рабочих дня | Рабочий доступ и утверждённые поля | Дни 4–6 | Дни 4–6 |
| Общая проверка и приёмка | 3 рабочих дня | Готовы сборка и интеграция | Дни 8–10 | Дни 11–13 |
| Публикация и проверка на домене | 1 рабочий день | Подтверждена готовность выпуска | День 11 | День 14 |
В исходном плане ветвь «решение → сборка» заканчивается в день 7, а ветвь «доступ → интеграция» — в день 6. Поэтому общая проверка начинается в день 8. Критический путь проходит через решение, сборку, общую проверку и публикацию: 2 + 5 + 3 + 1 = 11 рабочих дней. Длительности двух независимых ветвей не складывают последовательно.
Теперь окончательный ответ по текстам приходит в конце дня 5 вместо дня 2. Сборка смещается на дни 6–10, затем проверка — на дни 11–13, запуск — на день 14. Интеграция заканчивается в прежний день 6: она не ускоряет сборку и не компенсирует отсутствие решения. При заданных условиях три рабочих дня задержки на критической ветви дали три рабочих дня переноса запуска.
Задержка доступа в исходном плане повлияла бы иначе. Если доступ готов в конце дня 4 вместо дня 3, интеграция займёт дни 5–7; проверка всё ещё начнётся в день 8. Запас этой ветви исчерпан, но запуск остаётся в день 11. Если доступ появится лишь в конце дня 5, интеграция закончится в день 8, проверка пройдёт в дни 9–11, а запуск — в день 12. После изменения условий критический путь нужно определить заново.
Этот расчёт верен только при сохранении длительностей, доступности людей и остальных вводных. Если специалист после переноса уже занят другим проектом, потребуется учитывать ближайшее доступное время. Рабочие дни затем переводят в реальные даты по согласованному календарю. При пятидневной рабочей неделе с понедельника по пятницу, старте в понедельник и отсутствии праздников день 11 — понедельник третьей недели, а не одиннадцатая календарная дата от старта.
Как владельцу планировать свои действия
Попросите выделить из общего графика результаты, за которые отвечает ваша компания. Для каждого нужны ответственный, срок передачи, критерий готовности и следующая работа, которую он открывает. Формулировка «утвердить тексты услуг до конца дня 2, иначе сдвигается финальная сборка» позволяет действовать. «Ждём контент» оставляет слишком много неизвестного.
В учебном календаре действия бизнеса распределены так:
- До начала отсчёта — подтвердить, что команда действительно получила согласованные макеты, поля заявки и комплект текстов; договориться с администратором о доступе.
- К концу дня 2 — передать единое окончательное решение по текстам. Выделить время проверяющему заранее, а не искать его после напоминания.
- К концу дня 3 — получить подтверждение работоспособности доступа от специалиста, который будет выполнять интеграцию. Пересылка письма с приглашением не закрывает эту задачу.
- На дни 8–10 — обеспечить участие сотрудника, который принимает обращение в системе продаж, и человека, уполномоченного принять выпуск.
- На день 11 — обеспечить связь с ответственными за публикацию и обработку обращений для проверки после запуска.
Не обязательно выполнять всё лично. Важно, чтобы у каждого результата был владелец и возможность принять решение. Если человек уходит в отпуск или руководитель сможет посмотреть материалы только после командировки, это нужно сообщить при планировании, пока зависимые работы ещё можно переставить.
До ближайшего согласования уточняйте три вещи: что именно будет передано на проверку, достаточно ли этого для решения и кто будет доступен после ответа. Если срок уже под угрозой, просите обновить прогноз сразу. Ожидание окончательного опоздания лишает команду времени для изменения плана.
Как пересмотреть дату при изменении объёма
Новое пожелание нужно сначала связать с работами. Дополнительная информационная страница может использовать готовый шаблон, но требует содержания и проверки. Калькулятор услуги затрагивает правила расчёта, интерфейс, данные и сценарии ошибок. Название задачи само по себе не объясняет её влияние на срок.
Для пересмотра достаточно пройти пять последовательных действий:
- Зафиксировать изменение результата. Что добавляется в текущий выпуск, что заменяется, какие критерии готовности меняются. Не начинать зависимые работы с несколькими противоречащими версиями требований.
- Получить оценку затронутых работ. Учесть подготовку материалов, проектирование, реализацию, исправления и повторные проверки. Для уже начатой работы оценивать оставшийся объём с учётом сделанного.
- Обновить зависимости и доступность. Проверить необходимые решения, внешние ответы и время конкретных исполнителей. Не прибавлять одинаковую задержку ко всем задачам: независимые ветви могут сохранить свои даты.
- Пересчитать дату и найти управляющую цепочку. Проверить, какие работы теперь сходятся последними, сколько времени остаётся на проверку и какие вводные ещё не подтверждены. Если внешняя дата неизвестна, назвать её и показать, как прогноз зависит от ответа.
- Согласовать новый план. Сохранить исходную дату для сравнения, записать новый прогноз, причину изменения и обязательства сторон. Если дата события неизменна, рассмотреть другой состав первого выпуска и отдельно подтвердить, что он решает нужную задачу бизнеса.
Сокращать выпуск можно за счёт согласованных необязательных функций или страниц. Исключать проверку обязательного сценария ради прежней даты нельзя. Если новый результат не помещается в доступное время, выбор между переносом даты и пересмотром состава должен быть сделан явно.
Так же разбирают отставание без изменения объёма. Попросите показать конкретный незавершённый результат, когда он был нужен, что фактически произошло и какие работы это затронуло. Различайте позднее решение бизнеса, неготовый результат подрядчика и внешний ответ; при нескольких причинах учитывайте каждую. После разбора нужен выполнимый план оставшейся работы. Общая фраза «всё из-за согласований» не заменяет этих сведений.
Если обсуждаете разработку сайта под ключ, принесите дату бизнес-события, перечень обязательных функций и сведения о готовности материалов. Попросите связать предложение с этими вводными и назвать открытые зависимости. Согласуйте порядок взаимодействия и календарь конкретного проекта с учётом его объёма, необходимых решений и доступности исполнителей.
