Поддержка сайта после редизайна: как стабилизировать работу и принять результат

Поддержка сайта после редизайна — это отдельный ограниченный по времени этап, который начинается сразу после переноса новой версии на рабочий домен и заканчивается тогда, когда ключевые сценарии снова работают предсказуемо, а поток обращений по типовым дефектам иссяк. Смысл этапа в том, чтобы сначала вернуть сайту устойчивость и только потом браться за развитие.

Что считать поддержкой сайта после редизайна и где её границы

Редизайн меняет шаблон, структуру страниц, подключение скриптов и часто — способ вывода каталога. После переноса на рабочий домен часть сценариев ведёт себя иначе, чем на тестовом стенде: где-то не подставляется цена, где-то форма теряет данные, где-то страница открывается дольше обычного. Поддержка сайта после редизайна — это управляемый период, в котором команда не добавляет новое, а возвращает сайту предсказуемость.

Границы этапа описывают тремя признаками:

• есть зафиксированный список сценариев, которые обязаны работать: заказ, заявка, оплата, вход в личный кабинет, поиск, выгрузка в учётную систему;
• есть журнал дефектов с приоритетами и ответственным за каждый пункт;
• есть критерий выхода: сколько времени подряд не появляется новых дефектов первого и второго уровня.

Что в стабилизацию не входит: новые разделы, смена дизайна, расширение функциональности, интеграции с новыми сервисами. Это уже отдельная задача и отдельная оценка. Смешивать их в одном списке опасно: развитие маскирует регресс, и понять, что именно сломалось, становится труднее.

Отдельно стоит договориться о терминах внутри команды. «Стабилизация», «гарантия» и «поддержка» часто понимаются по-разному, и из этого вырастают споры о деньгах и сроках. Полезно один раз письменно зафиксировать, что каждый из этих терминов означает в конкретном проекте, и дальше опираться на это определение.

Если сайт работает на 1С-Битрикс, полезно заранее понимать, какие каналы помощи доступны по платформе: у вендора есть центр поддержки разработчиков с документацией, обучающими материалами и сообществом. Это не заменяет работу по проекту, но помогает быстрее проверять спорные места и не изобретать то, что уже описано.

Какие дефекты и метрики фиксируют в первый период

Первый период после переключения — самый шумный. Задача не в том, чтобы закрыть всё сразу, а в том, чтобы отделить регресс от ожидаемого поведения и от старых проблем.

Как собрать список дефектов

Источники обращений обычно такие: письма и звонки клиентов, сообщения в чат, отчёты службы поддержки, логи ошибок, обращения менеджеров, которые первыми видят, что заказ не проходит. Каждое обращение превращают в запись с одинаковыми полями: где воспроизводится, при каких условиях, что ожидалось, что получилось, как часто повторяется, есть ли обходной путь.

Важно разделять:

• регресс — работало до редизайна, перестало после;
• известное ограничение — так и было раньше, редизайн не при чём;
• новое пожелание — улучшение, а не поломка.

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

Какие метрики смотреть

Метрики нужны не для отчёта, а для решения: закрывать этап или нет. Обычно смотрят:

• долю успешных прохождений ключевых сценариев;
• количество обращений по дефектам за период и их динамику;
• время от появления дефекта до его закрытия по уровням;
• долю страниц, которые отдают ошибку;
• расхождения между данными сайта и учётной системы.

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

Как приоритизировать

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

Граница гарантии и новая задача: как разделить

Самый частый конфликт после редизайна — спор о том, гарантийный это дефект или новая работа. Разделение опирается на три вопроса.

Первый: это поведение было в согласованном объёме? Если сценарий входил в приёмку и раньше работал — это гарантия. Если сценарий не описывали и не принимали — это новая задача.

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

Третий: есть ли воспроизведение? Дефект без воспроизведения невозможно ни подтвердить, ни закрыть. Нужны шаги, при которых проблема повторяется, и данные, на которых она видна.

