Название этапа не отвечает ни на один из этих вопросов. «Разработка» может означать сборку утверждённых макетов, а может включать настройку форм, событий и перенос материалов. «Дизайн» иногда охватывает только несколько ключевых экранов. Всё остальное команда достраивает по ходу и каждый участник понимает границу по-своему.
До подписи полезно проверить не количество строк в смете, а три вещи по каждой области: какой результат должен остаться на руках, кто за него отвечает и по каким признакам его принимают. Такой разговор не делает предложение длиннее ради порядка. Он показывает места, где стоимость, решение или ответственность пока спрятаны между строками.
Начните с коммерческой задачи и списка страниц
Фраза «сделать корпоративный сайт» слишком широка для рабочего решения. Сначала зафиксируйте, что должен объяснить сайт и к какому следующему действию он ведёт человека. Для одного проекта ключевым действием будет отправка формы. Для другого - звонок, запись, запрос расчёта или переход к выбору филиала. Так в проекте появляется конкретная роль сайта в пути покупателя.
После этого нужен перечень страниц. Не только пункты верхнего меню, но и служебные и информационные страницы, страницы подтверждения, ошибки, материалы блога и посадочные, которые должны сохраниться. Рядом с каждой страницей стоит указать её задачу, основное действие и источник фактов. Если перечень ещё меняется, в предложении нужен понятный порядок изменения: кто предлагает новую страницу, кто оценивает работу и кто утверждает добавление.
Список страниц помогает заранее увидеть расхождение: одну и ту же работу стороны считают включённой или отдельной. Он также показывает, какие решения пока не приняты. Пустая строка лучше уверенного предположения: её можно обсудить до начала работы.
Кто отвечает за факты, черновик и финальное согласование
Текст сайта редко рождается из одного интервью. Нужны сведения об услугах, условиях, географии, ограничениях, процессе обращения и основаниях для публичных утверждений. Эти факты обычно находятся у разных людей: собственника, маркетинга, продаж, продукта, филиалов. Подрядчик не может достоверно восстановить их по старой странице или презентации, если компания сама не подтвердила содержание.
В составе проекта должно быть видно, кто передаёт факты, кто готовит черновик, кто проверяет точность и кто принимает финальную версию. Отдельно договоритесь, что происходит с фразой, для которой нет подтверждения. Её убирают, смягчают или оставляют на согласование, но не заполняют догадкой.
Уточните и объём редакционной работы. Одно дело - расставить готовый текст в макете. Другое - провести интервью, собрать структуру, написать страницы и провести несколько кругов правок. Слово «копирайтинг» этой разницы не раскрывает. Нужен наблюдаемый результат: какие страницы получают текст, в каком виде он передаётся и кто ставит финальное «принято».
Проверьте состояния сайта, которых нет в макете
На презентации обычно показывают идеальную страницу с заполненными карточками и ровными заголовками. Живой сайт ведёт себя сложнее. У меню есть открытое состояние. У формы - ошибка, отправка и подтверждение. У списка может не быть элементов. Длинное название услуги переносится на новую строку. На телефоне таблица, кнопка или всплывающее окно занимают другое место.
Поэтому результат дизайна и разработки стоит описывать через общие элементы и их состояния: шапка, подвал, навигация, кнопки, формы, карточки, списки, сообщения об ошибке. Не обязательно перечислять каждую мелочь в коммерческом предложении. Достаточно определить набор повторяющихся элементов, важные состояния и место, где они собраны для проверки.
«Есть мобильная версия» тоже недостаточно. Для приёмки нужны конкретные действия на согласованных размерах экрана: открыть меню, прочитать первый экран, нажать основную кнопку, заполнить поля, увидеть ошибку и получить подтверждение. Исполнитель показывает собранную страницу, ответственный со стороны компании проходит сценарии и фиксирует замечания в одном согласованном месте.
Определите, что делать со старыми адресами до выпуска
Если действующий сайт уже получает переходы, старые страницы нельзя считать просто архивом. До выпуска нужно решить, какие адреса сохраняются, какие получают новое место, какие снимаются и кто проверяет результат после публикации. В составе проекта достаточно закрепить саму ответственность за список адресов, решения по ним и проверку.
Технический порядок переезда, перенаправления и поисковые проверки раскрыты в отдельном материале о переносе сайта с Tilda на custom. Здесь не нужно переписывать его в предложение целиком. Но формулировка «SEO включено» не заменяет ответ на четыре вопроса: кто готовит список старых страниц, кто назначает новое место, кто внедряет решения и кто проверяет живой сайт.
Если такой карты ещё нет, область нельзя автоматически считать включённой в разработку. Её надо оценить отдельно или явно оставить за командой клиента.
Зафиксируйте путь формы до места хранения
Форма - это не только поля и кнопка. Человек должен увидеть понятную ошибку при неверном вводе и однозначное подтверждение после отправки. Команда должна знать, куда сохраняется обращение и кто получает уведомление. Для аналитики заранее определяют нужные события. Имя, телефон, email, название компании и текст сообщения не передают в URL, UTM-метки и параметры событий. Эта граница сама по себе не подтверждает юридическое соответствие всей системы.
До договора разделите зоны ответственности: кто проектирует поля и тексты, кто собирает форму, кто настраивает сохранение и уведомление, кто добавляет события и кто выполняет контрольную отправку. Если подключение внешней CRM не входит в проект, это следует написать прямо, указав фактическую точку, на которой заканчивается работа.
Пошаговую проверку передачи обращения не стоит встраивать в эту статью. Для неё есть чеклист маршрута формы до CRM. В составе проекта нужен более ранний ответ: какой маршрут обещан, где лежит заявка после отправки и кто подтверждает, что согласованный участок работает.
Договоритесь о правках, передаче и выпуске
Фраза «правки включены» оставляет слишком много пространства для разных ожиданий. До начала работы определите, как команда передаёт замечания, кто объединяет противоречивые комментарии и где проходит граница между исправлением несоответствия и новой задачей. Не нужно придумывать универсальное число кругов или дней. Правило должно соответствовать конкретному предложению и способу работы сторон.
Приёмка не заканчивается утверждением макета. Перед выпуском нужен список критичных сценариев: страницы открываются, навигация ведёт по нужным адресам, формы дают ожидаемые состояния, события фиксируются, старые маршруты обработаны. У каждого пункта есть проверяющий. Замечание получает владельца и решение: исправить до публикации, принять осознанно или убрать спорную функцию из выпуска.
Отдельно перечислите материалы, которые передаются компании: тексты, исходники дизайна, доступы, инструкции по обновлению, список подключений и актуальная версия проекта. Конкретный набор зависит от технологии и договорённости. Нельзя считать, что слово «сайт» автоматически включает все исходные файлы и любые сторонние аккаунты.
После публикации команда проходит короткую проверку уже на живом адресе. В предложении также нужен ответ на случай критичной поломки: кто принимает решение и как вернуть последнюю рабочую версию. Это не обещание безошибочного выпуска. Это заранее назначенная ответственность, когда ошибка мешает человеку открыть важную страницу или отправить обращение.
Чеклист состава проекта
Скопируйте таблицу в рабочий документ и проходите её вместе с предложением подрядчика: изменения в полях на этой странице не сохраняются. В рабочей копии добавьте к каждой области статус: «входит», «не входит» или «не определено». Формулировки во второй и четвёртой колонках служат вопросами для сверки; замените их решением для конкретного проекта. В колонке «Кто отвечает» замените тире ролью или именем участника с каждой стороны. Способ приёмки должен описывать наблюдаемую проверку.
| Область | Что должно быть определено | Кто отвечает | Как принимается |
|---|---|---|---|
| Коммерческая задача и страницы | роль сайта, основное действие, перечень страниц и порядок добавления новых | - | согласован список страниц с задачей и действием для каждой |
| Факты и тексты | источники фактов, автор черновика, проверяющий точность и утверждающий | - | у каждой страницы есть принятый текст без неподтверждённых утверждений |
| Дизайн и общие элементы | набор ключевых экранов, повторяющиеся элементы и важные состояния | - | элементы показаны на собранных страницах в согласованных состояниях |
| Мобильная версия | страницы, размеры экранов и критичные действия для проверки | - | проверяющий проходит согласованные сценарии на телефоне |
| Старые адреса | какие страницы сохраняются, получают новый адрес или снимаются | - | решения внедрены и проверены на живом сайте ответственным |
| Формы и аналитика | поля, ошибки, подтверждение, место хранения, уведомление и события | - | выполнена контрольная отправка, результат сверён на каждом включённом шаге |
| Правки и приёмка | канал замечаний, владелец общего ответа, граница исправления и новой задачи | - | замечания сведены в один список и по каждому принято решение |
| Границы, зависимости и внешние расходы | что не входит, что предоставляет клиент, от каких согласований зависит работа, какие сервисы, лицензии, домен, хостинг и поддержка после выпуска оцениваются отдельно | - | исключения, зависимости, внешние расходы и граница поддержки перечислены прямо |
| Передача и выпуск | передаваемые материалы, доступы, проверка после публикации и способ возврата рабочей версии | - | комплект передан; на живом сайте пройдены согласованные сценарии; для критичной поломки указан владелец решения и способ возврата |
Заменяет ли чеклист договор?
Нет. Это рабочий список вопросов к составу проекта, а не юридическая консультация и не шаблон условий. Он помогает заметить неопределённые результаты и роли до подписи. Как закрепить договорённости в документах, стороны решают со своими ответственными специалистами.
Кто должен заполнять чеклист?
Лучше пройти его вместе: владелец решения со стороны компании и человек, который отвечает за предложение со стороны подрядчика. Маркетинг уточняет задачу и материалы, технический участник проверяет сборку и подключения, собственник или назначенный руководитель принимает спорные границы. Один человек может совмещать роли, но сама ответственность всё равно должна быть названа.
Насколько подробно описывать результат?
До уровня, на котором другой участник сможет принять работу без догадки. Не нужен многотомный документ о каждом отступе. Нужны конкретные страницы, действия, состояния и способы проверки там, где ошибка меняет стоимость, срок обсуждения или работу сайта. Чем выше риск расхождения ожиданий, тем точнее должна быть строка.
Когда нужен аудит действующего сайта?
Когда предложение предполагает заметную пересборку, а команда не знает, какие страницы получают переходы, какие формы используются, где хранятся обращения и что нельзя потерять при выпуске. Аудит также уместен, если разные участники дают несовместимые ответы о текущем сайте. Сначала фиксируют факты и работающие маршруты, затем решают, что переносить, менять или убирать.
Самостоятельная проверка может показать пустые зоны в предложении. Но она не заменит разбор самого сайта, если список страниц, форм и старых адресов неизвестен. В такой ситуации можно обсудить состав проекта до договора: сопоставить предложение с текущим сайтом и назвать вопросы, которые нужно закрыть до начала работ. О том, как UpMarketing подходит к пересборке и выпуску, читайте на странице разработки сайтов.