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

Комментарии
Написать комментарийВойти