← Назад в блог

Risk budget перед headless: что я считаю до переписывания

Rewrite редко начинается с архитектуры. Обычно он начинается с фразы: "текущий сайт уже невозможно развивать".

Иногда это правда. Иногда нет.

Перед headless, Next.js или полным переписыванием я считаю не только бюджет разработки. Я считаю risk budget: сколько бизнес может потерять, если переход пойдет не по плану.

Деньги - не единственный риск

У проекта есть очевидная стоимость: команда, часы, подрядчик, лицензии, инфраструктура.

Но у e-commerce есть еще четыре счета, которые часто не попадают в первый estimate:

  • простой каталога или checkout;
  • просадка SEO из-за URL, canonical, фильтров и контентного паритета;
  • сбои интеграций с 1C, оплатой, доставкой, CRM;
  • время внутренней команды на приемку, тестирование и поддержку переходного периода.

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

Первый вопрос: что именно тормозит рост

Фраза "Bitrix тормозит" ничего не объясняет.

Тормозить может SQL-запрос. Кэш. Шаблон. Поиск. Интеграция с 1C. Отсутствие staging. Ручной deploy. Иногда узкое место вообще не в backend, а в процессе: любое изменение идет через одного человека, который помнит систему по памяти.

Поэтому первый шаг - не выбирать stack. Первый шаг - собрать карту рисков:

  1. какие страницы и сценарии реально зарабатывают деньги;
  2. где видны технические ограничения по метрикам, логам или релизам;
  3. что нельзя сломать ни на один день;
  4. какие интеграции имеют скрытую бизнес-логику;
  5. какие критерии приемки покажут, что переход удался.

Без этого headless превращается в красивую гипотезу.

Второй вопрос: можно ли идти поэтапно

Большой rewrite опасен тем, что долго не дает feedback.

Команда строит новую систему несколько месяцев, а потом в конце узнает, что часть логики жила в старом шаблоне, часть в обработчиках, часть в Excel у менеджера, а часть "всегда делалась руками".

Поэтапный headless-переход снижает риск:

  • сначала выносим один коммерческий сценарий;
  • сохраняем старое ядро, если оно зарабатывает деньги;
  • заводим staging и rollback;
  • сравниваем метрики до/после;
  • только потом расширяем scope.

Это не всегда моднее. Зато бизнес не ставит весь оборот на один deploy.

Третий вопрос: что будет считаться успехом

"Запустить новый сайт" - слабый acceptance criteria.

Лучше считать так:

  • LCP и TTFB на ключевых страницах;
  • скорость релиза маркетинговых изменений;
  • корректность индексации и редиректов;
  • стабильность checkout и интеграций;
  • доля сценариев, где команда больше не трогает legacy frontend;
  • понятность ownership: кто отвечает за API, frontend, content, cache, monitoring.

Тогда разговор про архитектуру становится разговором про бизнес-результат.

Что я обычно предлагаю вместо большого обещания

Не "фиксированная цена за rewrite".

Сначала compact discovery: требования, карта функциональности, базовый scope, optional/client-specific части, интеграции, данные, роли, workflow и acceptance criteria.

Потом небольшой work slice: один раздел каталога, один сценарий поиска, один frontend-модуль, одна измеримая проблема.

Это быстрее показывает качество работы, чем презентация на 40 слайдов.

И честнее.

Headless хорош, когда он снижает риск и ускоряет изменения. Если он просто заменяет один black box на другой, это не модернизация. Это смена декораций.