Не начинайте rewrite с оценки на полгода. Начните с первого work slice
Если проект уже болит, почти всегда хочется попросить у команды «оценку на весь rewrite». В таблице появляется 4–6 месяцев, список рисков, большой бюджет и ощущение контроля.
Проблема в том, что это часто ложный контроль. Пока команда не видела репозиторий, staging, CI/CD, данные, роли, интеграции и реальные сценарии пользователей, большая оценка выглядит точной только на слайде.
Я предпочитаю начинать иначе: с маленького work slice.
Что такое work slice
Work slice — это не «бесплатно посмотреть проект» и не попытка сразу решить всё. Это ограниченный кусок работы, после которого становится понятнее три вещи:
- насколько система реально поддерживаема;
- как команда думает, коммуницирует и принимает решения;
- какие требования нужны для нормальной оценки следующего этапа.
Например: поднять проект локально или на staging, пройти один критичный пользовательский поток, найти место, где теряются данные или тормозит каталог, описать минимальный runbook и предложить следующий шаг.
Если речь о Bitrix, Laravel, Next.js или Elasticsearch, один такой slice часто показывает больше, чем неделя созвонов.
Почему большая оценка до discovery опасна
В legacy-проектах стоимость редко прячется в очевидных задачах. Она прячется в деталях:
- кто владеет доступами;
- можно ли безопасно выкатить staging;
- где живут секреты и cron-задачи;
- как устроены интеграции с CRM, 1С, оплатами, доставкой;
- есть ли документация или всё держится на памяти одного человека;
- что считается «готово» для бизнеса, а не только для разработчика.
Без этих ответов фиксированная оценка для кастомной разработки превращается в спор о том, кто оплатит неизвестность. Нормальнее сначала собрать контекст, отделить базовый scope от optional-части и договориться об acceptance criteria.
Как выглядит хороший первый slice
Я обычно смотрю не на «сколько экранов надо нарисовать», а на контроль проекта:
- репозиторий и история изменений;
- локальный запуск или staging;
- CI/CD и способ отката;
- структура данных и API-контракты;
- критичный поток: каталог, поиск, checkout, форма заявки или личный кабинет;
- логи и метрики, если они есть;
- документация, которой хватит новой команде.
На выходе нужен не красивый PDF. Нужна короткая карта: что блокирует развитие, что можно чинить без rewrite, где rewrite оправдан, какие риски надо закрыть первыми.
Что это показывает про подрядчика или senior engineer
Малый slice быстро показывает рабочий стиль.
Человек либо сразу просит «переписать всё», либо пытается понять, что уже приносит деньги и что нельзя ломать. Либо обещает точную цену до доступа к системе, либо честно отделяет известное от неизвестного. Либо прячет процесс, либо показывает Git Flow, review, staging и критерии проверки.
Для CTO или founder это практичнее, чем выбирать по портфолио. Вы видите не обещание, а маленькую модель будущей работы.
Когда slice не нужен
Если задача простая и типовая — лендинг, небольшой сайт, стандартная интеграция без сложных данных — можно идти сразу в обычную оценку.
Но если проект уже живёт в проде, зависит от интеграций, приносит деньги и его страшно трогать, work slice почти всегда дешевле большой ошибки.
Итог
Первый шаг в проблемном проекте — не героический rewrite. Первый шаг — сделать систему чуть более понятной.
Малый work slice не заменяет стратегию. Он убирает туман перед ней: показывает реальные ограничения, качество коммуникации и цену следующего решения.
Если вы смотрите на legacy-проект и не понимаете, чинить его или переписывать, начните не с большой сметы. Начните с одного проверяемого куска работы.
→ Близкая тема: Фронт деплоится за 3 минуты, бэк — за 40: как мы это решали в headless-проекте
→ И про границу между скоростью и архитектурой: Я даю Claude писать тесты. Я не даю ему выбирать архитектуру