Создание сайта: от технического задания до запуска

Создание сайта редко срывается из-за технологий. Гораздо чаще проект буксует по другим причинам: не договорились, что считать результатом, начали рисовать до того, как поняли структуру, забыли про тексты и фотографии, а на приёмке выяснилось, что заявки не доходят до почты. В этой статье мы разобрали весь путь — от первого разговора о задаче до первых недель после запуска — и собрали то, что стоит решить заранее, чтобы потом не переделывать. Материал рассчитан на заказчика: он поможет говорить с подрядчиком на одном языке и понимать, за что вы платите на каждом этапе.

Зачем нужен сайт: цель определяет всё остальное

Первый вопрос, который мы задаём на встрече, звучит просто: какое действие посетителя вы считаете результатом. От ответа зависит и объём работ, и цена, и способ оценки успеха.

Типичные варианты:

• Получать заявки на услуги. Сайту нужны понятные описания услуг, примеры работ, ориентиры по цене и удобные формы.
• Продавать товары. Нужен каталог, корзина, оплата, доставка и связь со складским учётом.
• Подтверждать надёжность компании. Сайт-визитка для тендеров и переговоров: реквизиты, лицензии, проекты, отзывы.
• Обслуживать существующих клиентов. Личный кабинет, база знаний, документы.
• Нанимать людей. Раздел вакансий и рассказ о том, как устроена работа.

Часто целей несколько, и это нормально. Важно расставить их по значимости: сайт, который одинаково старается делать пять вещей, обычно не делает как следует ни одной. Дальше цель превращается в измеримый ориентир — например, «принимать заявки с формы и видеть их в CRM» или «оформлять заказы с оплатой картой». Этот ориентир и будет критерием приёмки.

Какой сайт нужен: типы и когда какой подходит

Название типа определяет не столько дизайн, сколько объём работ.

• Лендинг — одна страница под одно предложение. Подходит для рекламной кампании, запуска продукта, мероприятия. Быстро делается, но плохо растёт: добавлять в него разделы бессмысленно.
• Сайт-визитка — несколько страниц о компании и услугах. Достаточно, когда сделка идёт через переговоры, а сайт подтверждает существование компании.
• Корпоративный сайт — развитая структура: направления, услуги, проекты, блог, вакансии. Основной инструмент, если вы рассчитываете на поиск.
• Сайт-каталог — товары без онлайн-оплаты, заказ через заявку. Разумный вариант для оптовых поставок и оборудования.
• Интернет-магазин — каталог, корзина, оплата, доставка, интеграции с учётом. Самый трудоёмкий из массовых типов.
• Веб-сервис или личный кабинет — не сайт в привычном смысле, а приложение с ролями, правами и данными.

Техническое задание: что в нём должно быть

ТЗ нужно не для формальности. Это документ, который защищает обе стороны: заказчик понимает, что получит, подрядчик — что должен сделать. Без него любое расхождение в ожиданиях превращается в спор, а любая новая идея — в бесплатную работу или в конфликт.

Мы считаем достаточным ТЗ, в котором есть:

1. Цель сайта и целевые действия. Кратко, без общих слов.
2. Аудитория и типовые сценарии. Кто приходит и что должен суметь сделать.
3. Структура. Полный перечень страниц и разделов с их назначением.
4. Описание типовых страниц. Из каких блоков состоит страница услуги, карточка товара, статья.
5. Функциональные требования. Формы, поиск, фильтры, калькулятор, личный кабинет, многоязычность.
6. Интеграции. С какими системами и в какую сторону передаются данные.
7. Требования к контенту. Кто пишет тексты, кто предоставляет фотографии, в какие сроки.
8. Технические требования. Платформа, хостинг, домен, поддерживаемые браузеры, мобильная версия, скорость загрузки.
9. Административная часть. Что заказчик должен уметь менять сам, без разработчика.
10. Порядок приёмки. Как проверяется результат и что считается выполненным.

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

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

Платформа: конструктор, готовая CMS или разработка

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

Мы советуем не выбирать платформу первой. Сначала — структура и функциональные требования; после этого обычно остаётся один-два разумных варианта. И отдельно обсудите, кому принадлежат исходники и есть ли к ним доступ: это выясняется в самый неудобный момент — когда нужно сменить подрядчика. Сменить платформу можно и позже: так мы делали перенос сайта некоммерческой организации на новую систему управления.

Из чего складывается стоимость и срок

Цена сайта — это не цена «сайта вообще», а сумма конкретных работ. На неё влияют:

