Сопровождение сайта после запуска

Сопровождение сайта — это договорённость о том, как команда будет жить с площадкой после релиза: кто принимает задачи, как быстро реагируем на поломки, куда складываем идеи «на потом» и как не смешивать срочное с плановым. Без такой рамки владелец бизнеса пишет в общий чат, разработчик тонет в мелочах, а стратегические доработки откладываются месяцами. Хорошее сопровождение выглядит скучно снаружи — регулярные отчёты, предсказуемые релизы, редкие ночные звонки.

Три класса задач в сопровождении

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

SLA: что фиксировать в цифрах, а что — в процессе

SLA (соглашение об уровне сервиса) не обязан быть корпоративным документом на десять страниц. Достаточно явно записать: время первой реакции на инцидент, время восстановления критичного функционала, рабочие часы, канал связи и что считается инцидентом. Например, «не открывается сайт» — инцидент; «хотим другой оттенок кнопки» — очередь правок. Серые зоны («форма работает, но письма приходят с задержкой в час») лучше описать заранее, иначе они станут вечным спором.

• Время реакции и время решения — разные метрики, обе нужны
• Эскалация: кому звонить, если ответа нет в согласованный интервал
• Окна обслуживания для обновлений, чтобы не релизить в пик продаж
• Формат отчёта: еженедельно или ежемесячно — но регулярно

Бэклог развития: как не потерять идеи маркетинга

Маркетинг генерирует запросы быстрее, чем разработка их успевает делать. Единый бэклог с приоритетом и оценкой «усилие / эффект» снимает хаос: видно, почему задача стоит третьей, а не первой, и сколько она займёт. Полезно раз в месяц проводить короткую сессию приоритизации с владельцем бизнеса — не техническую, а продуктовую: что ближе к деньгам в этом квартале.

Релизы при сопровождении: маленькими порциями

• Группировать правки в релиз с чек-листом, а не выкладывать по одному файлу в течение дня
• Иметь staging или хотя бы снимок перед обновлением
• После релиза — smoke-тест: главная, услуга, форма, оплата (если есть)
• Фиксировать версию: что именно ушло в прод и кто подтвердил приёмку

Передача между подрядчиками

Смена команды сопровождения — частый источник простоя. Минимальный пакет передачи: репозиторий или архив кода, доступы по ролям, описание интеграций, расписание cron, контакты хостинга и регистратора, последние три отчёта поддержки. Без этого новый подрядчик месяц «разбирается», а бизнес платит дважды. Закладывать документирование в сопровождение дешевле, чем экстренно восстанавливать знания при уходе разработчика.

Сопровождение окупается, когда сайт перестаёт быть «чёрным ящиком» для собственника: понятно, что сделано, что сломано, что запланировано и сколько это стоит. Тогда решения о рекламе и найме менеджеров опираются на рабочий инструмент, а не на надежду.

Метрики сопровождения, которые имеют смысл

Количество закрытых тикетов само по себе мало что говорит. Полезнее смотреть на время восстановления после инцидентов, долю задач развития, дошедших до релиза по плану, и число повторяющихся проблем (если форма ломается каждый месяц после обновления — нужен системный фикс, а не очередная «заплатка»). Для маркетинга можно добавить контроль битых ссылок в рекламных посадочных и соответствие UTM-страниц живым URL — это напрямую влияет на стоимость лида.

1. MTTR — среднее время восстановления критичного функционала
2. Доля инцидентов с задокументированным постмортем
3. Процент релизов без отката в течение 48 часов
4. Регулярность отчётов и выполнение согласованного плана развития