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

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

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

Содержание

• что подготовить до обращения;
• чем бриф отличается от ТЗ;
• как сравнивать сметы;
• что закрепить в договоре;
• кому должны принадлежать код и аккаунты;
• как организовать этапы и изменения;
• как провести приёмку и запуск.

Начните с результата бизнеса

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

Хорошая цель содержит:

• аудиторию и её ситуацию;
• ожидаемое действие на сайте;
• способ привлечения посетителей;
• ограничение первой версии;
• способ проверить результат.

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

Что положить в первый бриф

Для содержательного разговора достаточно короткого документа или письма:

1. чем занимается компания и что продаёт;
2. кто выбирает и кто согласует покупку;
3. какие задачи должен выполнить посетитель;
4. какие страницы или разделы предполагаются;
5. откуда возьмутся тексты, фото и юридические материалы;
6. какие системы нужно подключить;
7. какие сайты нравятся и почему;
8. какие сроки связаны с реальным событием;
9. кто со стороны заказчика принимает решения;
10. что будет считаться готовым результатом.

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

Бриф, прототип и ТЗ решают разные задачи

• Бриф. Помогает понять, зачем нужен проект и в каких условиях. Этот документ готовят до оценки.
• Карта страниц. Помогает понять, какой контент и маршруты входят. Этот документ готовят после уточнения цели.
• Прототип. Помогает понять, как пользователь проходит сценарий. Этот документ готовят до детального дизайна.
• ТЗ. Помогает понять, как система должна вести себя в состояниях. Этот документ готовят до разработки сложной логики.
• План приёмки. Помогает понять, как доказать готовность. Этот документ готовят до начала реализации.

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

ТЗ не должно диктовать технологию без причины. Требование «использовать конкретную библиотеку» имеет смысл, если у заказчика есть команда или инфраструктурный стандарт. В остальных случаях полезнее описать нагрузку, безопасность, поддержку и право переносить проект.

Как выбрать формат сайта

Перед сметой решите, какой формат закрывает первую задачу:

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

Не превращайте лендинг в дешёвый корпоративный сайт, добавляя всё новые разделы. И не заказывайте кабинет, если реальный процесс первое время надёжнее обрабатывает менеджер. Матрица выбора есть в статье о форматах сайта для бизнеса.

Как читать смету

Сравнивать только итоговую сумму нельзя. В предложении должны быть видны:

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

На текущем публичном прайсе Za IT базовый лендинг стоит 4 999 ₽, корпоративный сайт — 19 999 ₽, интернет-магазин — 29 999 ₽. Эти суммы относятся к ограниченному базовому составу. Нестандартная инженерная работа может оцениваться по 2 999 ₽/час или отдельным этапом после диагностики.

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

Что зафиксировать в договоре

Договор должен связывать юридические условия с реальным процессом. В нём или приложениях фиксируют:

1. предмет и состав результата;
2. этапы, стоимость и порядок оплаты;
3. входные материалы и сроки их передачи;
4. порядок согласования и число итераций;
5. способ постановки дополнительных задач;
6. критерии приёмки и срок проверки;
7. устранение ошибок согласованного объёма;
8. права на код, дизайн и контент;
9. конфиденциальность и работу с данными;
10. порядок остановки и передачи незавершённого проекта.

Фраза «любые пожелания заказчика входят в стоимость» не защищает ни одну сторону. Новые идеи оценивают через change request: что меняется, сколько требуется времени, какой этап и срок затронуты. Заказчик видит цену решения, а команда не прячет доплаты.

Права и лицензии

До старта выясните, что именно передаётся после оплаты:

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

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

Аккаунты и доступы принадлежат бизнесу

Домен, хостинг, облако, аналитика, CMS, почта и платёжный сервис должны оформляться на контролируемые компанией аккаунты. Исполнитель получает роль с минимально достаточными правами.

Безопасный порядок:

1. создать корпоративный аккаунт владельца;
2. включить двухфакторную защиту;
3. пригласить исполнителя отдельной учётной записью;
4. передавать секреты через согласованный защищённый канал;
5. вести список выданных прав;
6. после завершения отозвать лишние доступы и сменить общие секреты.

Не отправляйте пароли в форму заявки, обычный чат или task-файл. Для диагностики часто достаточно временного доступа без права менять оплату и владельца.

Этапы проекта и контрольные точки

Последовательность зависит от формата, но обычно выглядит так:

1. Обследование

Команда уточняет цель, процессы, контент, интеграции и риски. Результат — состав первой версии и список вопросов, которые ещё нельзя оценить.

2. Структура и прототип

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

3. Контент и дизайн

Реальные заголовки, объём текста и изображения проверяются в интерфейсе. Макет включает мобильное поведение, формы, ошибки, меню и повторяющиеся компоненты.

4. Разработка и интеграции

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

5. Наполнение и проверка

Контент переносится в CMS, формы проходят полный путь, аналитика проверяется по факту события. Исправляются дефекты согласованного объёма.

6. Публикация и наблюдение

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

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

Как управлять сроком

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

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

Приёмка: проверяйте сценарий, а не скриншот

Критерий «соответствует макету» недостаточен. Готовый сайт должен работать в реальном окружении.

Минимальный чек-лист:

1. все согласованные URL открываются с корректным статусом;
2. навигация, кнопки и ссылки ведут туда, куда обещают;
3. интерфейс проверен на мобильном и desktop;
4. формы валидируют данные и доставляют тестовое обращение;
5. успешные действия фиксируются аналитикой без персональных данных;
6. редактор может изменить предусмотренный контент;
7. title, description, canonical, sitemap и robots согласованы;
8. изображения оптимизированы, а критические страницы не имеют явных ошибок;
9. редиректы со старых адресов проверены;
10. резервная копия и процедура восстановления описаны;
11. аккаунты, код, макеты и инструкции переданы;
12. известные ограничения записаны, а не скрыты.

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

Что делать после запуска

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

Поддержка может быть разовой или регулярной. Публичный пакет Za IT для сайта стоит 9 999 ₽ в месяц и включает до четырёх часов работ, мониторинг, резервные копии и обновления. Более крупные изменения оцениваются отдельно. Условия и ответственность разбираются в статье о стоимости сопровождения.

Практический пример выбора

Компания продаёт четыре B2B-услуги, имеет кейсы и планирует статьи. Лендинг дешевле, но вынудит смешать разные интенты на одной странице. Корпоративный формат до десяти типовых страниц за 19 999 ₽ лучше соответствует структуре, если контент готов и нет кабинета.

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

Следующий шаг

Соберите цель, аудиторию, примерный список страниц, материалы, интеграции и критерии готовности. На странице разработки сайтов под ключ можно сравнить форматы и отправить вводные без готового ТЗ.

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