• Количество уникальных шаблонов страниц. Сорок страниц по одному шаблону дешевле, чем восемь страниц по восьми разным.
• Сложность дизайна. Индивидуальный макет дороже адаптации готовой темы.
• Функциональность. Фильтры, калькуляторы, личные кабинеты, многоязычность — каждая позиция считается отдельно.
• Интеграции. Оплата, доставка, CRM, складской учёт. Стоимость зависит от того, есть ли у системы нормальный программный интерфейс.
• Контент. Написание текстов, фотосъёмка, наполнение каталога.
• Наполнение. Перенос тысячи товаров руками — это отдельная работа, её часто забывают заложить.
• Сроки. Сжатые сроки означают параллельную работу нескольких специалистов и обычно наценку.

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

Мы всегда предупреждаем: подозрительно дешёвое предложение обычно означает, что часть работ вынесена за скобки — тексты, наполнение, адаптив, интеграции или поддержка после запуска. Сравнивать предложения имеет смысл по составу работ, а не по итоговой цифре.

Этапы работ и что вы получаете на каждом

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

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

Структура, прототип и дизайн

Структура сайта — это перечень страниц и их связи. Мы собираем её из двух источников: что компания должна рассказать и что люди ищут. Второй источник часто важнее: если по услуге существуют устойчивые запросы, ей нужна отдельная страница, а не абзац в общем списке. По этому принципу собран сайт-каталог сети по ремонту телефонов.

Прототип — схема страницы без цвета и картинок: какие блоки, в каком порядке, что в них написано. На этом этапе дешевле всего спорить. Перестановка блока в прототипе занимает минуты, та же перестановка после вёрстки — часы, а иногда требует переделки кода.

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

Что стоит проверить в макетах до передачи в вёрстку:

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

Вёрстка и программирование: что проверять

Вёрстка — это перевод макета в код, который одинаково работает на разных экранах и в разных браузерах. Заказчику не нужно разбираться в коде, но несколько вещей стоит проверить самостоятельно:

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

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

Отдельно проверьте, что сайт работает по защищённому протоколу, что установлен сертификат и что все адреса ведут на один основной вариант — с www или без, — а не открываются в нескольких вариантах одновременно.

Контент: тексты, фотографии, наполнение

Контент — самая частая причина срыва сроков. Разработка закончена, а сайт не запускается, потому что тексты «почти готовы» уже третий месяц.

Чтобы этого не случилось, мы фиксируем в начале проекта: кто отвечает за тексты, кто за фотографии, к какой дате они нужны и что происходит, если материалов нет. Полезные правила:

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

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

Интеграции: оплата, CRM, учёт, доставка

Сайт редко живёт сам по себе. Обычно он должен передавать данные дальше — в почту, CRM, учётную систему, службу доставки. Чаще всего это синхронизация сайта с 1С и передача заявок в CRM.

Наиболее востребованные связки:

• Заявки в CRM. Отправленная форма создаёт сделку с источником обращения. Без этого невозможно понять, какие страницы приносят клиентов.
• Приём оплаты. Подключается через платёжный сервис. Важное правило: данные карты вводятся на стороне банка или платёжной системы, а не на вашем сайте — это и требование безопасности, и снятие ответственности за хранение таких данных.
• Товарный учёт. Обмен с учётной системой по остаткам, ценам и заказам. Договоритесь заранее о частоте обмена и о том, какая система считается главной по каждому полю.
• Доставка. Расчёт стоимости и передача отправлений в службу доставки.
• Аналитика. Счётчики и настроенные цели. Их ставят до запуска, а не через полгода.

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

И отдельный пункт про персональные данные: любая форма должна содержать непредустановленный флажок согласия на обработку и ссылку на политику. Это требование закона, и добавить его на этапе разработки проще, чем потом.

Тестирование и приёмка перед запуском

Приёмка — это не «посмотрели, вроде красиво». Это проверка по списку, составленному из ТЗ. Вот минимальный набор, который мы проходим по каждому проекту.

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

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

Порядок работ, описанный выше, — это то, как мы ведём проекты сами: создание сайтов и информационных систем для бизнеса с фиксацией задач в брифе и техническом задании до начала разработки.

Запуск и первые недели

Запуск — не финиш, а точка, с которой начинают поступать данные. Что мы делаем в первый месяц:

1. Передаём сайт в панели вебмастеров и проверяем, что карта сайта принята.
2. Следим за журналом ошибок сервера: часть проблем видна только на живом трафике.
3. Смотрим отчёты аналитики: с каких страниц уходят, где обрываются сценарии, доходят ли посетители до формы.
4. Спрашиваем у отдела продаж, какие вопросы задают позвонившие. Это прямое указание, чего не хватает на сайте.
5. Собираем первые правки в один список и вносим их партией, а не по одной в день.

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

Мы делаем сайты полного цикла: обследование, техническое задание, прототипы, дизайн, вёрстка, программирование, интеграции и сопровождение после запуска. Если вы планируете новый сайт или хотите понять, что не так с текущим, посмотрите, как устроено создание сайтов у нас, и напишите нам. Обсудим задачу, оценим объём работ и предложим план — оценка бесплатная.