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