Что проверить перед заказом разработки и технической поддержки сайта

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

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

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

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

До обращения к разработчику желательно зафиксировать:

• основные цели сайта;

• целевые действия посетителей;

• обязательные разделы и функции;

• необходимость подключения сторонних систем;

• требования к нескольким языковым версиям;

• планируемое развитие проекта после запуска.

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

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

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

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

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

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

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

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

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

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

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

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

• доменное имя;

• учетная запись у поставщика размещения;

• система управления сайтом;

• исходные файлы и программный код;

• тексты, изображения и оформление;

• учетные записи систем статистики;

• ключи для подключения оплаты, доставки и других служб.

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

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

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

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

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

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

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

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

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

Результаты проверки лучше фиксировать в одном документе или системе учета задач. Это исключает потерю замечаний в переписке и позволяет контролировать сроки их устранения.

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

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

Зависимость от одного разработчика повышает стоимость любых изменений и создает риск остановки работ. Возможность передать проект другому исполнителю — один из признаков качественно организованной разработки.

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

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