Чтобы не спорить каждый раз заново, границу фиксируют письменно: перечень сценариев приёмки, срок гарантии, порядок эскалации, кто принимает решение о приоритете. Если сайт на 1С-Битрикс и его сопровождает студия, разумно заранее согласовать, как соотносятся гарантийные правки и техническая поддержка сайта на Битрикс. Если же предыдущий подрядчик недоступен и работу приходится перенимать, порядок действий описан в материале Подрядчик пропал: как перенять поддержку сайта и ничего не потерять.

План стабилизации: этапы, роли и порядок работ

План стабилизации — обязательный артефакт этапа. Без него работы превращаются в бесконечную реакцию на входящие сообщения.

Роли

• Владелец этапа со стороны заказчика: принимает решения о приоритетах и закрытии.
• Ответственный за приём обращений: регистрирует дефекты, не даёт им потеряться.
• Технический исполнитель: воспроизводит, находит причину, чинит, описывает результат.
• Проверяющий: подтверждает, что дефект закрыт и ничего не сломалось рядом.

Один человек может совмещать роли, но ответственный за приём обращений должен быть всегда — иначе часть сообщений уходит в личные переписки и теряется.

Порядок работ

1. Заморозить изменения, кроме исправлений. 2. Собрать и приоритизировать журнал дефектов. 3. Закрывать сначала то, что блокирует деньги и данные: заказы, заявки, оплата, выгрузка. 4. После каждого исправления проверять соседние сценарии, а не только сам дефект. 5. Вести журнал изменений: что, когда, кем, с какой проверкой. 6. Раз в согласованный интервал пересматривать список и решать, не пора ли закрывать этап.

Порядок «сначала деньги и данные, потом внешний вид» экономит больше всего нервов. Косметика подождёт, потерянный заказ — нет.

Что делать с изменениями, которые всё же нужны

Иногда во время стабилизации действительно требуется срочная правка, не связанная с регрессом: например, изменились условия внешнего сервиса. Такие задачи не смешивают с исправлениями, а ведут отдельным списком с отдельной проверкой. Так видно, что именно вызвало новое поведение сайта, если оно появится.

Таблица принятия решения по дефекту

Таблица — не инструкция, а рамка разговора. Если симптом не подходит ни под одну строку, это повод описать его отдельно, а не подгонять под удобную категорию.

Учебный пример: интернет-магазин после редизайна

Учебный пример. Данные условные, это не реальный проект.

Входные условия. Интернет-магазин на 1С-Битрикс, около 4 000 товаров, обмен с учётной системой раз в 30 минут. Редизайн затронул шаблон каталога, карточку товара, корзину и оформление заказа. Переключение на рабочий домен сделали в четверг вечером, чтобы выиграть время до выходных.

Что произошло в первые дни. В пятницу поступило 14 обращений: у части клиентов не применялась скидка, у части — не подставлялся способ доставки, три заказа не дошли до учётной системы. В субботу добавились жалобы на медленную загрузку карточки. В понедельник менеджеры сообщили, что не видят часть новых заказов в привычном списке.

Как действовали. Завели журнал дефектов с полями «где», «условия», «ожидание», «факт», «частота», «обходной путь». Разделили записи на регресс, известные ограничения и пожелания. Заморозили все работы, кроме исправлений. Первыми взяли заказы и обмен с учётной системой, затем — скидки и доставку, потом — скорость, и только в конце — косметику. Каждое исправление проверяли не только на самом дефекте, но и на соседних сценариях.

Что оказалось причиной. Часть дефектов объяснялась тем, что новый шаблон не учитывал условия, которые раньше задавались в старом. Часть — тем, что настройки, перенесённые на рабочий сайт, отличались от тестовых. Отдельные обращения не подтвердились: клиенты видели закэшированную версию страницы.

Проверка результата. Через две недели команда сверила: тестовые заказы проходят все способы доставки и оплаты; обмен с учётной системой не теряет записи; ключевые страницы открываются в привычное время; новых обращений по закрытым дефектам нет. Только после этого этап закрыли и вернулись к плановым доработкам.

Что помогло бы раньше. Заранее согласованный перечень сценариев приёмки, проверка на данных, близких к рабочим, и договорённость о том, кто принимает решение о приоритете в первые дни.

