Подрядчик предлагает переписать сайт: как проверить основания и смету

За что компания заплатит второй раз

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

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

Симптом, причина и работа

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

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

В отчёте различают подтверждённые причины и предположения. Если подрядчик не получил исходники или доступ к интеграции, он описывает риск и запрашивает недостающие данные.

Непроверенную причину нельзя подавать как установленную невозможность исправления. Руководитель запрашивает недостающее и понимает, какие пункты сметы ещё могут измениться после осмотра.

Сравнивать нужно исправление, замену части и новый сайт

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

Что показывает реальный переход

ШТАБ ИТ перевёл каталог крупной электротехнической компании с React на Next.js. Сайт этого клиента работает на Битриксе в сочетании с Next.js. После перехода страницы каталога стали правильно индексироваться, а позиции сайта пошли вверх. При обсуждении сметы такой результат возвращает нас к предмету работ: какое изменение поможет устранить найденную проблему? Если причина сосредоточена в каталоге, сначала стоит оценить его переработку и связь с остальными разделами. Полная замена сайта потребует собственных оснований.

Название технологии — только начало диагностики. Для страниц на React разбирают способ подготовки содержимого и доступность данных поисковому роботу, прежде чем предлагать переход на другой инструмент.

Google описывает обработку JavaScript как отдельный этап получения содержимого и рекомендует учитывать серверную или предварительную отрисовку. В документации Next.js серверные и клиентские компоненты выполняют разные задачи, а HTML может готовиться до работы интерактивной части в браузере. Подрядчику стоит показать, какое содержимое робот получает сейчас и что изменится после переработки, а не ограничиваться заменой названия технологии в смете.

Почему частичная замена тоже требует расчёта

Новая часть должна получать нужные данные и передавать результат прежним системам. Если новая и старая части одновременно меняют цену, сохраняют заказ или обновляют остаток, исполнителю придётся устранять расхождения между ними, поэтому смета частичной переработки включает не только новый каталог, но и понятный способ поддерживать общий учёт. Я предпочитаю частичную переработку при понятном обмене данными: где меняют цену, где сохраняют заказ и каким способом обе части узнают об изменении. Для выбора нужен этот разбор, а не обещание «перенести только каталог» без описания связей.

Смета раскрывает одинаковый результат для разных вариантов

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

Какие работы легко пропустить

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

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

Кто будет поддерживать результат

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

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

Старые адреса остаются обязательствами нового сайта

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

Список переходов

Google рекомендует при миграции подготовить соответствие старых и новых URL. Для постоянного переезда страницы используются постоянные серверные перенаправления, например 301 и 308. Удалённому содержимому без замены соответствуют ответы 404 или 410. Владелец не настраивает эти ответы вручную, но получает список исходов важных страниц и сверяет его по смыслу. Главная не заменяет любой документ. Если все старые инструкции ведут на неё, клиент потеряет нужный материал, хотя технически переход сработает и браузер откроет доступную страницу.

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

Поисковые указания согласуются между собой

У новой страницы сверяют основной адрес, указанный через rel="canonical", внутренние ссылки и sitemap — карту сайта. Справка Google о canonical различает сигналы выбора основного адреса и рекомендует их согласовывать. Противоречие между прежним URL в одном месте и новым в другом усложняет понимание того, какую страницу компания считает основной.

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

Как перейти на новую версию без потери текущей работы

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

Что ограничат на время

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

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

Кто разрешает переключение

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

Предложение можно принять, когда его удаётся проверить

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

Короткая проверка предложения

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

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

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