Аудит до rewrite: что должен получить decision maker

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

Хороший discovery-аудит нужен не для красивой презентации. Он должен дать владельцу, CTO или e-commerce lead материал, по которому можно принять решение: запускать пилот, менять план, остановиться или сначала собрать недостающие данные.

1. Карта ограничений, а не список пожеланий

Первый результат аудита — карта текущего контура: скорость, каталог, поиск, SEO, checkout, 1С-обмен, CRM, платежи, доставка, роли и контентные процессы. Важно отделить симптомы от причин. «Каталог тормозит» может означать тяжелые фильтры, неоптимальный API, неправильный cache strategy или конфликт бизнес-правил в данных.

На этом этапе нельзя обещать фиксированную стоимость полного replatform. Можно честно показать, какие зоны простые, какие требуют проверки, а какие нельзя трогать без rollback-плана.

2. Scope должен быть разделен на base и optional

Самая частая ошибка — смешать минимально нужный пилот с идеальным будущим продуктом. В результате смета раздувается, команда теряет фокус, а decision maker видит только большой риск.

Рабочая структура проще: base scope для первого измеримого slice, optional-блоки отдельно, client-specific сценарии отдельно. Например: одна категория, листинг, карточка товара, поиск и базовая аналитика — в pilot; сложная персонализация, редкие роли, дополнительные интеграции и полный контентный перенос — после проверки первого результата.

3. Acceptance criteria до разработки

Если критерии приемки появляются после старта, проект уже уязвим. До разработки нужно договориться, какие метрики сравниваем: LCP, TTFB, индексация, поиск без результата, конверсия в корзину, ошибки API, стабильность checkout. Не все метрики обязаны стать KPI пилота, но все спорные зоны должны быть названы заранее.

Это защищает обе стороны: клиент понимает, что именно покупает, а команда не продает абстрактную «модернизацию» без измеримого результата.

4. Первый work slice вместо большого обещания

Для сложной разработки правильный следующий шаг — небольшой work slice или пилот на реальных данных. Он показывает скорость коммуникации, качество Git Flow, staging-проверки, review, документацию и способность команды не ломать работающий бизнес.

WGP обычно предлагает начинать с ограниченного участка: категория, каталог, поиск, SEO-risk map или интеграционный probe. Это быстрее и честнее, чем продавать большой rewrite до того, как понятны данные, роли, workflow и acceptance criteria.

Следующий шаг: если вы смотрите на rewrite или migration с Bitrix, начните с короткого аудита. Мы разберем текущий контур, выделим base scope и покажем, какой маленький slice даст достаточно данных для решения. Посмотреть формат Headless Pilot или написать нам.