Как правильно заказать сайт и не переделывать его потом: часть 1

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

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

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

Guard-IT находится в Новосибирске и ведёт проекты для компаний из разных регионов России и других стран. На старте мы регулярно сталкиваемся с одной и той же ситуацией: заказчик хорошо знает свой бизнес, но совершенно не обязан знать, какая структура, CMS или схема интеграций ему нужна. Это задача команды разработки.

Из практики Guard-IT: хороший старт проекта начинается не с вопроса «какой дизайн вам нравится?», а с понимания того, что должен изменить новый сайт в работе бизнеса.

Почему сайты приходится переделывать вскоре после запуска

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

Компания решила запустить SEO, а под основные направления услуг нет отдельных посадочных страниц. Появилась новая категория товаров, но каталог проектировался под старый ассортимент. Отдел продаж попросил передавать заявки в CRM с дополнительными параметрами, а форма собирает только имя и телефон.

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

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

Поэтому вопрос до старта должен звучать не «сколько страниц сделать?», а «что сайт должен позволить делать сейчас и что может потребоваться от него дальше?».

Сначала задача бизнеса, потом структура сайта

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

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

Один и тот же визуально аккуратный сайт не сможет одинаково хорошо решить все эти задачи.

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

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

Что должен выяснить подрядчик

До проектирования команде важно понять несколько вещей:

1. Кто принимает решение о покупке и какие вопросы возникают у клиента до обращения.

2. Как сейчас компания получает заявки и какие каналы планирует развивать.

3. Какие услуги, категории или направления являются приоритетными.

4. Что происходит с обращением после отправки формы.

5. Какие системы сайт должен использовать или учитывать: CRM, 1С, телефонию, оплату, доставку, аналитику.

6. Как бизнес планирует развивать проект после запуска.

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

Если планируется SEO, его нужно учитывать до дизайна

Одна из самых дорогих ошибок: сначала сделать сайт, а потом решить его продвигать.

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

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

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

Подробнее о том, как мы подходим к самой разработке, можно посмотреть в материале о создании сайтов в Guard-IT.

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

Не стоит начинать проект с выбора CMS

WordPress, 1С-Битрикс, конструктор или индивидуальная разработка сами по себе не делают проект хорошим или плохим.

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

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

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

Если вы выбираете между полноценной CMS и конструктором, эту тему мы отдельно разобрали в материале «Стоит ли создавать сайт на конструкторе: часть 1».

Контент нельзя оставлять «на потом»

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

Контент влияет и на структуру.

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

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

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

Мобильный сценарий нужно проектировать отдельно

Уменьшить готовую десктопную страницу до ширины смартфона недостаточно.

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

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

Поэтому адаптивность лучше воспринимать не как техническую опцию в конце сметы, а как часть проектирования интерфейса.

Какие интеграции могут неожиданно изменить проект

Даже простой корпоративный сайт редко существует полностью отдельно от бизнеса.

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

Разработчик должен узнать об этом до оценки архитектуры.

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

Нужно ли заказчику писать подробное техническое задание

Не обязательно.

Если компания уже знает свои процессы и имеет штатного IT-специалиста, подробное ТЗ может быть полезным. Но требовать от собственника бизнеса самостоятельно описать архитектуру, сценарии пользователей и технические ограничения странно: именно для этого и привлекают профессиональную команду.

От заказчика важнее другое: знание продукта, клиентов, продаж и планов бизнеса.

Задача разработчиков: превратить эти данные в понятную структуру проекта, зафиксировать состав работ и объяснить последствия ключевых решений.

Из практики Guard-IT: заказчик должен хорошо понимать, какой результат покупает. Разбираться вместо команды в CMS, структуре базы данных и способах реализации интеграций ему не требуется.

Что стоит получить до начала основной разработки

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

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

Главное, чтобы было понятно:

• какие задачи решает сайт;

• для кого он создаётся;

• какие основные разделы и сценарии нужны;

• какие функции и интеграции входят в проект;

• что потребуется для продвижения;

• какой результат должен быть передан после завершения работ.

Если этих ответов нет, слишком многое начинает решаться уже в процессе разработки. Именно тогда растут сроки, стоимость и число переделок.

Почему самая низкая цена на старте может оказаться самой дорогой

Две студии могут оценить «один и тот же сайт» совершенно по-разному, потому что на самом деле они считают разные работы.

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

Сравнивать только итоговые суммы в таком случае бессмысленно.

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

Когда можно запускаться быстрее

Не каждому бизнесу сразу нужен большой сайт.

Иногда правильнее выпустить компактную первую версию, проверить направление и постепенно расширять проект. Но сокращать лучше объём, а не качество основы.

Можно отложить второстепенные разделы. Можно начать с части каталога. Можно перенести автоматизацию следующего этапа.

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

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

Что происходит дальше

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

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

Перейти ко второй части: как выбрать подрядчика на разработку сайта.

Если вы планируете новый сайт и хотите до начала разработки понять, какой объём действительно нужен вашему бизнесу, в Guard-IT можно начать с разбора задачи. Мы изучим исходные данные и предложим структуру проекта без необходимости самостоятельно составлять техническое задание.