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