Для каждой ошибки договоритесь, кто читает сообщение, кто проверяет причину, кто разрешает изменение и кто смотрит результат после публикации. В маленькой команде несколько действий может выполнять один человек. Запишите его имя и контакт, а также замену на время отсутствия.
Допустим, сайт услуг ведёт владелец, код меняет фрилансер, а сервер обслуживает хостинг. Уведомление о сбое сначала читает владелец. Он проверяет URL в браузере и передаёт время и результат тому, кто может восстановить сайт.
Заполните таблицу с именами
| Действие | Кто отвечает в примере | Что передать дальше |
|---|---|---|
| Прочитать сообщение и открыть URL | Владелец | Время, адрес, сообщение браузера |
| Найти причину ошибки страницы | Разработчик | Объяснение и вариант исправления |
| Разобрать серверный сбой | Хостинг | Результат проверки логов |
| Согласовать важное изменение | Владелец | Что можно менять и когда |
| Проверить правку после публикации | Владелец с разработчиком | Адреса и повторённые действия |
Замените роли именами и контактами. Если для строки нет исполнителя, решите это до следующего сбоя. Указанный человек может привлекать специалиста, но отвечает за получение ответа.
Что решает владелец
Владелец сайта определяет важные пользовательские действия и ограничения работы. Он может объяснить, какие страницы приводят обращения, когда начинается рекламная кампания и какие изменения нельзя выпускать без согласования. Эти сведения не выводятся автоматически из балла аудита.
Укажите ограничения: например, не отключать форму во время рекламы и не менять адрес услуги без согласования. Для приёма формы владельцу нужно подтвердить тестовую заявку у менеджера; проверку серверной настройки он может поручить специалисту.
Что передать разработчику
Разработчик отвечает за изменение реализации в пределах согласованной задачи. Задача должна содержать адрес, наблюдаемый факт, ожидаемый результат и способ приёмки. Ссылка на длинный отчёт без выделенного примера часто приводит к повторному выяснению деталей и потере времени.
Не требуйте «исправить всё, что сервис отметил». Некоторые замечания относятся к продуктовым решениям, ограничениям доступа или содержанию. Исполнитель должен знать, какие изменения утверждены и какие требуют уточнения. Условия приёмки полезно согласовать до выпуска, чтобы не спорить после него.
Структуру можно взять из шаблона задачи разработчику. Например: «Ссылка услуги в общем меню ведёт на старый адрес; нужен переход на /services/repair; после публикации проверяем главную и две услуги».
Когда обращаться к хостингу
Проблемы сертификата, настроек домена, сетевой доступности и сервера иногда требуют участия хостинга или администратора. Разработчик сайта может не управлять этими настройками. Заранее запишите, у кого есть договор с хостингом и право обращаться в поддержку.
При передаче приложите время с часовым поясом, конкретный адрес и наблюдаемый результат. «Сайт иногда тормозит» не позволяет найти нужный интервал в логах. Если проблема подтверждена только одним измерением, так и напишите; повторяемость нужно проверять отдельно.
Контакт поддержки и номер договора храните там, где их найдёт заменяющий. На время расследования назначьте одного человека, который согласует изменения: одновременные перезапуски нескольких участников затруднят разбор.
Проверьте договорённость на одной задаче
Возьмите актуальное замечание в кабинете мониторинга. Пройдите его по таблице: кто уже прочитал, кому передали, кто обещал ответ и кто повторит проверку. Если никто не ждёт результата, задача может потеряться между чатами.
Для замечания по поиску или метатегам привлеките человека, который объяснит ожидаемое состояние страницы. Выбрать первые работы поможет инструкция по приоритетам аудита.
Перед отпуском попросите заменяющего показать журнал, контакт хостинга и открытую задачу. Проверьте настройки уведомлений и договоритесь о просмотре кабинета. Внешние сообщения зависят от привязки и доступности канала. При ближайшем настоящем событии уточните у получателя, увидел ли он сообщение.