Для разработки сайта обычно нужны договор с приложениями, бриф, техническое задание, смета или спецификация, календарный план, прототипы, дизайн-макеты, требования к контенту, документы по тестированию и приёмке, а также перечень передаваемых доступов и прав. Точный комплект зависит от масштаба проекта, способа оплаты, состава команды, выбранной CMS и требований к будущему сайту.
В статье разберём, какие документы нужны при разработке веб-сайта на каждом этапе, кто их готовит и что необходимо проверить перед согласованием. В конце — компактный чек-лист, который поможет заказчику снизить риск споров, задержек и неполной передачи проекта.
Карта документов по этапам разработки
Документы в веб-разработке выполняют несколько разных задач: фиксируют договорённости, описывают результат, распределяют ответственность и помогают принять работу. Не каждый проект требует десятков отдельных файлов. Часть условий можно объединить в договоре, техническом задании или единой базе знаний.
| Этап | Основные документы | Что фиксируют |
|---|---|---|
| Подготовка | Бриф, коммерческое предложение, смета | Цели, состав работ, предварительную стоимость и ограничения |
| Оформление отношений | Договор, приложения, соглашение о конфиденциальности | Обязанности сторон, оплату, сроки, права и порядок приёмки |
| Проектирование | Техническое задание, структура, пользовательские сценарии, прототипы | Функции сайта, состав страниц и логику взаимодействия |
| Дизайн и контент | Дизайн-макеты, UI-kit, контент-план, требования к материалам | Внешний вид интерфейса и наполнение страниц |
| Разработка и проверка | Спецификация интеграций, тест-кейсы, реестр замечаний | Технические требования и результаты тестирования |
| Запуск и передача | Акт, инструкция, перечень доступов, реестр передаваемых материалов | Факт выполнения работ и комплектность передачи |
Название файла не так важно, как его содержание. Например, календарный план может быть отдельным приложением или разделом договора. Главное, чтобы стороны одинаково понимали объём работ, результат и критерии его готовности.
Договор и приложения: основа отношений с подрядчиком
Договор определяет организационные и финансовые условия проекта. Техническое задание отвечает на вопрос, что нужно разработать, а договор — кто, в какие сроки и на каких условиях выполняет работу.
В договоре или приложениях стоит зафиксировать:
- предмет и состав работ;
- этапы, сроки и порядок изменения графика;
- стоимость, схему оплаты и условия дополнительных работ;
- обязанности заказчика по предоставлению материалов и согласованию;
- порядок коммуникации и список уполномоченных представителей;
- процедуру сдачи, проверки и приёмки результата;
- условия исправления недостатков и последующей поддержки;
- порядок передачи исходных файлов, доступов и исключительных прав;
- условия прекращения проекта и передачи незавершённых результатов;
- правила работы с конфиденциальной информацией.
К договору часто прикладывают смету, спецификацию, техническое задание и календарный план. Если проект оплачивается по фактически затраченному времени, документам следует описывать ставки, способ учёта часов, периодичность отчётности и порядок согласования лимитов. При фиксированной стоимости особенно важно точно определить границы работ.
Соглашение о конфиденциальности может понадобиться до подписания основного договора, если заказчик передаёт внутреннюю аналитику, сведения о клиентах, финансовые показатели или непубличные материалы. Необходимость отдельного соглашения зависит от содержания договора и внутренних требований сторон.
Юридические формулировки лучше проверять с профильным специалистом с учётом страны, формы сотрудничества и особенностей проекта. Универсальный шаблон не заменяет анализ конкретной сделки.
Бриф и техническое задание: чем отличаются и что включают
Бриф собирает исходную информацию о бизнесе и задачах. Техническое задание переводит эту информацию в конкретные требования к будущему сайту. Бриф помогает начать обсуждение, но обычно не подходит для приёмки сложного результата.
Что указать в брифе
Хороший бриф содержит не пожелание «сделать современно», а контекст для принятия решений:
- цели сайта и ожидаемые действия посетителей;
- продукты, услуги и особенности бизнеса;
- целевые аудитории и основные пользовательские задачи;
- географию, языковые версии и регионы продвижения;
- существующий сайт, аналитику и известные проблемы;
- конкурентов и визуальные ориентиры;
- нужные интеграции и ограничения инфраструктуры;
- ответственных за контент, согласование и технические вопросы;
- желаемый срок запуска и объективно важные даты.
Бриф может заполнять заказчик самостоятельно или вместе с подрядчиком на интервью. После обсуждения полезно подтвердить итоговый документ, чтобы спорные предположения не перешли в проектирование.
Что должно быть в техническом задании
Техническое задание описывает проверяемый результат разработки. Состав ТЗ меняется в зависимости от типа сайта, но обычно включает:
- назначение проекта и терминологию;
- структуру разделов и типы страниц;
- роли пользователей и права доступа;
- функциональные сценарии: регистрация, поиск, фильтрация, заказ, отправка форм;
- состав данных и правила их отображения;
- требования к административной панели;
- интеграции с CRM, учётными, платёжными и другими системами;
- требования к адаптивности, поддерживаемым средам и производительности;
- правила обработки ошибок и нестандартных ситуаций;
- базовые требования к SEO, аналитике и безопасности;
- критерии приёмки функций.
Формулировка «добавить удобный каталог» не позволяет проверить результат. Полезнее перечислить категории, параметры фильтрации, правила сортировки, вид карточки, поведение при отсутствии товаров и возможности редактора. Чем выше неопределённость и цена изменений, тем подробнее следует описывать функцию.
ТЗ не обязано заранее определять каждую кнопку. Для гибкой поэтапной разработки требования могут храниться в бэклоге в виде пользовательских историй и критериев готовности. В таком случае договор должен объяснять, как формируется приоритет, оцениваются задачи и принимаются итерации.
Документы для проектирования, дизайна и контента
Между техническим заданием и программированием появляются материалы, которые уточняют интерфейс. Такие материалы также нужно согласовывать: разработка по неподтверждённому прототипу часто приводит к переделкам.
Структура, сценарии и прототипы
Карта сайта показывает состав и иерархию страниц. Пользовательские сценарии описывают путь к целевому действию. Прототип определяет расположение смысловых блоков, навигацию и поведение интерфейса без детальной визуальной стилистики.
При проверке прототипов заказчику стоит оценивать не оттенки и шрифты, а полноту информации, последовательность действий и доступность важных функций. На этом этапе дешевле обнаружить пропущенную страницу, лишний шаг в форме или противоречие между мобильной и десктопной логикой.
Дизайн-макеты и UI-kit
Макеты показывают внешний вид ключевых страниц и состояний интерфейса. В комплект могут входить версии для разных размеров экрана, состояния полей, меню, окон, кнопок, уведомлений и ошибок.
UI-kit или дизайн-система фиксирует повторно используемые компоненты: цвета, типографику, сетку, элементы форм, карточки и правила отступов. Для небольшого лендинга достаточно компактного набора компонентов. Для сервиса с десятками экранов системное описание интерфейса сокращает количество расхождений при разработке.
Контент-план и реестр материалов
Контент часто становится причиной переноса запуска, поэтому ответственность за него нужно определить заранее. Контент-план или таблица наполнения может содержать список страниц, формат материалов, объём, источник, ответственного и статус готовности.
Отдельно следует согласовать, кто пишет и редактирует тексты, подбирает изображения, переносит данные со старого сайта, проверяет факты и загружает материалы в CMS. Если используются фотографии, шрифты, видео или иллюстрации третьих лиц, заказчику необходимо понимать основания их использования и ограничения лицензий.
Технические спецификации, тестирование и управление изменениями
Для типового корпоративного сайта технические требования могут находиться внутри общего ТЗ. Сложному проекту обычно нужны отдельные описания архитектуры, интеграций, данных и среды размещения.
Спецификация интеграции определяет системы-участники, состав передаваемых данных, формат запросов и ответов, правила авторизации, ограничения, обработку ошибок и ответственных за доступ к тестовой среде. Без такого документа стороны могут по-разному понимать даже простую задачу «связать сайт с CRM».
Перед сдачей проекта полезно согласовать план тестирования. В зависимости от сайта проверяют:
- основные пользовательские сценарии;
- формы, уведомления и передачу заявок;
- адаптивное отображение и заявленные браузеры;
- роли и ограничения доступа;
- интеграции и обмен данными;
- редактирование контента в административной панели;
- метаданные, адреса страниц, редиректы и индексируемость;
- поведение при ошибках и неполных данных.
Замечания лучше вести в едином реестре. Для каждой записи указывают страницу, условия воспроизведения, ожидаемое и фактическое поведение, приоритет, ответственного и статус. Сообщение «на телефоне всё съехало» не помогает диагностике без модели устройства, снимка экрана и адреса страницы.
Изменения требований необходимо отличать от ошибок. Ошибка означает несоответствие согласованным требованиям. Новое пожелание расширяет или меняет исходный объём. Порядок оценки таких запросов — влияние на сроки, бюджет и связанные функции — стоит определить в договоре до начала работ.
Документы для приёмки, запуска и передачи сайта
Завершение программирования не равно полной передаче проекта. Заказчику нужны не только опубликованные страницы, но и возможность управлять сайтом, продлевать инфраструктуру, менять подрядчика и восстанавливать систему.
На финальном этапе обычно оформляют:
- акт или иной документ о приёмке — подтверждает сдачу согласованного объёма работ;
- протокол замечаний — перечисляет найденные недостатки, сроки и порядок исправления;
- инструкцию администратора — объясняет работу с разделами, пользователями, товарами, заявками и настройками;
- реестр доступов — включает домен, хостинг, CMS, репозиторий, аналитику, панели вебмастеров и внешние сервисы;
- реестр исходных материалов — перечисляет код, дизайн-макеты, графику, документацию и базы данных;
- описание развёртывания и резервного копирования — необходимо для сопровождения и восстановления;
- условия гарантии и поддержки — определяют состав обращений, каналы связи и границы ответственности.
Пароли нежелательно отправлять в открытой таблице или переписке. Безопаснее передавать доступ через согласованный защищённый канал, создавать персональные учётные записи и менять временные пароли после приёмки.
Перед публикацией также проверяют пользовательские документы и механизмы, связанные со сбором данных: тексты уведомлений и согласий, политику конфиденциальности, настройки форм и используемых файлов cookie. Конкретный комплект зависит от функциональности сайта, применимых требований, юрисдикции и фактических способов обработки данных. Подготовку юридических текстов следует поручать компетентному специалисту, а разработчик должен корректно реализовать согласованные механизмы.
Как собрать достаточный комплект без лишней бюрократии
Количество документов должно соответствовать риску и сложности проекта. Для лендинга без интеграций могут быть достаточны договор, краткое ТЗ, прототип, макет, список контента и акт. Интернет-магазину или личному кабинету потребуются подробные сценарии, спецификации обмена данными, матрица ролей и расширенный план тестирования.
Перед стартом используйте чек-лист:
- Определите цели сайта, аудитории и измеримые задачи.
- Зафиксируйте состав работ, исключения и ответственность сторон.
- Свяжите смету и график с конкретными этапами и результатами.
- Опишите функции так, чтобы их можно было проверить.
- Назначьте ответственных за материалы, доступы и согласование.
- Установите срок обратной связи и порядок фиксации решений.
- Согласуйте процедуру оценки новых требований.
- Перечислите исходники, права и доступы, которые передаются после завершения.
- Определите критерии приёмки и формат реестра замечаний.
- Проверьте, кто отвечает за запуск, поддержку и продление сервисов.
У каждого важного документа должна быть актуальная версия, ответственный и понятный статус согласования. Решения из звонков и чатов стоит переносить в рабочую систему или итоговый протокол. Такой подход полезнее, чем большой архив файлов, противоречащих друг другу.
При выборе подрядчика попросите показать не чужие конфиденциальные документы, а структуру процесса: какие результаты создаются на этапах, как согласуются изменения, где ведутся задачи и что передаётся заказчику. Прозрачный порядок работы позволяет заранее увидеть пробелы в проекте.
Частые вопросы
Можно ли начать разработку сайта без технического задания?
Можно начать исследование, интервью или прототипирование. Начинать программирование без зафиксированных требований рискованно: сторонам будет сложно оценить объём, стоимость и соответствие результата ожиданиям.
Кто должен составлять техническое задание?
ТЗ обычно готовит подрядчик или аналитик на основе информации заказчика. Заказчик предоставляет бизнес-требования, ограничения и данные, а затем проверяет и согласовывает итоговое описание.
Нужно ли прикладывать дизайн-макеты к договору?
Необязательно прикладывать готовые макеты при подписании договора, если дизайн создаётся в рамках проекта. Однако договору следует определять этап разработки дизайна, порядок согласования и статус утверждённых макетов.
Какие доступы должен получить заказчик после запуска?
Состав зависит от инфраструктуры, но обычно передают управление доменом, хостингом, CMS, репозиторием кода, аналитикой, почтовыми и интеграционными сервисами. Учётные записи желательно оформлять на заказчика, а не на сотрудника подрядчика.
Чем акт отличается от протокола тестирования?
Акт фиксирует приёмку результата или этапа. Протокол тестирования подтверждает, какие проверки проведены и какие замечания обнаружены. Протокол помогает принять решение, но сам по себе не всегда заменяет документ о приёмке.
Все ли перечисленные документы нужны для небольшого сайта?
Нет. Комплект сокращают с учётом функций, бюджета и рисков, но договорённости о составе работ, требованиях, сроках, приёмке, правах и передаче доступов должны оставаться однозначными.
Если нужно выстроить процесс от аналитики и проектирования до запуска и передачи доступов, изучите услугу разработки сайтов Granat. До начала проекта полезно согласовать не только будущий результат, но и комплект документов для каждого этапа.
