Доработать старый сайт или строить новый: решение по стоимости ограничений

Сначала назовите ограничение, а не список недостатков

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

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

Важно отличать симптом от причины. Низкое число обращений не всегда означает, что нужно строить новый сайт. Причина может быть в предложении, трафике, форме или маршруте пользователя. А неудобная CMS сама по себе еще не доказывает необходимость полного перезапуска: иногда достаточно пересобрать контентную модель и роли редакторов. Чем точнее сформулировано ограничение, тем меньше денег уйдет на изменения, которые выглядят активно, но не меняют результат.

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

Полезная формула для первой встречи проста: «Мы хотим сделать X, но сайт мешает потому, что Y». Важно, чтобы X было действием бизнеса, а Y - наблюдаемым препятствием, а не общим ощущением. Такая формулировка объединяет коммерческую, маркетинговую и техническую стороны задачи без попытки решить все одновременно.

Посчитайте цену сохранения текущей модели

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

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

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

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

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

Сравните три масштаба решения

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

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

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

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

«Самый дорогой вариант - не всегда новый проект. Иногда дороже годами оплачивать доработки, которые не складываются в систему. Я смотрю на решение через будущую задачу компании: сможет ли после изменения команда спокойно запускать новые предложения и развивать сайт, или каждый следующий шаг снова потребует отдельного исключения».

Не смешивайте ремонт с редизайном

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

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

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

Примите решение через четыре критерия

Чтобы не выбирать между «дешево сейчас» и «дорого, но красиво», полезно рассмотреть варианты по одной шкале. Я использую четыре критерия: влияние на бизнес-задачу, стоимость изменения, риск сохранения ограничения и способность команды развивать результат после запуска.

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

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

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

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

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

Не переносите в новый проект старые привычки

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

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

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

Начните с решения, которое можно проверить

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

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

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