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