Содержание 9 разделов ↘
Почему проект сайта превращается в бесконечную разработку
Компания согласовала красивый макет, подрядчик начал вёрстку, через два месяца выяснилось, что тексты никто не готовит, каталог не описан, интеграция с CRM не оценена, а критерии приёмки сводятся к «нам нравится». Сроки плывут не потому, что сайты невозможно планировать, а потому что договорились о дизайне до согласования состава продукта.
Этот гайд нужен до подписания договора. На выходе у вас будет минимальное техническое описание, сопоставимая смета, контрольные точки проекта и правила приёмки. Он не заменяет юридическую экспертизу: конкретные права и ответственность нужно оформлять в договоре с юристом.
Сначала создайте карту проекта на одной странице
До запросов цен запишите, для кого сайт, какие продукты или услуги он объясняет, какие действия должен поддерживать и кто в компании принимает решение по каждому блоку. Укажите типы страниц (не только их число), каталог, поиск и фильтры, языки, формы, интеграции, миграцию старых URL, требования доступности и аналитики. Список из 30 страниц недостаточен: одна шаблонная карточка и сложный конфигуратор имеют разную трудоёмкость.
Полезно отдельно перечислить «не входит»: личный кабинет, контентное наполнение, профессиональная фотосъёмка, интеграция учёта, перевод, SEO-продвижение после запуска. Не для того чтобы сэкономить на всём, а чтобы обе стороны знали границу оценки.
Почему две сметы на одинаковый сайт могут отличаться втрое
Сравнивайте состав работ по этапам. Одно предложение включает исследование задач, прототипы, дизайн-систему, CMS, шаблоны, интеграции, тесты и запуск. Другое ограничивается «дизайн + разработка», считая контент и интеграции отдельными задачами. Дешёвая цифра может относиться к принципиально меньшему результату.
| Этап | Проверяемый результат | Вопрос подрядчику |
|---|---|---|
| Аналитика и структура | Карта страниц, сценарии и объём работ | Сколько типов страниц проектируется? |
| UX и дизайн | Макеты ключевых состояний | Есть ли мобильные и ошибочные состояния? |
| Разработка | Репозиторий, работающий frontend/backend | Какие интеграции и ограничения включены? |
| Контент | Наполненные шаблоны и подготовленные данные | Кто пишет и переносит тексты? |
| SEO-миграция | Карта редиректов, canonical, метаданные | Что будет со старыми URL? |
| Тесты и запуск | Приёмочные сценарии, акт, доступы | Как исправляются критические дефекты? |
| Поддержка | SLA в согласованном объёме | Какие изменения входят после релиза? |
Этапы нужно принимать по работающим артефактам
- Архитектура: карта маршрутов и функциональные сценарии, включая формы, каталог и поиск.
- Прототип: важные пути пользователя, порядок информации, доступность на мобильном.
- Дизайн: ключевые страницы и состояния; интерфейсные компоненты и система отступов.
- Рабочая сборка: страницы с настоящими данными, интеграции и проверяемая логика.
- Предрелиз: редиректы, индексационные теги, аналитика, скорость, безопасность и сценарии ошибок.
- Запуск: передача исходников и доступов, план резервной копии, регламент поддержки.
Оплата и календарь могут быть привязаны к этим результатам, а не к субъективным оценкам «готово на 80%». В договоре различайте ошибку относительно согласованного требования и новую просьбу после утверждения этапа.
Кому принадлежат домен, код, макеты и данные
Домен и аналитика должны оставаться под управлением заказчика или иметь ясно закреплённый порядок передачи. Для исходников, дизайна, шрифтов, сторонних библиотек и контента проверьте права использования и возможности сопровождения другим подрядчиком. Оговорите, передаётся ли Git-репозиторий, документация по развёртыванию, список лицензий, порядок доступа к CMS и интеграциям.
Отдельный риск — сайт работает только на инфраструктуре подрядчика, а выгрузить его в рабочем виде нельзя. Такой вариант может быть допустим осознанно, но тогда экономику владения и риск смены поставщика нужно учитывать до заказа.
Что предусмотреть для SEO ещё до запуска
Если сайт уже получает органический трафик, соберите действующие URL, страницы с показами и конверсиями, правила каноникализации и карту перенаправлений. При изменении структуры сохраните пользовательскую задачу и настройте релевантные редиректы. Не направляйте все старые страницы на главную — так теряется смысл перехода.
Проверяйте серверный HTML, метатеги robots, canonical, внутренние ссылки, sitemap, работу навигации без выполнения сложных сценариев в браузере и корректные статусы HTTP. Наличие XML-карты не гарантирует индексацию; поисковая система решает, какие доступные страницы включать в индекс. На тестовом сайте должен оставаться noindex до согласованного публичного запуска.
Приёмка: семь тестов, которые защищают заказчика
Проверьте: (1) открытие всех ключевых маршрутов с прямого URL; (2) мобильные состояния; (3) отправку формы с подтверждением в CRM; (4) ошибки валидации и недоступный API; (5) доступность каталога и фильтров; (6) индексационные и канонические сигналы; (7) владение кодом и рабочую инструкцию развёртывания. Для каждой проверки храните URL, ожидаемый результат, фактический результат, устройство и ответственного.
Критические дефекты не следует списывать на «поддержку после запуска», если они нарушают согласованные сценарии. Косметические изменения можно вынести в отдельный план, чтобы не блокировать запуск бесконечной полировкой.
Как управлять новыми пожеланиями, не срывая проект
Каждое изменение после утверждения базы оформляйте как отдельное решение: зачем нужно, сколько стоит, что переносит по срокам, какие зависимости создаёт и что будет, если отложить. Держите один реестр запросов, а не обсуждайте их одновременно в переписках дизайнеру, разработчику и аккаунту.
Если команда регулярно «вспоминает» обязательные элементы по ходу разработки, причина не в дисциплине, а в незавершённом этапе постановки задачи. Возвращайтесь к карте сценариев и фиксируйте принятую базовую версию.
Мини-чек-лист перед подписанием договора
Убедитесь, что на руках есть функциональное описание, карта страниц, план контента, сопоставимая смета, перечень интеграций, границы ответственности, контрольные точки, порядок приёмки, условия изменения работ, права на результаты и критерии запуска. Покажите документы будущему сотруднику, который не присутствовал на переговорах: сможет ли он объяснить, что покупает компания и когда результат считается готовым?
Если ответ нет, не торопитесь утверждать бюджет разработки. Короткая качественная подготовка обычно полезнее подробного договора на плохо определённый продукт.
