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