Как проверить результат и принять работу

Приёмка стабилизации — это не «посмотрели, вроде работает». Нужны проверяемые шаги.

Сначала сверяют сценарии из перечня приёмки: каждый проходят целиком, от входа до результата, на данных, близких к рабочим. Затем проверяют, что исправления не сломали соседние места. Потом смотрят журнал: все ли дефекты первого и второго уровня закрыты, есть ли по ним повторные обращения. И только затем — метрики за период.

Что фиксируют в акте приёмки

• перечень проверенных сценариев и результат по каждому;
• список закрытых дефектов с датой и способом проверки;
• список открытых пунктов с причиной и планом;
• снятые метрики и их сопоставление с порогами;
• решение о закрытии этапа и ответственного за дальнейшие обращения.

Отдельно фиксируют, что осталось открытым и почему. Список открытых пунктов с причиной и планом — нормальный результат приёмки, если он согласован. Ненормально — когда оставшиеся дефекты просто не упомянуты.

Если сайт передают на постоянное сопровождение, полезно заранее обсудить, как будет устроена поддержка сайта на Битрикс: кто принимает обращения, как они приоритизируются, что считается гарантией, а что — новой задачей.

Типичные ошибки и ограничения

• Смешивать исправления и развитие в одном потоке. Тогда непонятно, что именно вызвало новую поломку.
• Начинать с косметики. Пока не закрыты заказы и данные, внешний вид не имеет значения.
• Чинить без воспроизведения. Дефект, который нельзя повторить, нельзя и подтвердить.
• Не вести журнал. Без записей через неделю никто не вспомнит, что уже пробовали.
• Считать, что тестовый стенд полностью повторяет рабочий сайт. Отличия в настройках и данных — обычная причина сюрпризов.
• Закрывать этап по календарю, а не по критериям. Дата не гарантирует, что поток обращений иссяк.
• Оставлять приём обращений «на всех». Тогда часть сообщений теряется в личных переписках.

Ограничения тоже стоит назвать честно. Часть дефектов зависит от внешних сервисов и от действий других подрядчиков — их нельзя закрыть внутри этапа. Часть обращений окажется не дефектами, а пожеланиями. И ни один план не отменяет того, что в первые дни нагрузка на людей выше обычной.

Какие исходные данные подготовить для оценки

Чтобы оценить стабилизацию, а не гадать, нужны:

• перечень сценариев, которые обязаны работать, с приоритетами;
• описание того, что именно изменилось при редизайне;
• доступы и контакты ответственных;
• данные о том, как сайт связан с учётной системой и внешними сервисами;
• журнал обращений за первые дни, если он уже есть;
• сведения о прежнем поведении сайта: что и как работало до изменений;
• договорённости о гарантии и порядке эскалации.

Чем полнее этот набор, тем меньше времени уйдёт на выяснение причин и тем быстрее закроется этап. Если часть данных отсутствует, это не повод откладывать — это повод зафиксировать, что именно придётся выяснять по ходу. Отдельно стоит уточнить, как в компании принято обрабатывать обращения клиентов и какие данные при этом собираются: это уже вопрос границ задачи и сверки с профильным специалистом, а не технического решения.

Чек-лист приёмки стабилизации

• Составлен и согласован перечень сценариев приёмки с приоритетами.
• Заведён журнал дефектов с полями «где», «условия», «ожидание», «факт», «частота», «обходной путь».
• Дефекты разделены на регресс, известные ограничения и пожелания.
• Все работы, кроме исправлений, заморожены на время этапа.
• Дефекты первого и второго уровня закрыты или имеют согласованный план.
• После каждого исправления проверены соседние сценарии.
• Ключевые сценарии пройдены целиком на данных, близких к рабочим.
• Обмен с учётной системой проверен на тестовых записях.
• Метрики за период сняты и сопоставлены с порогами, заданными до начала этапа.
• Список открытых пунктов с причинами согласован с заказчиком.
• Определено, кто принимает обращения после закрытия этапа.
• Зафиксировано, что считается гарантией, а что — новой задачей.