Что происходит после запуска сайта
Как организовать работу после запуска: проверить заявки, отделить гарантийные недочёты от новых задач, передать доступы и составить план развития.
После запуска сайта начинается наблюдение за реальной работой: приходят ли заявки, доступны ли страницы, могут ли сотрудники обновлять материалы. Параллельно закрывают передачу проекта и разделяют оставшиеся вопросы на недочёты, поддержку и новые функции. Публикация не означает, что всё это автоматически входит в одну бессрочную услугу.
Лучше договориться о порядке действий до запуска. Тогда у заказчика есть понятный контакт, список переданных материалов и способ поставить задачу. У исполнителя — конкретное описание проблемы вместо сообщения «посмотрите сайт, что-то не так».
1. Проверьте работу на реальном адресе
Сразу после публикации повторите ключевой сценарий: открыть сайт, перейти к нужной услуге и отправить тестовую заявку. Подтвердите получение у ответственного сотрудника. Если работают внешние системы, проверьте результат и в них: красивое сообщение об успехе ещё не показывает, что обращение попало в рабочую очередь.
В первые дни назначьте человека, который соберёт наблюдения коллег. Пусть замечания попадают в один список, а не в несколько чатов. Указывайте страницу, устройство, время и последовательность действий. Для ошибки полезен скриншот без личных данных и секретов.
Отдельно проверьте, что сотрудник может выполнить обычную задачу: поменять цену, добавить новость или найти полученное обращение. Если для каждого действия приходится звать разработчика, уточните, чего не хватает: инструкции, прав или самой функции. Это разные причины и разный объём решения.
Не оценивайте успех проекта только по первым посещениям. Техническая доступность и коммерческий результат — разные вопросы. Для обсуждения заявок нужны сведения об источниках посетителей, предложении и обработке обращений, а не предположение, что любая тишина вызвана ошибкой сайта.
2. Отделите недочёты от новых пожеланий
В моей работе недочёты после сдачи исправляются бесплатно в течение 30 дней. Речь о расхождениях с согласованным заданием: например, предусмотренная форма не передаёт обязательное поле. Конкретный порядок фиксации и исправления нужно сверить с договором проекта.
Новая функция — другая ситуация. Если после запуска понадобились дополнительная роль пользователя, новый раздел или обмен с ещё одной системой, это отдельная задача для оценки. Она не становится недочётом только потому, что идея появилась в течение гарантийного периода.
Удобно описывать обращение в четырёх пунктах:
- что согласовано и где это зафиксировано;
- что происходит сейчас;
- какого результата ожидаете;
- как повторить ситуацию и насколько она мешает работе.
Не обязательно самостоятельно определять техническую причину. Достаточно наблюдаемого результата. Исполнитель проверит, связано ли отклонение с выполненной работой, изменёнными настройками или сторонним сервисом. До проверки не стоит автоматически относить любой сбой к гарантии или платной доработке.
Если задачу нельзя решить сразу, согласуйте следующий шаг и ответственного. Не подменяйте конкретную договорённость обещанием «всегда быть на связи»: оно не определяет часы работы, приоритет или срок восстановления.
3. Закройте передачу и договоритесь о регулярных задачах
У заказчика должны остаться доступы к согласованным сервисам, исходные материалы в предусмотренном объёме и инструкция по повседневным действиям. Проверьте это практикой: ответственный входит в кабинет и находит нужный раздел без помощи исполнителя.
Составьте календарь продлений: домен, размещение, лицензии и внешние сервисы. Укажите плательщика и получателя уведомлений. Поддержка разработчика не заменяет оплату этих услуг, если иное прямо не согласовано. Также уточните, кто хранит резервные копии и проверяет возможность восстановления.
Регулярная поддержка может включать согласованные правки, развитие и мониторинг. Но состав нужно определить заранее: что наблюдаем, как часто, кто реагирует и какие работы оплачиваются отдельно. Само слово «поддержка» не обещает круглосуточное дежурство или неограниченные изменения.
Если уже понятно, что нужно улучшить, соберите задачи для доработки сайта. Добавьте пример результата и приоритет: восстановить приём заявок важнее, чем поменять порядок декоративных блоков. Такой список позволяет оценить работу предметно.
4. Планируйте развитие по наблюдениям, а не по впечатлению
Когда основные сценарии работают, соберите вопросы посетителей и сотрудников. Какие условия приходится объяснять вручную? Где теряется нужный документ? Какого фильтра не хватает менеджеру? Это исходные гипотезы для развития, а не доказательства необходимости полной переделки.
Сопоставьте наблюдения с доступной аналитикой. Проверьте, правильно ли измеряются действия, прежде чем делать выводы по отчёту. Полезно менять ограниченный набор элементов и фиксировать дату изменения, чтобы позднее понимать, с какой версией сайта связаны данные.
Появление страниц в поиске также требует наблюдения. Google предупреждает, что запрос на повторное сканирование не гарантирует немедленного включения в результаты или включения вообще. Поэтому публикацию, обнаружение поиском и получение обращений не стоит объединять в один обещанный срок.
Завершите первый период списком решений: что исправлено, что требует уточнения, что переносится в следующий этап. Для обсуждения поддержки отправьте через форму обращения адрес сайта и задачи. Я уточню вводные, границы ответственности и подходящий формат работы.